Confusing errors with *dyn pointers

Code

trait MyTrait {
    fn f(&self) -> bool;
}

struct MyStruct(pub u32);

impl MyTrait for MyStruct {
    fn f(&self) -> bool {
        self.0 != 0
    }
}

pub fn inner(_p: *mut dyn MyTrait) {}

pub fn outer(p: &mut dyn MyTrait) {
    let q = p as *mut _;
    inner(q)
}

pub fn main() {
    let mut s = MyStruct(42);
    outer(&mut s);
}

Current output

error: lifetime may not live long enough
  --> main.rs:16:13
   |
15 | pub fn outer(p: &mut dyn MyTrait) {
   |                 - let's call the lifetime of this reference `'1`
16 |     let q = p as *mut _;
   |             ^ cast requires that `'1` must outlive `'static`

error: aborting due to 1 previous error

Desired output

No response

Rationale and extra context

The fact that a cast to a raw pointer checks lifetimes is confusing by itself. Even more confusing is the fact it talks about the reference lifetime while it’s the referenced type lifetime what matters, i.e. &mut (dyn MyTrait + 'static) is what the compiler wants. Though I’m not sure whether it should check that either, it’s a raw pointer after all.

Also sometimes, the error is shown not on the cast but where the result is used, like:

43 | pub fn some_function<R>(parameter: &mut dyn SomeTrait, f: impl FnOnce() -> R) -> R {
   |                                    - let's call the lifetime of this reference `'1`
44 |     let pp = std::ptr::from_mut(parameter);
45 |     let obj = SomeOtherObj::new(pp);
   |                                 ^^ cast requires that `'1` must outlive `'static`

I’m not sure how to reproduce that however.

Related: #95242.

Other cases

No response

Rust Version

rustc 1.80.1 (3f5fd8dd4 2024-08-06)
binary: rustc
commit-hash: 3f5fd8dd41153bc5fdca9427e9e05be2c767ba23
commit-date: 2024-08-06
host: x86_64-unknown-linux-gnu
release: 1.80.1
LLVM version: 18.1.7

Anything else?

No response

Start with the Rust code sample in main.rs and reproduce the diagnostic using rustc 1.80.1, then compare it with the second from_mut example and related issue #95242. The issue needs a defined expected diagnostic or behavior before completion can be judged; done would mean the confusing lifetime error cases have an agreed, clearer outcome.