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

Add lint for & -> &mut transmutes #13146

Closed
huonw opened this issue Mar 26, 2014 · 5 comments · Fixed by #24392
Closed

Add lint for & -> &mut transmutes #13146

huonw opened this issue Mar 26, 2014 · 5 comments · Fixed by #24392
Labels
A-lints Area: Lints (warnings about flaws in source code) such as unused_mut.

Comments

@huonw
Copy link
Member

huonw commented Mar 26, 2014

Doing a &T to &mut T transmute is now undefined behaviour (it needs to use the Unsafe type), and so there could be a lint for it.

Unfortunately, such a lint is likely to miss many such casts, but it will theoretically catch common cases like transmute::<&Foo, &mut Foo>(self).

@huonw huonw added the A-lint label Mar 26, 2014
@nikomatsakis
Copy link
Contributor

The proposed changes to intrinsics help here, because they wlil effectively forbid transmutes between types unless we can be sure of the size, which implies that one cannot transmute arbitrary types T to U and so on. We could even make these sorts of const casts illegal -- though somehow we have to make the Unsafe type able to do it. :)

@nikomatsakis
Copy link
Contributor

Oh, hmm, the RFC doesn't have the interesting parts. Nm.

@emberian
Copy link
Member

(I have this half-implemented in https://github.com/cmr/rust/tree/unsafe-transmutes)

@nikomatsakis
Copy link
Contributor

Ah, the proposed changes to transmute are in #12898, not the RFC.

@steveklabnik
Copy link
Member

Triage: nothing has changed, these transmutes still silently work:

use std::mem;

fn main() {
    let x = 5;

    let y = &x;

    let z = unsafe { mem::transmute::<&i32, &mut i32>(y) };
}

seanmonstar added a commit to seanmonstar/rust that referenced this issue Apr 22, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
seanmonstar added a commit to seanmonstar/rust that referenced this issue Apr 29, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
seanmonstar added a commit to seanmonstar/rust that referenced this issue Apr 29, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
seanmonstar added a commit to seanmonstar/rust that referenced this issue Apr 30, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
seanmonstar added a commit to seanmonstar/rust that referenced this issue May 5, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
seanmonstar added a commit to seanmonstar/rust that referenced this issue May 6, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
bors added a commit that referenced this issue May 6, 2015
The [UnsafeCell documentation says it is undefined behavior](http://doc.rust-lang.org/nightly/std/cell/struct.UnsafeCell.html), so people shouldn't do it.

This happened to catch one case in libstd that was doing this, and I switched that to use an UnsafeCell internally.

Closes #13146
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue May 7, 2015
…d behavior

[breaking-change] Technically breaking, since code that had been using
these transmutes before will no longer compile. However, it was
undefined behavior, so really, it's a good thing. Fixing your code would
require some re-working to use an UnsafeCell instead.

Closes rust-lang#13146
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 25, 2024
Lint casts to `u128` in `cast_lossless`

Reverts rust-lang#12496 per https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Should.20.60as.20u128.60.20trigger.20cast_lossless

Also changes the lint messages and refactors the suggestion production - Fixes rust-lang#12695

changelog: [`cast_lossless`]: lint casts to `u128`
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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants