experiment: Require safety comments in all of std & alloc by nia-e · Pull Request #160824 · rust-lang/rust

nia-e · 2026-08-09T23:25:46Z

cc @workingjubilee @joshtriplett, per discussion in Zulip.

this is... awful, but not as awful as expected :D it'd also cause a lot of conflicts. i'm scared of how many CODEOWNERS might be triggered

workingjubilee · 2026-08-09T23:52:07Z

We have CODEOWNERS?

nia-e · 2026-08-09T23:54:58Z

we have configs for teams to get pinged when certain files are touched. close enough

clarfonthey · 2026-08-09T23:56:32Z

I think, for the sake of this being reasonable to merge at all, we should probably split this into multiple pieces.

Also, perhaps starting with alloc would be best?

nia-e · 2026-08-10T00:01:25Z

alloc is reasonable to start. a lot of std excepting os and sys would be actually doable manually. i'd also want a check-in from libs more broadly that we want to go this direction, so i'd let the idea cook for a bit before i'd want to merge anything

clarfonthey · 2026-08-10T00:08:24Z

I feel like offering up a PR with just alloc would be a good test, since some folks mentioned it might increase noise, and it'd be a good example for people to play with and see if that's actually the case.

sys and os are substantially larger and messier, so, they'd probably be harder to gauge. There's already a lot of duplication we still need to scale back.

ChrisDenton · 2026-08-10T00:46:55Z

This file is generated from windows-bindgen so shouldn't be edited. But the good news is that, since Default is now implemented on pointers, the unsafe will be going away in the next version of windows-bindgen.

View changes since the review

y21 · 2026-08-10T06:29:48Z

        // Safety: We only touch lock_count when we own the inner mutex.
        // Additionally, we only call `self.owner.set()` while holding
        // the inner mutex, so no two threads can call it concurrently.
+        // SAFETY: Untriaged.


Two safety comments here now

View changes since the review

fair. I did all of this with just a regex, not intending to merge as-is ^^ there's very likely a lot of cases like this

y21 · 2026-08-10T06:31:39Z

+            _ => {
+    // SAFETY: Untriaged.
+                unsafe {
+                    cvt(libc::pipe(fds.as_mut_ptr()))?;



Formatting seems a little off here

View changes since the review

This is an unfortunate side-effect of macro formatting; not even indenting gets done right.

rust-bors · 2026-08-12T06:04:10Z

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

…nthey doc: document safety requirements for core WTF-8 This PR is a follow-up to rust-lang#160824, and serves as a complementry of `Wtf8` in `alloc` . This PR currently fixes the wtf8 module in `core`, because I noticed that some unsafe APIs in this file do not provide a `safety section`. Therefore, before discharging the call sites, we need to first add the safety section. This PR performs that fix. This PR is related to unstable feature `Wtf8` but this feature don't have relevant tracking issue.

Rollup merge of #161271 - yilin0518:fix_coree_wtf8, r=clarfonthey doc: document safety requirements for core WTF-8 This PR is a follow-up to #160824, and serves as a complementry of `Wtf8` in `alloc` . This PR currently fixes the wtf8 module in `core`, because I noticed that some unsafe APIs in this file do not provide a `safety section`. Therefore, before discharging the call sites, we need to first add the safety section. This PR performs that fix. This PR is related to unstable feature `Wtf8` but this feature don't have relevant tracking issue.

…nthey Add safety comments in alloc::Wtf8 This PR follow up rust-lang#160824 and add some safety section for unsafe APIs. This PR focus on Wtf8 in alloc and fix every `Untriged` mentioned in rust-lang#160824. Before this PR, rust-lang#161271 had add some safety sections for Wtf8 in core. I'm looking forward to your review and give me any feedback to improve this PR.

Rollup merge of #161292 - yilin0518:fix_alloc_wtf8, r=clarfonthey Add safety comments in alloc::Wtf8 This PR follow up #160824 and add some safety section for unsafe APIs. This PR focus on Wtf8 in alloc and fix every `Untriged` mentioned in #160824. Before this PR, #161271 had add some safety sections for Wtf8 in core. I'm looking forward to your review and give me any feedback to improve this PR.

doc: document safety requirements for core WTF-8 This PR is a follow-up to rust-lang/rust#160824, and serves as a complementry of `Wtf8` in `alloc` . This PR currently fixes the wtf8 module in `core`, because I noticed that some unsafe APIs in this file do not provide a `safety section`. Therefore, before discharging the call sites, we need to first add the safety section. This PR performs that fix. This PR is related to unstable feature `Wtf8` but this feature don't have relevant tracking issue.

nia-e added 2 commits August 10, 2026 01:21

tidy: enforce documented unsafe

83595fe

lol. lmao, even. rofl.

0c8b110

nia-e added O-wasi Operating system: Wasi, Webassembly System Interface O-hermit Operating System: Hermit O-itron Operating System: ITRON O-solid Operating System: SOLID O-apple Operating system: Apple / Darwin (macOS, iOS, tvOS, visionOS, watchOS) labels Aug 9, 2026

ChrisDenton reviewed Aug 10, 2026

View reviewed changes

y21 reviewed Aug 10, 2026

View reviewed changes

nia-e mentioned this pull request Aug 11, 2026

Enforce safety comments on alloc #160941

Open

This was referenced Aug 18, 2026

doc: document safety requirements for core WTF-8 #161271

Merged

Add safety comments in alloc::Wtf8 #161292

Merged

Navigation Menu

Uh oh!

Uh oh!

experiment: Require safety comments in all of std & alloc - #160824

experiment: Require safety comments in all of std & alloc#160824
nia-e wants to merge 2 commits into
rust-lang:mainfrom
nia-e:std-safety-comments

nia-e commented Aug 9, 2026 •

edited

Loading

Uh oh!

workingjubilee commented Aug 9, 2026

Uh oh!

nia-e commented Aug 9, 2026

Uh oh!

clarfonthey commented Aug 9, 2026

Uh oh!

nia-e commented Aug 10, 2026 •

edited

Loading

Uh oh!

clarfonthey commented Aug 10, 2026

Uh oh!

ChrisDenton Aug 10, 2026 •

edited by rustbot

Loading

Uh oh!

y21 Aug 10, 2026 •

edited by rustbot

Loading

Uh oh!

nia-e Aug 10, 2026

Uh oh!

y21 Aug 10, 2026 •

edited by rustbot

Loading

Uh oh!

clarfonthey Aug 10, 2026

Uh oh!

rust-bors Bot commented Aug 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Uh oh!

Conversation

nia-e commented Aug 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented Aug 9, 2026

Uh oh!

nia-e commented Aug 9, 2026

Uh oh!

clarfonthey commented Aug 9, 2026

Uh oh!

nia-e commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clarfonthey commented Aug 10, 2026

Uh oh!

ChrisDenton Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

y21 Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nia-e Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

y21 Aug 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clarfonthey Aug 10, 2026

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Aug 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nia-e commented Aug 9, 2026 •

edited

Loading

nia-e commented Aug 10, 2026 •

edited

Loading

ChrisDenton Aug 10, 2026 •

edited by rustbot

Loading

y21 Aug 10, 2026 •

edited by rustbot

Loading

y21 Aug 10, 2026 •

edited by rustbot

Loading