hir_analysis: add missing sizedness bounds

[davidtwco]

Default sizedness bounds were not being added to explicit_super_predicates_of and explicit_implied_predicates_of which meant that a trait bound added to a associated type projection would be missing the implied predicate of the default sizedness supertrait of that trait.

An unexpected consequence of this change was that the check for multiple principals was now finding an additional MetaSized principal when eagerly expanding trait aliases - this required modifying lowering to no longer add default bounds to trait aliases.

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

HIR ty lowering was modified

cc @fmease

[davidtwco]

Wasn't expecting that failure, looking into it.

[davidtwco]

A smaller example of one of the failing crates (which happens with a stage two build):

#![crate_type = "lib"]

use std::marker::PhantomData;

pub trait ZeroMapKV<'a> {
    type Container;
}

pub trait ZeroFrom<'zf, C: ?Sized> {}

pub struct ZeroMap<'a, K: ZeroMapKV<'a>>(PhantomData<&'a K>);

impl<'zf, 's, K> ZeroFrom<'zf, ZeroMap<'s, K>> for ZeroMap<'zf, K>
where
    K: for<'b> ZeroMapKV<'b>,
    <K as ZeroMapKV<'zf>>::Container: ZeroFrom<'zf, <K as ZeroMapKV<'s>>::Container>,
{
}

error[E0308]: mismatched types
  --> f.rs:16:39
   |
16 |     <K as ZeroMapKV<'zf>>::Container: ZeroFrom<'zf, <K as ZeroMapKV<'s>>::Container>,
   |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected trait `<<K as ZeroMapKV<'s>>::Container as MetaSized>`
              found trait `<<K as ZeroMapKV<'zf>>::Container as MetaSized>`
note: the lifetime `'zf` as defined here...
  --> f.rs:13:6
   |
13 | impl<'zf, 's, K> ZeroFrom<'zf, ZeroMap<'s, K>> for ZeroMap<'zf, K>
   |      ^^^
note: ...does not necessarily outlive the lifetime `'s` as defined here
  --> f.rs:13:11
   |
13 | impl<'zf, 's, K> ZeroFrom<'zf, ZeroMap<'s, K>> for ZeroMap<'zf, K>
   |           ^^

error[E0308]: mismatched types
  --> f.rs:16:39
   |
16 |     <K as ZeroMapKV<'zf>>::Container: ZeroFrom<'zf, <K as ZeroMapKV<'s>>::Container>,
   |                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected trait `<<K as ZeroMapKV<'s>>::Container as MetaSized>`
              found trait `<<K as ZeroMapKV<'zf>>::Container as MetaSized>`
note: the lifetime `'s` as defined here...
  --> f.rs:13:11
   |
13 | impl<'zf, 's, K> ZeroFrom<'zf, ZeroMap<'s, K>> for ZeroMap<'zf, K>
   |           ^^
note: ...does not necessarily outlive the lifetime `'zf` as defined here
  --> f.rs:13:6
   |
13 | impl<'zf, 's, K> ZeroFrom<'zf, ZeroMap<'s, K>> for ZeroMap<'zf, K>
   |      ^^^

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0308`.

[petrochenkov]

r? types

[compiler-errors]

I'd like to think about this...

Can you remind me, is trait Foo {} actually trait Foo: MetaSized {}?

[davidtwco]

I'd like to think about this...

Can you remind me, is trait Foo {} actually trait Foo: MetaSized {}?

Yes, it is

[compiler-errors]

I think this highlights a problematic interaction with trait aliases, and I'm tempted to say that trait aliases should have their behavior reworked to stop expanding into their bounds in dyn types. This would, for example, also fix dyn TraitAlias when trait TraitAlias = A + B, but that's a bigger change to advocate for I guess.

FOr now, I think it's inconsistent to not add MetaSized to trait aliases but add them to traits, and I think instead, to preserve/fix the tests, we should probably filter out MetaSized when we elaborate trait aliases when lowering dyn TraitAlias. This behavior should probably be tagged with a FIXME though.

[davidtwco]

I think this highlights a problematic interaction with trait aliases, and I'm tempted to say that trait aliases should have their behavior reworked to stop expanding into their bounds in dyn types. This would, for example, also fix dyn TraitAlias when trait TraitAlias = A + B, but that's a bigger change to advocate for I guess.

FOr now, I think it's inconsistent to not add MetaSized to trait aliases but add them to traits, and I think instead, to preserve/fix the tests, we should probably filter out MetaSized when we elaborate trait aliases when lowering dyn TraitAlias. This behavior should probably be tagged with a FIXME though.

Changed to this, thanks.

---

Still hitting the stage two failure, though I've added a UI test with my reproduction so that will fail first, not had much progress on working out what's going wrong with it.

[davidtwco]

See discussion on Zulip (#t-types > relaxing associated type bounds @ 💬) for background behind the last commit's changes.

[davidtwco]

@bors try

[bors]

⌛ Trying commit eac7da1 with merge 7df376b...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7df376b (7df376b035b3d12ff0386ad8b45b76dbe020257b)

[davidtwco]

@craterbot check

[craterbot]

👌 Experiment pr-142712 created and queued.
🤖 Automatically detected try build 7df376b
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-142712 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-142712 is completed!
📊 11 regressed and 5 fixed (661105 total)
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[Jules-Bertholet]

🎉 Experiment pr-142712 is completed! 📊 11 regressed and 5 fixed (661105 total) 📰 Open the summary report.

All these failures appear spurious—fail during linking or build script.

[Jules-Bertholet]

I think this highlights a problematic interaction with trait aliases, and I'm tempted to say that trait aliases should have their behavior reworked to stop expanding into their bounds in dyn types. This would, for example, also fix dyn TraitAlias when trait TraitAlias = A + B, but that's a bigger change to advocate for I guess.

That would conflict with the goals of my RFC 3437. Crates that use that RFC’s features to backward-compatibly expand their trait hierarchy, would find themselves saddled with a proliferation of equivalent-yet-distinct dyn types, risking all sorts of complications.

[Jules-Bertholet]

FOr now, I think it's inconsistent to not add MetaSized to trait aliases but add them to traits, and I think instead, to preserve/fix the tests, we should probably filter out MetaSized when we elaborate trait aliases when lowering dyn TraitAlias.

Actually, I think that adding MetaSized to trait aliases is inconsistent with type aliases. E.g. type Ptr<T> = *const T; doesn’t add an implicit T: Sized. I prefer the behavior from the original version of this PR. I suppose it could cause problems if you have a trait alias with no traits (trait Foo =;), but that can probably just be forbidden. (Edit: actually I think it’s fine?)

[fmease]

adding MetaSized to [trait] aliases is inconsistent with type aliases

Trait & type aliases are nothing alike, I wouldn't point at type aliases which are broken AF atm.

E.g. type Ref<T> = &T; doesn’t add an implicit T: Sized

We do actually (and always have) (you can see that for yourself by applying #[rustc_dump_predicates] to the type alias), it just doesn't get enforced — which is but a bug. CC #112792. This isn't a technicality, I just want to highlight that you truly shouldn't take inspiration from today's type aliases.

[Jules-Bertholet]

We do actually (and always have) (you can see that for yourself by applying #[rustc_dump_predicates] to the type alias), it just doesn't get enforced — which is but a bug.

I don’t see it as a bug, I think it’s a feature. To me, “alias” implying “the thing on the left means exactly the same as the thing on the right, no more nor less” is the natural and intuitive behavior. (Explicit bounds being unenforced is a bug, of course.)

[Jules-Bertholet]

Similarly, in this example:

struct Foo<T: Send>(T);
type Alias<T> = Foo<T>;

I think it’s good and useful that the declaration of Alias does not need to repeat the T: Send bound.