Stabilize unsafe_op_in_unsafe_fn lint

[LeSeulArtichaut]

This makes it possible to override the level of the unsafe_op_in_unsafe_fn, as proposed in #71668 (comment).

Tracking issue: #71668
r? @nikomatsakis cc @SimonSapin @RalfJung

Stabilization report

This is a stabilization report for #![feature(unsafe_block_in_unsafe_fn)].

Summary

Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside.

The unsafe_op_in_unsafe_fn lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block.

For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level.

For more information, see RFC 2585

Example

// An `unsafe fn` for demonstration purposes.
// Calling this is an unsafe operation.
unsafe fn unsf() {}

// #[allow(unsafe_op_in_unsafe_fn)] by default,
// the behavior of `unsafe fn` is unchanged
unsafe fn allowed() {
    // Here, no `unsafe` block is needed to
    // perform unsafe operations...
    unsf();
    
    // ...and any `unsafe` block is considered 
    // unused and is warned on by the compiler.
    unsafe {
        unsf();
    }
}

#[warn(unsafe_op_in_unsafe_fn)]
unsafe fn warned() {
    // Removing this `unsafe` block will
    // cause the compiler to emit a warning.
    // (Also, no "unused unsafe" warning will be emitted here.)
    unsafe {
        unsf();
    }
}

#[deny(unsafe_op_in_unsafe_fn)]
unsafe fn denied() {
    // Removing this `unsafe` block will
    // cause a compilation error.
    // (Also, no "unused unsafe" warning will be emitted here.)
    unsafe {
        unsf();
    }
}

[crlf0710]

Triage: there's merge conflicts now.

[crlf0710]

@LeSeulArtichaut Ping from triage. Any updates here?

[LeSeulArtichaut]

Opened #81110, marking as blocked on that

[nikomatsakis]

@bors r+

[bors]

📌 Commit ec20993 has been approved by nikomatsakis