#![deny(unsafe_op_in_unsafe_fn)] in libstd

[LeSeulArtichaut]

The goal of this effort is to #![deny(unsafe_op_in_unsafe_fn)] in all of libstd, as proposed in rust-lang/compiler-team#317. This means enclosing unsafe operations in unsafe functions inside unsafe blocks, and documenting them as much as possible.
However, as libstd contains more than 100,000 lines (!!!) and 600 unsafe functions, this should be done step by step, and by multiple people. This issue is meant as a way of tracking and synchronizing progress.

cc @nikomatsakis @RalfJung

Mentoring instructions (or rather, suggested workflow)

Please first leave a comment here stating that you want to work on file xxx.rs or module xxx, to make sure that this implements Sync.

You'll first want to add a #![deny(unsafe_op_in_unsafe_fn)] attribute in the scope you'll be working on.
Then, add unsafe blocks around unsafe operations in unsafe functions. These unsafe operations can be found either by searching for unsafe fns, or by running ./x.py check src/libstd and looking at the errors.
When adding an unsafe block, try to explain why it is safe in a safety comment before the unsafe block. This should look like:

// SAFETY: explain why `unsf` is safe here...
unsafe {
    unsf();
}

Example PRs: #72709 (for liballoc) and #73622 (for libcore)

TODO list

• alloc.rs (@poliorcetics, Deny unsafe operations in unsafe functions in libstd/alloc.rs #74333)
• fs.rs (@eltonlaw, #[deny(unsafe_op_in_unsafe_fn)] in libstd/fs.rs #73909)
• panicking.rs (@poliorcetics, Std panicking unsafe block in unsafe fn #74200)
• path.rs (@hellow554, deny(unsafe_op_in_unsafe_fn) in libstd/path.rs #73963)
• primitive_docs.rs
• process.rs (@hellow554, deny(unsafe_op_in_unsafe_fn) in libstd/process.rs #73955)
• sys_common/ (@LeSeulArtichaut, Deny unsafe ops in unsafe fns in std::sys_common #73928)
• net/tcp.rs (@ryr3, libstd/net/tcp.rs: #![deny(unsafe_op_in_unsafe_fn)] #73962)
• io/ (@ryr3)
• ffi/c_str.rs (@poliorcetics, deny(unsafe_op_in_unsafe_fn) in libstd/ffi/c_str.rs #74062)
• sync/mpsc (@poliorcetics, Deny unsafe operations in unsafe fns in libstd/sync/ #74278)
• thread/ (@poliorcetics, Std/thread: deny unsafe op in unsafe fn #74225)
• sys/
  • sys/cloudabi (@chansuke, #[deny(unsafe_op_in_unsafe_fn)] in sys/cloudabi #75115)
  • sys/hermit (@maekawatoshiki, #![deny(unsafe_op_in_unsafe_fn)] in sys/hermit #74979)
  • sys/sgx (@Caduser2020, #[deny(unsafe_op_in_unsafe_fn)] in sys/sgx #77346)
  • sys/unix (@euclio)
  • sys/unsupported (@m-ou-se, Remove unsafety from sys/unsupported and add deny(unsafe_op_in_unsafe_fn). #77722)
  • sys/vxworks
  • sys/wasm (@chansuke, #[deny(unsafe_op_in_unsafe_fn)] in sys/wasm #74477)
  • sys/wasi (@Amjad50, Applied #![deny(unsafe_op_in_unsafe_fn)] in library/std/src/wasi #75971)
  • sys/windows (unclaimed, previous attempt: Apply #![deny(unsafe_op_in_unsafe_fn)] to sys/windows #76676)

[euclio]

I'd like to work on sys/unix.

[eltonlaw]

I'd like to work on fs.rs

[ryr3]

I'd like to take up net/tcp.rs

[hellow554]

Took care of process.rs in #73955

What do you expect for primitive_docs.rs?

[LeSeulArtichaut]

What do you expect for primitive_docs.rs?

I built that list by running ripgrep to find occurrences of "unsafe fn" and blindly copied it. You’re right, there’s nothing to do, obviously since everything is comments :D

[retep998]

I'd like to be pinged on any PRs that touch windows bits.

[hellow554]

FYI: #73909 has been merged and now #![feature(unsafe_block_in_unsafe_fn)] is activated in libstd/lib.rs

[ryr3]

Can I try working on the io part once this is merged?
This one-liner to open the files that contain unsafe fns might be useful to someone working on this. Just thought I'd share!

grep -l -d recurse 'unsafe fn' io | xargs vim # Or your editor

[LeSeulArtichaut]

Can I try working on the io part once this is merged?

@ryr3 please go ahead!

[ryr3]

I started to work on it and saw that some files required other crates which need to be changed first.
For example, stdio imports thread/local.rs which has many unsafe fns. This leads to an error when running ./x.py check src/libstd
Is there any way to get around this, or will thread/local.rs have to be fixed first?

[LeSeulArtichaut]

I started to work on it and saw that some files required other crates which need to be changed first.
For example, stdio imports thread/local.rs which has many unsafe fns. This leads to an error when running ./x.py check src/libstd
Is there any way to get around this, or will thread/local.rs have to be fixed first?

I think that's only macros being problematic. You cannot put unsafe blocks in the macro, because it will make use sites which aren't using #[deny(unsafe_op_in_unsafe_fn)] fail to compile because of the "unnecessary unsafe block" warning. And there's no quick fix, because the macros defined in thread/local.rs are also used in other crates so you can't just slap an #[allow(unsafe_op_in_unsafe_fn)] in the macro. I think this is definitely an issue, but which is going to disappear when we stabilize #![feature(unsafe_block_in_unsafe_fn)]. cc @nikomatsakis for advice on this.

[LeSeulArtichaut]

Also cc @RalfJung as this problem might have an impact on the design of the feature.

[carbotaniuman]

I'll take sys/windows.

[ghost]

I would like to take sys/sgx.

[m-ou-se]

sys/unsupported is missing in the list. That one was not much work: #77722

sys/vxworks will be mostly fixed by #77666

[ghost]

sys/sgx merged in #77346.

[Mark-Simulacrum]

I have adjusted the E- tag here to E-hard, because for the most part, correctly checking the requirements and determining the appropriate safety comment to write is not an easy task. It might be a medium task (unclear), but it feels hard to me.

[RalfJung]

@LeSeulArtichaut @ryr3 @euclio @carbotaniuman you are currently "registered" at the top of this issue for various parts of std to be ported to unsafe_op_in_unsafe_fn. However, there doesn't seem to have been progress in a while -- do you still plan to pick this up, or can I remove your names from the issue so others can pick it up if they want to?

[carbotaniuman]

Feel free to take my name off, I think I put my name on before a hiatus and I don't remember this anymore.