Tracking issue for future-incompatibility lint ptr_cast_add_auto_to_object

[WaffleLapkin]

This is a tracking issue for the ptr_cast_add_auto_to_object lint, which was added in #120248.

This lint detects casts of raw pointers to trait objects, which add auto traits. Adding auto traits to trait objects may cause UB when #![feature(arbitrary_self_types)] is used.

Example

#![feature(arbitrary_self_types)]
trait Trait {
    fn f(self: *const Self)
    where
        Self: Send;
}

impl Trait for *const () {
    fn f(self: *const Self) {
        unreachable!()
    }
}

fn main() {
    let unsend: *const () = &();
    let unsend: *const dyn Trait = &unsend;
    let send_bad: *const (dyn Trait + Send) = unsend as _;
    send_bad.f(); // this crashes, since vtable for `*const ()` does not have an entry for `f`
    //~^ warning: adding an auto trait `Send` to a trait object in a pointer cast may cause UB later on
}

In case your usage is sound (e.g. because the trait doesn't have auto trait bounds), you can replace cast with a transmute to suppress the warning:

trait Cat {}
impl Cat for *const () {}

fn main() {
    let unsend: *const () = &();
    let unsend: *const dyn Cat = &unsend;
    let _send: *const (dyn Cat + Send) = unsafe {
        // Safety:
        // - Both types are pointers, to the same trait object (and thus have the same vtable)
        // - `Cat` does not have methods with `Send` bounds
        std::mem::transmute::<*const dyn Cat, *const (dyn Cat + Send)>(unsend)
    };
    // meow
}

[bjorn3]

In case your usage is sound (e.g. because the trait doesn't have auto trait bounds), you can replace cast with a transmute to suppress the warning:

Future compatibility warnings are generally made hard errors after a while, right? I don't think we should suggest suppressing a future compatibility warning.

[WaffleLapkin]

@bjorn3 we only will make cases with the warning into errors. transmuteing is, and will be, allowed (although you do actually need to make sure that your code is sound).

[BoxyUwU]

The example in the description now needs arbitrary_self_types_pointers instead however we can recreate the same kind of setup with a combination of arbitrary_self_types and derive_coerce_pointee in order to get a raw pointer receiver with a DispatchFromDyn impl:

#![feature(arbitrary_self_types, derive_coerce_pointee)]

use std::marker::CoercePointee;

#[derive(CoercePointee)]
#[repr(transparent)]
struct MyPtr<T: ?Sized>(*const T);

use std::ops::Receiver;

impl<T: ?Sized> Receiver for MyPtr<T> {
    type Target = T;
}

trait Trait {
    fn foo(self: MyPtr<Self>)
    where
        Self: Send;
}

impl Trait for *mut () {
    fn foo(self: MyPtr<Self>) {
        unreachable!()
    }
}

fn main() {
    let a = 0x1 as *const *mut ();
    let a = a as *const dyn Trait as *const (dyn Trait + Send);
    MyPtr(a).foo();
}

This does currently ICE due to #135179 not having been merged yet but once it's in this segfaults for me locally

[RalfJung]

We already have a safety invariant of requiring a valid vtable for raw pointers; dyn upcasting relies on that. I guess the cast above is accepted because "marker traits don't change the vtable", or so?

[RalfJung]

@BoxyUwU that does not trigger the lint that this issue tracks... so it should probably get a separate issue?

[BoxyUwU]

The ICE gets hit before the lint is triggered but once the ICE is fixed the lint triggers + there's a segfault when the program is run

[BoxyUwU]

boxy@crossaints:/media/Nyoomies/Repos/playground_1$ cargo +stage1 run
warning: adding an auto trait `Send` to a trait object in a pointer cast may cause UB later on
  --> src/main.rs:29:13
   |
29 |     let a = a as *const dyn Trait as *const (dyn Trait + Send);
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #127323 <https://github.com/rust-lang/rust/issues/127323>
   = note: `#[warn(ptr_cast_add_auto_to_object)]` on by default

warning: `c` (bin "c") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.00s
warning: the following packages contain code that will be rejected by a future version of Rust: c v0.1.0 (/media/Nyoomies/Repos/playground_1)
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 2`
     Running `target/debug/c`
Segmentation fault (core dumped)

If anyone is curious this is the output I get locally on that example when using a stage1 compiler from errs' branch

[RalfJung]

Ah okay. So this one "just" needs the lint to be turned into a hard error then.

I agree with your statement elsewhere that that should happen before this example works on stable.