Tracking issue for future-incompatibility lint tyvar_behind_raw_pointer

View all comments

This is the summary issue for the tyvar_behind_raw_pointer future-compatibility warning and other related errors. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What is the warning for?

This warning occurs when you call a method on a value whose type is a raw pointer to an unknown type (aka *const _ or *mut _), or a type that dereferences to one of these.

The most common case for this is casts, for example:

        let s = libc::getenv(k.as_ptr()) as *const _;
        s.is_null()

This can be fixed by giving a type annotation to the cast:

        let s = libc::getenv(k.as_ptr()) as *const libc::c_char;
        s.is_null()

The reason that this is going to become an error is because we are working on enabling arbitrary self types. Using that, you should be able to write functions such as:

#![feature(arbitrary_self_types)]

struct MyType;

impl MyType {
    fn is_null(self: *mut Self) -> bool {
        println!("?");
        true
    }
}

While that case is obviously silly, we can't prevent a sibling crate from implementing it, and such a function would make a call to s.is_null() when the type of s is an *mut _ ambiguous. Therefore, to avoid that potential breakage, you have to annotate the type of your raw pointer before the point of the method call.

After you fix these warnings, if you are working with raw pointers on nightly, you might want to check out #![feature(arbitrary_self_types)] yourself! It even works with trait objects:

#![feature(arbitrary_self_types, dyn_trait)]
trait Foo {
    fn example(self: *mut Self);
}

struct S;
impl Foo for S {
    fn example(self: *mut Self) {
        println!("Hello, I'm at {:?}", self);
    }
}

fn foo(foo: *mut dyn Foo) {
    foo.example();
}

fn main() {
    // This is 100% safe and not UB, even through I am calling `foo`
    // with a null pointer - this is a *raw* null pointer, and these are
    // always ok.
    foo(0 as *mut S);
}

While I'm at it, arbitrary_self_types also works for smart pointers, such as Rc<T> or Arc<T> (however, unfortunately we still have not figured out the best way to make it work with smart pointers to trait objects, so you can't yet create dyn Bar trait objects. We are planning on making it eventually work, so stay tuned!).

#![feature(arbitrary_self_types)]

use std::rc::Rc;

trait Bar {
    fn example(self: &Rc<Self>);
}

struct S;
impl Bar for S {
    fn example(self: &Rc<Self>) {
        println!("Hi I'm called on an Rc.");
        let _x = self.clone(); // You can call Rc::clone on Self!
    }
}

fn main() {
    Rc::new(S).example();
}

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.

Annotate raw pointer target types

@arielb1

@arielb1 thanks for editing with the detailed explanation!

Auto merge of #46914 - mikeyhew:raw_pointer_self, r=arielb1

Add an explicit type to silence a future compatibility warning

This warning occurs when you call a method on a value whose type is a raw pointer to an unknown type (aka *const _ or *mut _), or a type that dereferences to one of these.

(Emphasis added.)

I feel that this latter case is overly zealous. A pervasive pattern in Servo’s DOM can be simplified to this:

fn main() {
    // T = *mut _
    let mut constructor = RootedGuard::new(std::ptr::null_mut());

    // "warning: the type of this value must be known in this context"
    // But is this really ambiguous? Or does the warning have a false positive?
    let handle = constructor.handle_mut();

    // Type inference establishes `T = *mut JSObject` here.
    get_constructor_object_from_local_name(handle);
}

pub struct RootedGuard<T>(T);
pub struct MutableHandle<T>(T);
pub struct JSObject;

impl<T: Clone> RootedGuard<T> {
    pub fn new(x: T) -> Self { RootedGuard(x) }
    pub fn handle_mut(&mut self) -> MutableHandle<T> { unimplemented!() }
}

impl<T> std::ops::Deref for RootedGuard<T> {
    type Target = T;
    fn deref(&self) -> &T { &self.0 }
}

fn get_constructor_object_from_local_name(_: MutableHandle<*mut JSObject>) {}

As of 0a3761e the handle_mut call causes a tyvar_behind_raw_pointer warning which does not seem justified: handle_mut is an inherent method of RootedGuard<T> and so will always be picked before any method of T through auto-deref. arbitrary_self_types won’t change that as far as I can tell.

Please consider not warning in this case. This example is easy enough to fix (for example by replacing null_mut() with null_mut::<JSObject>()), but Servo has 1871 instances of this warning and adding as many type annotation would be a huge pain if they indeed don’t actually remove any ambiguity.

Auto merge of #19683 - servo:rustup, r=<try>

(Do not merge )Work around a maybe-false-positive warning

(Do not merge) Work around a maybe-false-positive warning

Auto merge of #19683 - servo:rustup, r=<try>

@SimonSapin

@SimonSapin

handle_mut is an inherent method of RootedGuard and so will always be picked before any method of T through auto-deref

During method lookup, T is *mut _. That _ could theoretically resolve to a type that has a method fn handle_mut(self: &mut RootedGuard<*mut Self>), which would result an an ambiguity on method lookup. Not to say that defining methods like this is very useful, but that's what's currently allowed with arbitrary_self_types.

