Dyn compatibility error when using an associated type as a type parameter in the super-trait listing

[jonysy]

I tried this code:

trait Super<T> {}

trait Foo: Super<<Self as Foo>::Bar> { type Bar;  }

type BoxFoo = Box<Foo<Bar = u8>>;

The code should compile since Self::Bar is the type parameter, not Self.

Instead, it will fail with the following message:

the trait Foo cannot be made into an object
the trait cannot use Self as a type parameter in the supertrait listing

FYI the discussion that sparked this issue:

So this has to do with object safety -- any trait that references Self is not object safe because the true Self type is erased. However, the error doesn't seem appropriate in this case. I think this warrants a bug report at least to fix the error message, if not to relax the object safety check (because there could be something I don't see preventing it still... can't say I fully understand object safety).

Meta

rustc --version --verbose: rustc 1.17.0-nightly (b1e31766d 2017-03-03)

[estebank]

Current output:

error[E0038]: the trait `Foo` cannot be made into an object
 --> src/lib.rs:5:19
  |
5 | type BoxFoo = Box<Foo<Bar = u8>>;
  |                   ^^^^^^^^^^^^^ the trait `Foo` cannot be made into an object
  |
  = note: the trait cannot use `Self` as a type parameter in the supertraits or where-clauses

It should at least point at trait Foo's supertraits.

[estebank]

Output in #68377:

error[E0038]: the trait `Foo` cannot be made into an object
 --> file.rs:7:19
  |
3 | trait Foo: Super<<Self as Foo>::Bar> {
  |       ---  ------------------------- ...because it cannot use `Self` as a type parameter in the supertraits or `where`-clauses
  |       |
  |       this trait cannot be made into an object...
...
7 | type BoxFoo = Box<dyn Foo<Bar = u8>>;
  |                   ^^^^^^^^^^^^^^^^^ the trait `Foo` cannot be made into an object

[estebank]

I believe that we should change the implementation here

rust/compiler/rustc_trait_selection/src/traits/object_safety.rs

Lines 287 to 293 in ed97493

	let self_ty = tcx.types.self_param;
	let has_self_ty = |arg: &GenericArg<'tcx>| arg.walk().any(|arg| arg == self_ty.into());
	match predicate.kind().skip_binder() {
	ty::PredicateKind::Clause(ty::Clause::Trait(ref data)) => {
	// In the case of a trait predicate, we can skip the "self" type.
	if data.trait_ref.substs[1..].iter().any(has_self_ty) { Some(sp) } else { None }
	}

to account for data=TraitPredicate(<Self as Super<<Self as Foo>::Bar>>, polarity:Positive and explicitly allow it, by ignoring when Self is only referenced to access one of its currently defined associated types.

Further changes would also be needed here

rust/compiler/rustc_hir_analysis/src/astconv/mod.rs

Lines 1519 to 1542 in ed97493

	// Like for trait refs, verify that `dummy_self` did not leak inside default type
	// parameters.
	let references_self = b.projection_ty.substs.iter().skip(1).any(|arg| {
	if arg.walk().any(|arg| arg == dummy_self.into()) {
	return true;
	}
	false
	});
	if references_self {
	tcx.sess
	.delay_span_bug(span, "trait object projection bounds reference `Self`");
	let substs: Vec<_> = b
	.projection_ty
	.substs
	.iter()
	.map(|arg| {
	if arg.walk().any(|arg| arg == dummy_self.into()) {
	return tcx.ty_error().into();
	}
	arg
	})
	.collect();
	b.projection_ty.substs = tcx.intern_substs(&substs[..]);
	}

@rust-lang/lang, would this require team sign-off, or is the current behavior "accidental"/"incidental" and a change of behavior requires no "new rationale"?

I'm also intrigued on whether this test should have been rejected with a more targeted error, instead of E0038: https://github.com/rust-lang/rust/blob/eb4580a570069175e1290b294d91042a09f9fde3/src/test/ui/issues/issue-26056.rs

[nikomatsakis]

@estebank

Self can appear in projections, but only as part of an "identity" trait-ref. i.e., if you hvae trait Foo<A..Z>, then the trait ref has to be <Self as Foo<A..Z>>::Bar. This ensures that we can extract the associated type from the self type (which will be something like dyn Foo<A..Z, Bar=X>.

I think such a PR does not require an FCP, but it's prob a good idea to nominate for @rust-lang/types approval or review. This feels to me like a 'nitty gritty' detail. I think in general @rust-lang/types is a good choice for that, and types team can escalate to lang if it seems like it requires a policy decision.