-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
#[deny(unsafe_op_in_unsafe_fn)]
in liballoc
#72709
Conversation
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
I believe they're desirable and will likely approve this fairly soon to avoid it bitrotting since it touches a bunch of code. However, I'm going to try and bring this up at tomorrow's compiler team meeting as an announcement and let folks chime in if they want (note: compiler team because of libs-impl area). While I think this is a definite improvement, looking over the diff, particularly in the "mostly unsafe" functions -- it almost feels like I want to go even further, or at least experiment with doing so. Something like "unsafe only applies one level in" though exactly what levels I'm talking about I'm not sure -- but something along the lines of having one unsafe block per unsafe operation. That's obviously likely to be quite noisy so I've now been thinking about something like cc @rust-lang/lang @rust-lang/wg-unsafe-code-guidelines -- y'all are probably interested in looking at the diff here too |
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'm in favor of landing the PR. I left a few suggestions for places we could "tighten" the unsafe block but I quickly got bored of that. =) I think we could refine these over time.
#71862 landed. |
d2e2890
to
dd18ba7
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
To be clear, this PR is tagged as "waiting on team" -- is it waiting on the lang team? It seems like it'd be good for @rust-lang/lang folks to look at, but I don't know that it has to be blocked on the team, it seems like more of a "compiler team" (well, libs-impl) decision. Still, I'll raise it in the meeting. |
dd18ba7
to
845e3eb
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
So I think we talked about this in our last lang team meeting and generally concluded that lang team approval isn't really relevant for this PR, as it's really an implementation question, though it's useful data towards the question of whether we want to alter the default levels for these lints. I'm going to remove the T-lang notification tag -- maybe folks from @rust-lang/compiler might want to weigh in here, since we are supposed to be managing the implementation of the standard library. I suppose an MCP might be appropriate actually, this feels like a kind of "policy question". Myself I would favor landing this PR if for no other reason than it will give us somewhat more data on whether the more precise unsafe blocks "wear well" over time. |
I actually meant to mark it as blocked on the Last time I tried to run CI after beta branching, it seems like it was using a cached beta so build still failed. I'll retry now and resolve the merge conflicts in the process. |
a0d9dce
to
615372b
Compare
615372b
to
7b63986
Compare
MCP rust-lang/compiler-team#306 has been accepted. |
@nikomatsakis If you are still ok with the changes, I think this should be merged as soon as possible because of the many conflicts it could cause or encounter. |
@bors r+ p=1 Giving p=1 because of "high merge conflict potential" |
📌 Commit 7b63986 has been approved by |
bumping priority a bit to avoid conflicts :D @bors p=3 |
⌛ Testing commit 7b63986 with merge 479198141ba473aa1035d3099700b5dda0919d6c... |
@bors yield force retry |
…arth Rollup of 13 pull requests Successful merges: - rust-lang#71568 (Document unsafety in slice/sort.rs) - rust-lang#72709 (`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc) - rust-lang#73214 (Add asm!() support for hexagon) - rust-lang#73248 (save_analysis: improve handling of enum struct variant) - rust-lang#73257 (ty: projections in `transparent_newtype_field`) - rust-lang#73261 (Suggest `?Sized` when applicable for ADTs) - rust-lang#73300 (Implement crate-level-only lints checking.) - rust-lang#73334 (Note numeric literals that can never fit in an expected type) - rust-lang#73357 (Use `LocalDefId` for import IDs in trait map) - rust-lang#73364 (asm: Allow multiple template string arguments; interpret them as newline-separated) - rust-lang#73382 (Only display other method receiver candidates if they actually apply) - rust-lang#73465 (Add specialization of `ToString for char`) - rust-lang#73489 (Refactor hir::Place) Failed merges: r? @ghost
@bors r=nikomatsakis |
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 7b63986 has been approved by |
This PR proposes to make use of the new
unsafe_op_in_unsafe_fn
lint, i.e. no longer consider the body of an unsafe function as an unsafe block and require explicit unsafe block to perform unsafe operations.This has been first (partly) suggested by @Mark-Simulacrum in #69245 (comment)
Tracking issue for the feature: #71668.
Blocked on #71862.r? @Mark-Simulacrum cc @nikomatsakis can you confirm that those changes are desirable? Should I restrict it to only BTree for the moment?