Uh oh!
There was an error while loading. Please reload this page.
#[deny(unsafe_op_in_unsafe_fn)] in liballoc - #72709
Conversation
rust-highfive
commented
May 28, 2020
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 |
Mark-Simulacrum
commented
May 28, 2020
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 |
nikomatsakis
left a comment
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
LeSeulArtichaut
commented
May 30, 2020
#71862 landed. |
d2e2890 to
dd18ba7Comparerust-highfive
commented
May 31, 2020
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 |
nikomatsakis
commented
Jun 1, 2020
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
845e3ebComparerust-highfive
commented
Jun 3, 2020
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 |
nikomatsakis
commented
Jun 8, 2020
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. |
LeSeulArtichaut
commented
Jun 8, 2020
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
615372bCompare615372b to
7b63986CompareLeSeulArtichaut
commented
Jun 19, 2020
MCP rust-lang/compiler-team#306 has been accepted. |
LeSeulArtichaut
commented
Jun 19, 2020
@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. |
nikomatsakis
commented
Jun 19, 2020
@bors r+ p=1 Giving p=1 because of "high merge conflict potential" |
bors
commented
Jun 19, 2020
📌 Commit 7b63986 has been approved by |
Dylan-DPC-zz
commented
Jun 19, 2020
bumping priority a bit to avoid conflicts :D @bors p=3 |
bors
commented
Jun 19, 2020
⌛ Testing commit 7b63986 with merge 479198141ba473aa1035d3099700b5dda0919d6c... |
Manishearth
commented
Jun 19, 2020
@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
Manishearth
commented
Jun 19, 2020
@bors r=nikomatsakis |
bors
commented
Jun 19, 2020
💡 This pull request was already approved, no need to approve it again.
|
bors
commented
Jun 19, 2020
📌 Commit 7b63986 has been approved by |
This PR proposes to make use of the new
unsafe_op_in_unsafe_fnlint, 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?