rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.63k stars 12.74k forks source link

fat-ptr-transmutes lint doesn't work #19676

Open kmcallister opened 9 years ago

kmcallister commented 9 years ago
#![deny(fat_ptr_transmutes)]

use std::mem;

fn main() {
    let x: [u8, ..8] = [0, ..8];
    let y: [u8, ..16] = unsafe {
        mem::transmute(x.as_slice())
    };
    println!("{}", y.as_slice());
}

compiles and runs with no warnings. The problem is that trans::intrinsic::check_intrinsics calls Session::add_lint but the pass that emits these lints has already run. See this comment in rustc::lint.

Please add a test case when fixing this! :)

kmcallister commented 9 years ago

cc @nick29581

kmcallister commented 9 years ago

Once this is fixed, I will submit a patch I wrote that ICEs when add_lint is called in the wrong place.

kmcallister commented 9 years ago

@nick29581: Any thoughts on this? I think we should fix this for 1.0 or remove the lint for now, because it never prints anything.

nrc commented 9 years ago

I think we should fix it :-) Do you know how hard it would be to do another lint pass after trans?

kmcallister commented 9 years ago

I think it's worth a shot. It would also eliminate a bunch of hacks for the existing variant size lint in trans.

kmcallister commented 9 years ago

If we leave these two lints hardcoded then we don't need a full pass, we just need to go through the session / AST and print out saved lints, which I think could be factored out easily enough.

Stebalien commented 9 years ago

Still broken. Updated test:

#![deny(fat_ptr_transmutes)]

use std::mem;

fn main() {
    let x: [u8; 8] = [0; 8];
    let y: [u8; 16] = unsafe {
        mem::transmute(&x[..])
    };
    println!("{:?}", &x[..]);
}
steveklabnik commented 7 years ago

Triage: no change.

Mark-Simulacrum commented 7 years ago

As far as I can tell, this lint is never invoked today (even in trans); it's previous use was removed by @nikomatsakis in c5edd22646fcde05b39490558371c7ea9d525a0f. @nikomatsakis, could you comment on what the reasoning there was? I feel like it might've been an accidental removal...

Looking into the code seems to suggest that the problem is that with slices, the representation (as I understand it) is *(usize, usize) so the type's size is the "same" in this case. That would explain why we don't detect this, I believe, though I may be wrong about my reasoning here.

nikomatsakis commented 7 years ago

@Mark-Simulacrum hmm I do think that was an accident, or perhaps a merge failure.

asquared31415 commented 1 year ago

This lint appears to have been completely removed, and trying to use it emits a "removed lint" warning. Should this issue be closed?