`safe` keyword is allowed in all function contexts

[ehuss]

The safe keyword appears to be allowed in all function contexts. However, the RFC explicitly says it should only be allowed in extern blocks:

The safe keyword is contextual and is currently allowed only within extern blocks.

#![feature(unsafe_extern_blocks)]

safe fn foo() {}

I expected to see this happen: Compile error

Instead, this happened: Compile success

cc @spastorino FYI

macro fragment

Additionally, it looks like safe fn foo(); is accepted in $item macro fragment specifier. I think there are different decisions to make here:

• Should $item allow safe functions at all? (I think "yes", since it already accepts extern-block items.)
• Should that be split out into a separate fragment, such as $item_2021 does not allow safe, and $item does in 2024? See Tracking Issue for updating expr macro fragment specifier for Rust 2024 #123742.

EDIT: Concluded below this should not be an issue.

Meta

rustc 1.81.0-nightly (59e2c01c2 2024-06-17)
binary: rustc
commit-hash: 59e2c01c2217a01546222e4d9ff4e6695ee8a1db
commit-date: 2024-06-17
host: aarch64-apple-darwin
release: 1.81.0-nightly
LLVM version: 18.1.7

Tracking:

• Tracking Issue for RFC 3484: Unsafe Extern Blocks #123743

[compiler-errors]

Should $item allow safe functions at all? (I think "yes", since it already accepts extern-block items.)

Yes, I don't think we need to be doing any context-specific parsing of macro item fragments. Validation that safe is only placed on items in an extern block should be done post-expansion IMO. That lets us write:

macro_rules! wrap_in_extern { ($i:item) => { unsafe extern { $i } } }

wrap_in_extern! { safe fn foo(); }

Should that be split out into a separate fragment, such as $item_2021 does not allow safe, and $item does in 2024?

We already allow item macro fragment specifiers start with the safe identifier, since safe might begin a macro item e.g. safe::hello_world! {}, so I don't think this is necessary.

[compiler-errors]

But to repeat myself just for clarity, I think we just need to do post-expansion validation of function signatures to guarantee that safe is only written on items in extern blocks.

[ehuss]

Another issue appears that safe is not feature-gated. The following seems to build without a feature gate:

safe fn foo() {}

[compiler-errors]

Thanks. I'll fix the feature gating at least, since it's regressed to beta. Let me break that out into another issue.

[spastorino]

Thanks @compiler-errors your fix at least make this thing not compile. I'm going to fix the underlying issue that I think started to happen as I ended going to a scheme where we have hir::Safety (safe|unsafe) and we do not have a default variant. I'm pretty sure that this thing originally wasn't happening but I've failed to add tests for this.
Anyway, going to fix this.