-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
enable fuzzy_provenance_casts lint in liballoc and libstd #104647
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
@@ -184,7 +185,7 @@ unsafe fn read_encoded_pointer( | |||
}; | |||
|
|||
if encoding & DW_EH_PE_indirect != 0 { | |||
result = *(result as *const usize); | |||
result = *ptr::from_exposed_addr::<usize>(result); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope this can only happen if we previously had the DW_EH_PE_pcrel
case above and exposed the pointer...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who knows, but given that as *const usize
is essentially semantically equivalent to from_exposed_addr::<usize>(...)
, this shouldn't add additional UB or anything if that's not how it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could add UB only if the code relied on the round_up
stuff above also exposing the pointer. But that did look like a slam-dunk case for with_addr
so I went with that. (Actually it would be an awesome case for map_addr
except that it would need ?
inside the closure so of course that doesn't work...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could add UB only if the code relied on the round_up stuff above also exposing the pointer
That would be incredibly goofy and surprising, so I'm going to assume it's not the case.
@@ -47,6 +47,7 @@ | |||
#![feature(strict_provenance)] | |||
#![feature(once_cell)] | |||
#![feature(drain_keep_rest)] | |||
#![deny(fuzzy_provenance_casts)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little surprised this is the only lint we turn on in the liballoc tests, but I'll look into that later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah me too... I briefly tried denying unsafe_op_in_unsafe_fn
and got too many red lines to pursue this further right now. ;)
@bors r+ rollup |
Ah, wait, this might cause platform-specific failures. So maybe rollup=always is too optimistic. @bors rollup=maybe |
Yeah. I did check builds on Linux, Android, macOS, Windows targets (which did find some more cases) but there are tons of targets left untested -- this should probably be |
⌛ Testing commit 7f5addd with merge 5d1ad57001036df80dc2d48130ba9a461b4a81a6... |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
@bors r=thomcc |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Flaky rustdoc test?
Cc @rust-lang/rustdoc |
Yeah, flaky rustdoc test. Nothing you changed here could've affected it. #93784 |
…r=thomcc enable fuzzy_provenance_casts lint in liballoc and libstd r? `@thomcc`
…r=thomcc enable fuzzy_provenance_casts lint in liballoc and libstd r? ``@thomcc``
…r=thomcc enable fuzzy_provenance_casts lint in liballoc and libstd r? ```@thomcc```
…earth Rollup of 6 pull requests Successful merges: - rust-lang#103488 (Allow opaque types in trait impl headers and rely on coherence to reject unsound cases) - rust-lang#104359 (Refactor must_use lint into two parts) - rust-lang#104612 (Lower return type outside async block creation) - rust-lang#104621 (Fix --extern library finding errors) - rust-lang#104647 (enable fuzzy_provenance_casts lint in liballoc and libstd) - rust-lang#104750 (Bump `fd-lock` in `bootstrap` again) Failed merges: - rust-lang#104732 (Refactor `ty::ClosureKind` related stuff) r? `@ghost` `@rustbot` modify labels: rollup
…safe_fn, r=Mark-Simulacrum Add `#![deny(unsafe_op_in_unsafe_fn)]` in liballoc tests In rust-lang#104647 (comment) it was mentioned that liballoc tests should probably have this enabled (we have it pretty much everywhere else in the stdlib), so I added it. This will probably conflict with rust-lang#104647 so I'll rebase after that lands.
…safe_fn, r=Mark-Simulacrum Add `#![deny(unsafe_op_in_unsafe_fn)]` in liballoc tests In rust-lang#104647 (comment) it was mentioned that liballoc tests should probably have this enabled (we have it pretty much everywhere else in the stdlib), so I added it. This will probably conflict with rust-lang#104647 so I'll rebase after that lands.
…safe_fn, r=Mark-Simulacrum Add `#![deny(unsafe_op_in_unsafe_fn)]` in liballoc tests In rust-lang#104647 (comment) it was mentioned that liballoc tests should probably have this enabled (we have it pretty much everywhere else in the stdlib), so I added it. This will probably conflict with rust-lang#104647 so I'll rebase after that lands.
…safe_fn, r=Mark-Simulacrum Add `#![deny(unsafe_op_in_unsafe_fn)]` in liballoc tests In rust-lang#104647 (comment) it was mentioned that liballoc tests should probably have this enabled (we have it pretty much everywhere else in the stdlib), so I added it. This will probably conflict with rust-lang#104647 so I'll rebase after that lands.
…r=Mark-Simulacrum Add `#![deny(unsafe_op_in_unsafe_fn)]` in liballoc tests In rust-lang/rust#104647 (comment) it was mentioned that liballoc tests should probably have this enabled (we have it pretty much everywhere else in the stdlib), so I added it. This will probably conflict with rust-lang/rust#104647 so I'll rebase after that lands.
r? @thomcc