Change:
Note: The regression is valid/"allowed" (there's a hole in the typesystem being patched), I'm just filing this issue now so we can make sure that this regression is tracked in case it got "fixed" by accident. Feel free to close if it's a known quantity; I'm just worried that this got "accidentally" fixed in some other change. My crate is being fixed to not face this problem, but in general there's a chance other crates are falling afoul of this as well; we should perhaps assess the impact and start off with it being a future incompatibility warning if necessary. I tried this code: () I expected to see this happen: It compiles, like it does on stable, or at least throws a future incompatibility warning. Instead, this happened: It errors: It most recently worked on: Rust 1.56.0
This regressed in , which was a rollup. Further testing shows this resulted from . It's marked as being a partial revert, so I'm not entirely sure what the chronology is here. CC Note that we think this "regression" probably isn't actually a problem, per the note at the top.
What the....
Okay so reverting fully also errors. Stable 1.55.0 fails. Checking (a couple commits before ) now, but I'm assuming it's going to error. So, this was actually a bug in 1.56.0 - prior to that, this didn't compile, rightfully. My guess is because of treating unnormalized function args & output as WF, we saw , replaced it with , assumed that was WF, so we didn't actually check that . I'm going to go ahead and make a PR to add a test that closes this issue. This was a bug in 1.56.0, not a regression since.
Good to know, thanks! (And good that this was just a one-version regression; less chance of there being in-the-wild breakage)
I should figure out an excuse to make yoke a dependency of rustc, it seems really good at finding typesystem corner cases and maybe we should just have it be a test
Isn't it failing on the wrong line? I would have expected it to fail on the because is the thing that needs to match
Haha yeah, it's a thorn in my side So, it's interesting. The check is , which is true. What I might expect here is it to fail because you haven't written (which is required for to be well-formed. But I think this is implied bounds, since this is fine:
In my experience WFness of has always been a bit variable where sometimes you can assume it and sometimes it requires you to spell it out, so maybe this is another instance of that.
Thanks!

Discussion:
<ins> // check-fail // See issue #91899. If we treat unnormalized args as WF, `Self` can also be a // source of unsoundness. pub trait Yokeable<'a>: 'static { type Output: 'a; } impl<'a, T: 'static + ?Sized> Yokeable<'a> for &'static T { type Output = &'a T; } pub trait ZeroCopyFrom<C: ?Sized>: for<'a> Yokeable<'a> { /// Clone the cart `C` into a [`Yokeable`] struct, which may retain references into `C`. fn zero_copy_from<'b>(cart: &'b C) -> <Self as Yokeable<'b>>::Output; } impl<T> ZeroCopyFrom<[T]> for &'static [T] { fn zero_copy_from<'b>(cart: &'b [T]) -> &'b [T] { //~^ the parameter cart } } fn main() {} </ins>

<ins> error[E0310]: the parameter type `T` may not live long enough --> $DIR/implied-bounds-unnorm-associated-type-3.rs:19:5 | LL |     fn zero_copy_from<'b>(cart: &'b [T]) -> &'b [T] { |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `T: 'static`... = note: ...so that the type `[T]` will meet its required lifetime bounds error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>