-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Comments
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 |
Oh, hmm, the RFC doesn't have the interesting parts. Nm. |
(I have this half-implemented in https://github.com/cmr/rust/tree/unsafe-transmutes) |
Ah, the proposed changes to transmute are in #12898, not the RFC. |
Triage: nothing has changed, these transmutes still silently work:
|
…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
…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
…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
…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
…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
…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
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
…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
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`
Doing a
&T
to&mut T
transmute is now undefined behaviour (it needs to use theUnsafe
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)
.The text was updated successfully, but these errors were encountered: