Add builtin# for compiler-intrinsic syntax

[est31]

Proposal

Some of rust's builtin macros use their direct access to the AST to do things that proc macros can't: create AST nodes that are not present in syntax. This turns those macros into language extensions more than actual macros.

The proposed solution is to add the builtin#... syntax intended for constructs that are perma-unstable, possibly having stable wrappers, where no final syntax is known.

builtin# would always be followed by a conditional keyword that corresponds to the functionality of the construct, and then contain its arguments in parentheses. So asm!(foo) becomes builtin#asm(foo).

Possible cases of builtin#:

• the asm!/global_asm! macros
• there is a PRs open for format_args
• another PR is open for offset_of
• An eventual replacement for box syntax that is more of an implementation detail than a future feature at this point. It is still used in the vec macro thus can't be removed easily. This would free up box as a keyword.
• Any future language feature whose syntax is not decided yet but people want to experiment with it. E.g. do yeet comes to mind.

Acceptance of this MCP does not imply that all of these should be migrated. For the last few non-macro cases the migration discussion is explicitly left for the future. Mainly, the list serves to show the targeted area of builtin#.

Macros can be changed to macro_rules macros with an allow_internal_unstable (or alternatively macro macros).

Mentors or Reviewers

@petrochenkov has expressed desire for this.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[m-ou-se]

A bit of a tangent but related: having lang#… for lang items could also be very nice, at least for -Zunpretty=hir. Now, it uses #[lang=…] syntax whenever it refers to lang items, which gets weird:

match #[lang = "branch"](x) {
    #[lang = "Break"] {  0: residual } =>
        #[allow(unreachable_code)]
        return #[lang = "from_residual"](residual),
    #[lang = "Continue"] {  0: val } =>
        #[allow(unreachable_code)]
        val,
};

changing that to lang#Break (etc.) in the pretty printed hir output is trivial, but it might be cool if that would actually also become (permanently unstable) syntax to refer to lang items. (Useful for in rustc tests, etc. And it'd be nice if rustfmt understands it.)

(Or maybe we should rename 'lang items' to something that makes more sense first. ^^)

[clubby789]

Another potential use case is include_bytes, which expands to a custom AST node to avoid escaping large blobs

[pnkfelix]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted