Enforce safety comments on alloc - #160941
Conversation
rustbot
added
A-tidy
|
This will break a lot of ppl's CI ^^ @bors rollup=never |
|
I'm not convinced |
|
@bors rollup=iffy p=1 likely to soft conflict |
|
...i completely forgot to actually push the commit with all my manual work. apologies 🫠 |
|
Oh, I didn't know that you were actually going through and adding comments to these. I'd, probably want to do an actual review in that case. |
| type Cap = core::num::niche_types::UsizeNoHighBit; | ||
|
|
||
| // SAFETY: Untriaged. | ||
| // SAFETY: 0 *definitely* is less than isize::MAX. |
There was a problem hiding this comment.
But how can you be sure?
There was a problem hiding this comment.
easy: isize was defined before 2025 and therefore there were affordable computers around that had to address more than 0 bytes of memory!
|
per this week's libs meeting, we (a) do want this! and (b) we should go for ignore-tidy-undocumented-unsafe instead of a blank untriaged comment |
|
@rustbot author |
rustbot
added
S-waiting-on-author
This comment has been minimized.
This comment has been minimized.
|
(apologies for merging some conflicting PRs. wouldn't mind helping rebase if this is getting difficult to manage) |
safety comments in alloc this was pain and it's not even half i think oepsje woepsje
75cc497 to
483873e
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. |
|
think this is done and mergeable now. rebased on main, so it shouldn't conflict much i hope? @rustbot ready |
rustbot
added
S-waiting-on-review
|
Okay, that was painful, but reviewed. @bors try |
This comment has been minimized.
This comment has been minimized.
Enforce safety comments on `alloc`
|
Recommended merge command assuming try passes: r=clarfonthey p=1 note="Affects entire alloc crate, can easily go stale" |
|
Also fine with you just rebasing this yourself and merging in case of conflicts, assuming you mark new blocks as ignored instead of trying to determine what their comments should be. |
|
@bors r+ p=1 note="Affects entire alloc crate, can easily go stale" |
rust-bors
Bot
added
S-waiting-on-bors
…rfonthey Enforce safety comments on `alloc` cc @clarfonthey, @workingjubilee. Following up from rust-lang#160824. I spent a painfully long time going over the comments and ensuring there's nothing too awful ^^ r? clarfonthey
…rfonthey Enforce safety comments on `alloc` cc @clarfonthey, @workingjubilee. Following up from rust-lang#160824. I spent a painfully long time going over the comments and ensuring there's nothing too awful ^^ r? clarfonthey
…rfonthey Enforce safety comments on `alloc` cc @clarfonthey, @workingjubilee. Following up from rust-lang#160824. I spent a painfully long time going over the comments and ensuring there's nothing too awful ^^ r? clarfonthey
Rollup of 7 pull requests Successful merges: - #160941 (Enforce safety comments on `alloc`) - #161975 (Abort instead of unwinding out of an inconsistent BTreeMap::split_off) - #157968 (Preserve ambiguous glob lint for subtrait method picks) - #161514 (rework handling of doc attributes on macro calls) - #161944 (rustdoc: Take into account edition information for keyword highlighting) - #161974 (remove rustc_never_type_options attr remnants) - #161978 (Move rustdoc ui doctests into the right testsuite) Failed merges: - #161702 (Use `drop_guard` in some places in {core,alloc,std})
7 participants
View all comments
cc @clarfonthey, @workingjubilee. Following up from #160824. I spent a painfully long time going over the comments and ensuring there's nothing too awful ^^
r? clarfonthey