unsafe keyword docs: bring back unsafe_op_in_unsafe_fn lint discussion#152613
unsafe keyword docs: bring back unsafe_op_in_unsafe_fn lint discussion#152613RalfJung wants to merge 2 commits intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
rustbot has assigned @Mark-Simulacrum. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Will remind myself of the earlier discussion and have a look. |
|
@traviscross friendly ping :) |
library/std/src/keyword_docs.rs
Outdated
| /// Historically, these two are not mutually exclusive, as can be seen in `unsafe fn`: the body of | ||
| /// an `unsafe fn` is, on old editions, treated like an unsafe block. The `unsafe_op_in_unsafe_fn` | ||
| /// lint can be enabled to change that (and that lint is enabled by default since edition 2024). |
There was a problem hiding this comment.
While better, this is still leading with the old-edition behavior (e.g., "can be enabled...") and burying the current-edition behavior in a parenthetical.
I'll leave this tab open and think about concrete wording that might be better. The second part of this diff, below, is better about this -- that wording is stronger. Maybe that could be copied up here, or this part shortened again.
(Also, see the double space between "two" and "are".)
There was a problem hiding this comment.
This is leading with "unsafe has two uses" in the old unchanged text above, which is the new behavior. Only then do we get to the historic part where we mention the old behavior.
There was a problem hiding this comment.
I have pushed a reword, maybe that works better?
|
Thanks for the ping. |
RalfJung
force-pushed
the
unsafe-keyword-docs
branch
from
fed1c33 to
40b2d7a
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
RalfJung
force-pushed
the
unsafe-keyword-docs
branch
from
40b2d7a to
f3ed56d
Compare
4 participants
@traviscross in #141471 you asked me to also update the text to account for the edition change. Apparently I did that by entirely removing this part of the discussion (except for a dangling forward reference, a "see below"). Given that old editions still exist and given that
unsafe_op_in_unsafe_fnis just a lint so the old behavior also still exists on new editions, I am no longer sure that was a good idea, so this brings back the old text with some editing to explain the current situation.