Syntactically permit unsafety on mods

[dtolnay]

Similar to #66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust.

#[mymacro]
unsafe mod m {
    ...
}

#[mymacro]
unsafe extern "C++" {
    ...
}

The intention is that this might be used as a kind of "item-level unsafe" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx.

In the absence of a procedural macro rewriting them to something else, they'll continue to be rejected at compile time though with a better error message than before.

Before:

error: expected item, found keyword `unsafe`
 --> src/main.rs:1:1
  |
1 | unsafe mod m {
  | ^^^^^^ expected item

After:

error: module cannot be declared unsafe
 --> src/main.rs:1:1
  |
1 | unsafe mod m {
  | ^^^^^^

error: extern block cannot be declared unsafe
 --> src/main.rs:4:1
  |
4 | unsafe extern "C++" {
  | ^^^^^^

Closes #68048.

[rust-highfive]

r? @ecstatic-morse

(rust_highfive has picked a reviewer for you, use r? to override)

[dtolnay]

r? @joshtriplett, since this is related to our discussion from yesterday.

[nagisa]

Nicer error messages!

I wonder why rustfmt/hir lowering avoided being changed at all. Other than that this LGTM!

also cc @petrochenkov

[dtolnay]

@nagisa:

I wonder why rustfmt/hir lowering avoided being changed at all.

• rustfmt: The code is not in this repo. As I understand it, after this PR lands in master, it gets published to rustc-ap-rustc_ast by https://github.com/alexcrichton/rustc-auto-publish, then we land the appropriate upgrade in rustfmt similar to rustfmt 1.x bump rustc-ap to v671 rustfmt#4356, then bump the rustfmt git submodule back here.
• hir lowering: Nothing here involves HIR, only AST. The syntax fails AST validation and never makes it to HIR.

[nagisa]

never makes it to HIR.

What I expected to see is a change to exhaustive match somewhere in HIR lowering, but looks like that goes through the visitor system.

[dtolnay]

Seems like that happens here and here. There isn't an exhaustive match, we just avoid accessing the new unsafety fields of Mod and ForeignMod.

[dtolnay]

I'll leave assigned to @joshtriplett for the lang FCP but request review from @estebank on the implementation.

[dtolnay]

• Rebased to resolve conflict with Move almost all compiler crates to compiler/ #74862.

[dtolnay]

• Rebased to resolve conflict with Factor out StmtKind::MacCall fields into MacCallStmt struct #76132 in import statements of compiler/rustc_expand/src/expand.rs.

[bors]

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[nagisa]

I’m just going to call this r=me.

I don’t see any problems with the implementation or the idea behind it. The diagnostic improvements are nice and there are no semantic changes to the language, so its all benefits.

[nagisa]

r? @nagisa

[nagisa]

@bors r+

[bors]

📌 Commit fd4dd00 has been approved by nagisa