-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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 a lint against hidden reborrows in &mut
-> *const
casts
#103652
Add a lint against hidden reborrows in &mut
-> *const
casts
#103652
Conversation
Functions in answer: - `Ty::is_freeze` - `Ty::is_sized` - `Ty::is_unpin` - `Ty::is_copy_modulo_regions`
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in src/tools/clippy cc @rust-lang/clippy The Miri subtree was changed cc @rust-lang/miri |
Very generic nit: lint names should read as a sentence if prefixed by allow/deny, so it should be |
We are not emitting Also I'm sorry but I won't have time to review this. |
Oh also, the next aliasing model I am currently working on with an intern will hopefully make these casts just fine, and make the returned pointer writeable. So I am not even sure if we want this lint. I view this as a Stacked Borrows artifact, not something fundamental.
That's not true any more, is it? AFAIK these casts compile to |
The job Click to see the possible cause of the failure (guessed by this bot)
|
So, from the @RalfJung's and folks' in community discord input it seems like this lint was misinformed and based on outdated view of the situation. The code that could be linted is currently UB (according to miri at least), but if it's not an inherent property of Rust, but more of a temporary result of SB, then we probably shouldn't lint it. As such, I'm closing this ;-; |
This PR adds a lint called
hidden_reborrow_in_ptr_casts
that warn against code like this:Direct
&mut
->*const
casts go through an intermediate&
reference, which strips write provenance from the pointer. Thus it's UB to write via a pointer derived from the resulting pointer.This is a tricky thing that can easily be left unnoticed, so makes sense to warn users about it. Especially since there are plans to actually exploit this UB.
r? @RalfJung
Some more details:
&mut 0 as *const _
) and implicit (let _: *const _ = &mut 0
) castsUnsafeCell
somewhere (or, in other words it's!Freeze
), then the warning is not issued, because it's ok to write to unsafe cell without write provenanceP.S. this is rebased on #103625, because it was more convenient