Skip to content

Enforce safety comments on alloc - #160941

Open
nia-e wants to merge 8 commits into
rust-lang:mainfrom
nia-e:alloc-safety-comments
Open

Enforce safety comments on alloc#160941
nia-e wants to merge 8 commits into
rust-lang:mainfrom
nia-e:alloc-safety-comments

Conversation

@nia-e

@nia-e nia-e commented Aug 11, 2026

Copy link
Copy Markdown
Member

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

@rustbot rustbot added A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Aug 11, 2026
@nia-e

nia-e commented Aug 11, 2026

Copy link
Copy Markdown
Member Author

This will break a lot of ppl's CI ^^

@bors rollup=never

@JonathanBrouwer

JonathanBrouwer commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

I'm not convinced rollup=never actually helps. This kind of PR is likely to have soft conflicts (i.e. someone adds an unsafe block between this PR being opened and merged), but rollup=never doesn't help detecting those. In fact, it makes them worse because soft conflicts may get detected in PR CI/try jobs of rollups and not waste queue time. My primary recommendation to help with this would be to reduce the time between PR open and r+, and rebase before r+ if this is more than a few days

@JonathanBrouwer

Copy link
Copy Markdown
Contributor

@bors rollup=iffy p=1 likely to soft conflict
p=1 does help because it makes you get into rollups earlier reducing time between pr open & merge

@nia-e

nia-e commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

...i completely forgot to actually push the commit with all my manual work. apologies 🫠

@clarfonthey

Copy link
Copy Markdown
Contributor

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.

Comment thread library/alloc/src/boxed/thin.rs Outdated
Comment thread library/alloc/src/boxed/thin.rs Outdated
Comment thread library/alloc/src/boxed/thin.rs Outdated
Comment thread library/alloc/src/collections/binary_heap/mod.rs Outdated
Comment thread library/alloc/src/collections/binary_heap/mod.rs Outdated
Comment thread library/alloc/src/collections/binary_heap/mod.rs Outdated
Comment thread library/alloc/src/collections/binary_heap/mod.rs
Comment thread library/alloc/src/collections/binary_heap/mod.rs
Comment thread library/alloc/src/collections/btree/mem.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/drain.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/spec_extend.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/spec_extend.rs Outdated
Comment thread library/alloc/src/ffi/c_str.rs Outdated
type Cap = core::num::niche_types::UsizeNoHighBit;

// SAFETY: Untriaged.
// SAFETY: 0 *definitely* is less than isize::MAX.

@clarfonthey clarfonthey Aug 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But how can you be sure?

View changes since the review

@nia-e nia-e Aug 12, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

easy: isize was defined before 2025 and therefore there were affordable computers around that had to address more than 0 bytes of memory!

Comment on lines -892 to +894
// SAFETY: Precondition passed to caller
// SAFETY: Untriaged.
if let Some((ptr, layout)) = unsafe { self.current_memory(elem_layout) } {
// SAFETY: Untriaged.
// SAFETY: Precondition passed to caller

@clarfonthey clarfonthey Aug 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one looked painful to figure out

View changes since the review

Comment thread library/alloc/src/vec/into_iter.rs Outdated
Comment thread library/alloc/src/vec/mod.rs Outdated
Comment thread library/alloc/src/alloc.rs
Comment thread library/alloc/src/alloc.rs
Comment thread library/alloc/src/sync.rs Outdated
fn into_inner_with_allocator(this: Self) -> (NonNull<ArcInner<T>>, A) {
let this = mem::ManuallyDrop::new(this);
// SAFETY: Untriaged.
// SAFETY: Pointer is valid for reads and won't be double-dropped.

@clarfonthey clarfonthey Aug 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

YORO? (You only read once.)

View changes since the review

@ChrisDenton

Copy link
Copy Markdown
Member

Could you put a #![forbid(clippy::missing_safety_doc)] in lib.rs? I know it's technically redundant with the tidy lint but I've been trying to enable (or at least not ignore) more clippy lints so it'd be useful to me to have that tracked with clippy too.

@nia-e

nia-e commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

missing_safety_doc is for missing function safety docs ^^ i think that goes as a separate PR? this is just the safety comments on unsafe blocks and the scope is already slightly terrifyingly large lol

@nia-e

nia-e commented Aug 12, 2026

Copy link
Copy Markdown
Member Author

that should address review comments 🫠

@rust-log-analyzer

This comment has been minimized.

Comment thread library/alloc/src/collections/btree/node.rs Outdated
Comment thread library/alloc/src/collections/btree/node.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
Comment thread library/alloc/src/collections/vec_deque/mod.rs Outdated
@@ -1403,6 +1436,7 @@ impl<T, A: Allocator> VecDeque<T, A> {
} else {
// Either there's not enough spare capacity to make the deque contiguous, or the head is shorter than the tail
// (and therefore hopefully cheaper to copy).
// SAFETY: Untriaged.

@DanielEScherzer DanielEScherzer Aug 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same, comment already in the unsafe block

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this one doesn't justify the access, since copy has missing safety docs. i assume the safety requirement is that the sizes are inbounds, but...

Comment thread library/alloc/src/io/cursor.rs Outdated
Comment thread library/alloc/src/vec/mod.rs Outdated
@@ -2682,6 +2695,7 @@ impl<T, A: Allocator> Vec<T, A> {
let mut first_duplicate_idx: usize = 1;
let start = self.as_mut_ptr();
while first_duplicate_idx != len {
// SAFETY: Untriaged.

@DanielEScherzer DanielEScherzer Aug 12, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is a safety comment within the unsafe block that can be used

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it applies to the first unsafe op, but i'm unconvinced for the other 2. either way, good to split this up, nice catch ^^

@rust-bors

This comment has been minimized.

@nia-e

nia-e commented Aug 13, 2026

Copy link
Copy Markdown
Member Author

(presumably #160953)

it seems my children have come to haunt me

@nia-e
nia-e force-pushed the alloc-safety-comments branch from 0ad4d08 to 0c8e275 Compare August 13, 2026 00:47
@rustbot

rustbot commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

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.

@rust-bors

rust-bors Bot commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

☔ The latest upstream changes (presumably #161075) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-tidy Area: The tidy tool S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants