Stabilize unsafe extern blocks (RFC 3484)

[spastorino]

Stabilization report

Summary

This is a tracking issue for the RFC 3484: Unsafe Extern Blocks

We are stabilizing #![feature(unsafe_extern_blocks)], as described in Unsafe Extern Blocks RFC 3484. This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use.

RFC: rust-lang/rfcs#3484
Tracking issue: #123743

What is stabilized

Summary of stabilization

We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results.

unsafe extern {
    // sqrt (from libm) may be called with any `f64`
    pub safe fn sqrt(x: f64) -> f64;

    // strlen (from libc) requires a valid pointer,
    // so we mark it as being an unsafe fn
    pub unsafe fn strlen(p: *const c_char) -> usize;

    // this function doesn't say safe or unsafe, so it defaults to unsafe
    pub fn free(p: *mut core::ffi::c_void);

    pub safe static IMPORTANT_BYTES: [u8; 256];

    pub safe static LINES: SyncUnsafeCell<i32>;
}

Tests

The relevant tests are in tests/ui/rust-2024/unsafe-extern-blocks.

History

• Unsafe extern blocks #124482
• Add new safety enum for inner extern items #124455
• Rename Unsafe to Safety #125077
• Add "better" edition handling on lint-docs tool #125522
• unsafe blocks do not fire unsafe_code lint #126738
• safe keyword is allowed in all function contexts #126749
• safe keyword is not feature-gated #126755
• Properly gate safe keyword in pre-expansion #126757
• Do not allow safe/unsafe on static and fn items #126758
• Bad replacement for unsafe extern block suggestion #126756
• Fix bad replacement for unsafe extern block suggestion #126973
• Fire unsafe_code lint on unsafe extern blocks #127535
• format safety keywords on static items rustfmt#6204

Unresolved questions

I am not aware of any unresolved questions.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[spastorino]

r? @traviscross

I wasn't sure if I should leave this as a draft but would leave all this up to t-lang.

[oli-obk]

default items with no modifiers are unsafe to keep backwards compatibility.

We don't need back compat when unsafe is added to the extern block, why do we have this rule?

[spastorino]

default items with no modifiers are unsafe to keep backwards compatibility.

We don't need back compat when unsafe is added to the extern block, why do we have this rule?

Well ... is not really about backwards compatibility and when I wrote this, I kind of knew that I wasn't properly explaining myself. What I meant was ... if we were to flip default safety to safe, it would not only be surprising but would may also led to end with something that was unsafe being safe when you migrate.
Imagine ...

extern "C" {
    fn foo();
    // foo is unsafe
}

When I migrate my code I do ...

unsafe extern "C" {
    fn foo();
    // now foo is safe
}

if the semantics of not providing safety is now being safe this would be a disaster.

This is what I meant in that text, but written really poorly :). If you want to suggest an edit, I'd be happy to apply it.

[workingjubilee]

It is best to avoid the phrase "backwards compatibility", as it is clear that it means different things to different people. For some, it means to keep code that currently exists compiling. For others, they primarily mean preserving functional equivalence if the code is recompiled, but not necessarily allowing it to still compile (e.g. rejecting unsound code). For others, it means offering easy migration to a new paradigm that does not have surprising results.

[workingjubilee]

Is it possible to write k#safe in previous editions? Did we ever commit to that prefix?

[workingjubilee]

@spastorino Would you please update your stabilization report to explain the finer-grained implementation choices that have been made? e.g. why safe is now parsed in previous editions, and whether safe is a restricted keyword in later editions? The RFC focused on Edition 2024, mostly.

...and is unsafe static now accepted outside extern "C"?

[workingjubilee]

...yes, without a feature gate, on a recent nightly? And beta?

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=a5e84d4d6df2b38d60fe18a44e1a2087

https://rust.godbolt.org/z/qdcreaqrh

...Could the stabilization report also explain why we decided to accept unsafe static outside extern "C"? Or reject it, if the implementation decides to change on that, that's fine too.

[compiler-errors]

#127943 fixes that last part. It was accidental afaict.

[spastorino]

@workingjubilee, first I've updated the stabilization report to avoid mentioning backwards compatibility and explained in terms of avoiding surprising effects.

why safe is now parsed in previous editions, and whether safe is a restricted keyword in later editions? The RFC focused on Edition 2024, mostly.

I did a short summary because I didn't want to repeat most of what is said in the RFC. Related to this very specific thing, from the RFC:

In all editions, items within unsafe extern blocks may be marked as safe to use.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

@bors r+

[bors]

📌 Commit 8366c7f has been approved by compiler-errors

It is now in the queue for this repository.

[Kobzol]

@rust-timer build 6841bd3

[rust-timer]

Finished benchmarking commit (6841bd3): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.9%	[0.4%, 1.3%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (primary -1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.5%	[-1.5%, -1.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.5%	[-1.5%, -1.5%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 758.56s -> 757.756s (-0.11%)
Artifact size: 336.83 MiB -> 336.85 MiB (0.00%)

[compiler-errors]

Probably has to do with the ungated edition check for extern block spans. I don't think this can be fixed 🤔

[Kobzol]

Understood, thanks. I'll mark the rollup as triaged then.

@rustbot label: +perf-regression-triaged