Made adjustments suggested by reviews.

Author: Alexander Regueiro

src/librustc_codegen_ssa/base.rs

@@ -161,7 +161,10 @@ pub fn unsized_info<'tcx, 'a, Bx: BuilderMethods<'a, 'tcx>>(
             // Trait upcast
 
             let source_ptr = old_info.expect("unsized_info: missing old info for trait upcast");
+            // Only bother offsetting into the parent vtable if we are upcasting to a
+            // non-auto trait.
             let target_ptr = if let Some(target_trait_ref) = target_data.principal() {
+                // Find the offset of the supertrait's vtable within the subtrait (parent) vtable.
                 let trait_ref = target_trait_ref.with_self_ty(tcx, source);
                 let vtable = tcx.codegen_fulfill_obligation((ty::ParamEnv::reveal_all(), trait_ref));
                 let offset = match vtable {
@@ -172,12 +175,14 @@ pub fn unsized_info<'tcx, 'a, Bx: BuilderMethods<'a, 'tcx>>(
                     _ => bug!("unsized_info: unexpected vtable kind {:?}", vtable),
                 };
 
+                // Ensure the pointer to the parent vtable has the right LLVM type.
                 let vtable_layout = bx.cx().layout_of(tcx.mk_mut_ptr(source));
                 let source_ptr = bx.pointercast(
                     source_ptr,
                     bx.cx().scalar_pair_element_backend_type(vtable_layout, 1, true),
                 );
 
+                // Perform the offset within the parent vtable.
                 bx.struct_gep(source_ptr, offset as u64)
             } else {
                 source_ptr

src/librustc_middle/ty/sty.rs

@@ -1881,14 +1881,6 @@ impl<'tcx> TyS<'tcx> {
         }
     }
 
-    /// Panics if called on any type other than `PhantomData<T>`.
-    pub fn phantom_ty(&self) -> Ty<'tcx> {
-        match self.kind {
-            Adt(def, substs) if def.is_phantom_data() => substs.type_at(0),
-            _ => bug!("`phantom_ty` is called on non-phantom-data type {:?}", self),
-        }
-    }
-
     /// A scalar type is one that denotes an atomic datum, with no sub-components.
     /// (A RawPtr is scalar because it represents a non-managed pointer, so its
     /// contents are abstract to rustc.)

src/librustc_trait_selection/traits/select.rs

@@ -2970,7 +2970,28 @@ impl<'cx, 'tcx> SelectionContext<'cx, 'tcx> {
                     tcx.mk_dynamic(existential_predicates, region_b);
 
                 if tcx.features().trait_upcasting {
-                    // Register obligations for `dyn TraitA1 [TraitA2...]: TraitB1 [TraitB2...]`.
+                    // Given that we are upcasting `dyn (TraitA1 + ... + TraitAn)` to
+                    // `dyn (TraitB1 + ... + TraitBn)`, register proof obligations like
+                    //
+                    //     dyn (TraitA1 + ... + TraitAn): TraitB1
+                    //     ...
+                    //     dyn (TraitA1 + ... + TraitAn): TraitBn
+                    //
+                    // So, if for example we are upcasting `dyn (Foo + Send)` to `dyn (Bar + Send)`,
+                    // then we would check that `dyn (Foo + Send): Bar` and `dyn (Foo + Send): Send`
+                    // -- or at least we would, were it not for the slight pre-filter hack.
+                    //
+                    // The pre-filter hack removes cases where `TraitBi` is an auto-trait like
+                    // `Send`, so long as we see that auto-trait in the A type. In our example, this
+                    // would skip the dyn (Foo + Send): Send obligation. There are two reasons for
+                    // this. The first is efficiency -- this case trivially holds. The second is
+                    // because we would otherwise encounter ambiguity errors during bootstrap, owing
+                    // to the `rustc_datastructures::sync::Send` trait (which is not the same as the
+                    // standard `Send` trait). This trait has a `impl<T: ?Sized> Send for T` impl,
+                    // and thus we get an error when trying to choose between this impl versus and
+                    // the automatic impl that we prove from `dyn Traits`. This ambiguity is silly
+                    // (it doesn't matter which one we choose), but rather than resolve that in the
+                    // general case (which is subtle), we can screen it out here easily enough.
                     nested.extend(
                         data_b.iter()
                             // HACK(alexreg | nikomatsakis): we handle auto traits specially here