Diagnostic for changed lifetime in trait object parameters points to tracking issue for different change

[traviscross]

Tracking:

• Tracking Issue for breaking raw pointer casts of trait objects #141402

Given this code:

trait AnyL<'x> {}

fn f<'long: 'short, 'short>(
    x: *const dyn AnyL<'long>,
) -> *const dyn AnyL<'short> {
    x as *const dyn AnyL<'short>
}

Our diagnostic, after #136776, reports:

error: lifetime may not live long enough
 --> src/main.rs:7:5
  |
4 | fn f<'long: 'short, 'short>(
  |      -----          ------ lifetime `'short` defined here
  |      |
  |      lifetime `'long` defined here
...
7 |     x as *const dyn AnyL<'short>
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cast requires that `'short` must outlive `'long`
  |
  = help: consider adding the following bound: `'short: 'long`
note: raw pointer casts of trait objects cannot extend lifetimes
 --> src/main.rs:7:5
  |
7 |     x as *const dyn AnyL<'short>
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  = note: this was previously accepted by the compiler but was changed recently
  = help: see <https://github.com/rust-lang/rust/issues/141402> for more information

It says this was previously accepted, but as far as I know, it never was. I tested it in Rust 1.0, Rust 1.85, and in various other version. It was rejected in the versions I tested.

Related:

• Tracking Issue for breaking raw pointer casts of trait objects #141402
• Forbid freely casting lifetime bounds of dyn-types #136776
• Reference updates for forbidding object lifetime changing pointer casts reference#1951

cc @BoxyUwU @Darksonn @ehuss

[Darksonn]

That's right. It was only accepted for trailing lifetimes dyn Trait + 'a. Lifetimes that appear in generics have always required an exact match.

[BoxyUwU]

I'm not sure why that example previously didn't compile but it's not true that we've always disallowed casting arguments to trait objects. See #120248 which made the casts we allow for trait objects massively stricter (but just missing object lifetime casts)

[traviscross]

Interesting. Upon testing more versions, I see that we rejected the above program in Rust 1.74 then allowed it in Rust 1.75. Then, due to #120248, we began rejecting it again in Rust 1.81.

One option, I suppose, would be to update the tracking issue in #141402 to talk about #120248 as well.

[BoxyUwU]

I think it would makes sense to have a shared tracking issue for all the breakage caused by being stricter about casts of raw pointers 👍