Give built-in macros stable addresses in the standard library

[petrochenkov]

Continuation of #62086.

Derive macros corresponding to traits from libcore are now available through the same paths as those traits:

• Clone - {core,std}::clone::Clone
• PartialEq - {core,std}::cmp::PartialEq
• Eq - {core,std}::cmp::Eq
• PartialOrd - {core,std}::cmp::PartialOrd
• Ord - {core,std}::cmp::Ord
• Default - {core,std}::default::Default
• Debug - {core,std}::fmt::Debug
• Hash - {core,std}::hash::Hash
• Copy - {core,std}::marker::Copy

Fn-like built-in macros are now available through libcore and libstd's root module, by analogy with non-builtin macros defined by libcore and libstd:

{core,std}::{
    __rust_unstable_column,
    asm,
    assert,
    cfg,
    column,
    compile_error,
    concat,
    concat_idents,
    env,
    file,
    format_args,
    format_args_nl,
    global_asm,
    include,
    include_bytes,
    include_str,
    line,
    log_syntax,
    module_path,
    option_env,
    stringify,
    trace_macros,
}

Derive macros without a corresponding trait in libcore or libstd are still available only through prelude (also see #62507).
Attribute macros also keep being available only through prelude, mostly because they don't have an existing practice to follow. An advice from the library team on their eventual placement would be appreciated.

    RustcDecodable,
    RustcEncodable,
    bench,
    global_allocator,
    test,
    test_case,

r? @alexcrichton

[alexcrichton]

As for my opinions about the other attributes, I think in general this is a good PR and wouldn't want to bog it down too much with where to put the remaining macros. They're pretty inconsequential so I think it's fine to deal with them in follow-up PRs. That being said some thoughts I'd have are:

• Encodable/Decodable - being removed soon in Remove derives Encodable/Decodable and unstabilize attribute #[bench] #62507 (yay!) so probably not too relevant
• RustcEncodable/RustcDecodable - I think it's fine to relegate these to "only in the prelude" for now, there's basically zero new users of these macros so it's basically a game of "what's the minimum we can do to keep what's working still working"
• global_allocator - my guess would be core::alloc as a good place for this.
• test, test_case, bench - my hunch is that as we stabilize #[test_case] we're going to create a std::test module. In that world they'd naturally all fit into std::test. For now though I think leaving them in the prelude is fine.

[alexcrichton]

I'm tweaking the tags since I'll run this through rfcbot once some of the review above has been addressed.

[petrochenkov]

Updated.

• Derive macros are moved into modules to avoid reexports.
• pub macro is converted to #[macro_export] macro_rules (which is automatically placed into the root) for fn-like macros to avoid more reexports.
• Other comments are addressed.

[alexcrichton]

@rfcbot fcp merge

Ok this all looks great to me, thanks again @petrochenkov!

As a heads up to the @rust-lang/libs folks, this is a follow-up to #62086 where builtin macros now are earning stable locations throughout the standard library (e.g. libcore and libstd). The diff is pretty easy to read and the description is comprehensive as well. Want to get a sign off though since this will actually affect some stable surface area!

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Kimundi
• @SimonSapin
• @alexcrichton
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[SimonSapin]

When defining a proc macro, the choice of using #[proc_macro] v.s. #[proc_macro_derive(…)] v.s. #[proc_macro_attribute] determines what kind of macro it is.

What is the equivalent of that for pub macro items? For example, what in this PR makes #[derive(Clone)] valid but not Clone!(…) ?

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[petrochenkov]

@SimonSapin
The compiler maintains a pre-defined map Map<Name, Signature> of built-in macros.
When the compiler sees a "lang item" macro (#[rustc_builtin_macro]) , it looks it signature up in that map. The macro kind (bang/attr/derive) is a part of that signature.

This machinery was implemented earlier in #62086 rather than in this PR.

[SimonSapin]

If the signature is built into the compiler, does that mean the $item:item part of pub macro Clone($item:item) { /* compiler built-in */ } is ignored? (Except perhaps by rustdoc?)

[petrochenkov]

Yes, the $item:item is for rustdoc.

[SimonSapin]

Sounds good, thanks!

[bors]

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

[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.

The RFC will be merged soon.

[alexcrichton]

r=me with a rebase

[petrochenkov]

@bors r=alexcrichton

[bors]

📌 Commit cbcc7dd has been approved by alexcrichton

[bors]

⌛ Testing commit cbcc7dd with merge a08d919ea24688f29f3a734c5e45c558bc5f4047...

[Centril]

@bors retry rolled up.

[bors]

⌛ Testing commit cbcc7dd with merge d19a359...