Type inference establishes `T = *mut JSObject` here.
get_constructor_object_from_local_name(handle);

It's unfortunate that the type information from this function call isn't available during the earlier method lookup. I don't know much about how type inference works in the compiler, but it would be nice if cases like this could be improved.

@arielb1 any thoughts on a possible solution here?

Auto merge of #19683 - servo:rustup, r=<try>

So, my thoughts are these:

There is really not much we can do to get more type information. We already do basically exhaust what remedies we have.

To get more, we'd have to do some big refactorings on the way that method lookup works. I'd like to do this, but it seems pretty distinct from this PR. We'd basically have to make method dispatch "delayable" until more type information is available.

I am a bit nervous about making this change however. I feel like we've seen a fair amount of code affected, though I don't have a real sample. Were any crater runs done to provide actual measurements?

At the worst, we could do the change only behind a feature-gate, and then use an epoch to enable access to custom self types.

xdispatch: Eliminate the compiler warning "tyvar_behind_raw_pointer"

@arielb1

I've got a case that hits this lint without using any casting.

I've just encountered the same issue on today's nightly:

    /// Creates an empty vector with capacity for `cap` values.                 
    pub fn with_capacity(cap: usize) -> Self {                                  
        let raw = RawVec::with_capacity(cap);                                   
        for i in 0..raw.capacity() {                                            
            unsafe {                                                            
                ptr::write(raw.ptr().offset(i as isize), T::default());         
            }                                                                   
        }                                                                       
        DefaultVec { raw }                                                      
    }

Gives:

warning: type annotations needed
  --> src/lib.rs:26:38
   |
26 |                 ptr::write(raw.ptr().offset(i as isize), T::default());
   |                                      ^^^^^^
   |
   = note: `#[warn(tyvar_behind_raw_pointer)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in the 2018 edition!
   = note: for more information, see issue #46906 <https://github.com/rust-lang/rust/issues/46906>

As @arielb1 says, you can fix it by adding type annotations:

let raw: RawVec<T> = RawVec::with_capacity(cap);

But I think the error message was confusing. I'd have known what to do if it had said:

warning: type annotations needed
  --> src/lib.rs:23:..
   |
23 |                 let raw = RawVec::with_capacity(cap);
   |                     ^^^
   |

It's probably time to move towards closing this compatibility lint, and maybe we can improve the diagnostics at the same time.

It appears I've come across this issue, though I don't get why it's happening despite me providing type annotations:

#[repr(C)]
struct Foo {
    a: u8,
    b: u8,
    c: u8,
    d: u8,
}

fn main() {
    let var = Foo { a: 1, b: 2, c: 3, d: 4 };
    let raw_pointer_array = &var as *const Foo as *const u8;
    let goofy_array: [u8; 4] = unsafe { raw_pointer_array.cast().read() };
    println!("{:?}", goofy_array);
}

it happens because the type of raw_pointer_array.cast() is *const _, i.e. a type variable behind a raw pointer. The lint is then emitted while selecting the method for read

It seems reasonable for it to infer from .read() that I want the type of .cast() to be *const [u8; 4]. If I'm not mistaken, this also happens in some similar capacity in type inference elsewhere too.

Fix for new rustc warnings

(I was reminded of this by the mention in cast_slice's tracking issue)

If we allow dispatchable non-method trait functions (zulip chat link), then we can get the "best of both worlds" IMO:

disallow raw pointer receivers (even under arbitrary_self_types), and then change type inference to make let x: T = ptr.cast().read(); work on all editions
allow raw pointer "dispatchers" of dispatchable non-method trait functions to allow code like the following to compile (adapted from OP):

code example

#![feature(rustc_attrs)]

#[rustc_dyn_compatible_trait] // requires all functions to either be dispatchable or explicitly non-dispatchable
trait Foo {
    fn example(this: *mut Self); // dispatchable because it doesn't have `Self: Sized` or similar
}

struct S;
impl Foo for S {
    fn example(this: *mut Self) {
        println!("Hello, I'm at {:?}", this);
    }
}

fn foo(foo: *mut dyn Foo) {
    Foo::example(foo); // Foo::example *is not a method*, so `foo.example()` method-call syntax intentionally doesn't work.
}

fn main() {
    // This is 100% safe and not UB, even through I am calling `foo`
    // with a null pointer - this is a *raw* null pointer, and these are
    // always ok.
    foo(0 as *mut S);
}

(this code compiles under this branch)

Navigation Menu

Repository navigation

Tracking issue for future-incompatibility lint `tyvar_behind_raw_pointer` #46906

39 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for future-incompatibility lint tyvar_behind_raw_pointer #46906

Description

Activity

mikeyhew commented on Dec 23, 2017

SimonSapin commented on Jan 4, 2018

mikeyhew commented on Jan 4, 2018

nikomatsakis commented on Jan 4, 2018

39 remaining items

vext01 commented on Jun 18, 2020

nikomatsakis commented on Jun 18, 2020

orowith2os commented on Nov 7, 2023

lcnr commented on Nov 10, 2023

orowith2os commented on Nov 10, 2023

zachs18 commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for future-incompatibility lint `tyvar_behind_raw_pointer` #46906