Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
kmcallister opened this issue Dec 9, 2014 · 12 comments
Closed

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

kmcallister opened this issue Dec 9, 2014 · 12 comments
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@kmcallister
Copy link
Contributor

#![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 kmcallister added I-wrong A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. labels Dec 9, 2014
@kmcallister
Copy link
Contributor Author

cc @nick29581

@kmcallister
Copy link
Contributor Author

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

@kmcallister
Copy link
Contributor Author

@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
Copy link
Member

nrc commented Jan 12, 2015

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

@kmcallister
Copy link
Contributor Author

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

@kmcallister
Copy link
Contributor Author

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
Copy link
Contributor

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 steveklabnik added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 8, 2017
@steveklabnik
Copy link
Member

Triage: no change.

@Mark-Simulacrum
Copy link
Member

As far as I can tell, this lint is never invoked today (even in trans); it's previous use was removed by @nikomatsakis in c5edd22. @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
Copy link
Contributor

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

@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. I-wrong labels Jul 22, 2017
@asquared31415
Copy link
Contributor

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

@jieyouxu
Copy link
Member

jieyouxu commented Mar 1, 2025

This lint doesn't exist today since it seems to be...

store.register_removed("fat_ptr_transmutes", "was accidentally removed back in 2014");

Closing.

@jieyouxu jieyouxu closed this as not planned Won't fix, can't repro, duplicate, stale Mar 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants