Migrate symbols to use declarative macro.

[fee1-dead]

Pros:

• faster build times
• completion for IDE users
• easier to understand

Cons:

• check for duplicates and alphabetical order is moved to tidy

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[bjorn3]

Another con: With a proc macro it would have been possible to precompute hashes of all symbols to make building the symbol interner faster.

[petrochenkov]

IIRC, it was migrated from a declarative to procedural macro only 1-2 years ago.

[fee1-dead]

With a proc macro it would have been possible to precompute hashes of all symbols to make building the symbol interner faster.

Yes, but how would that work with FxHashMap? With some improvements to CTFE I think this can be done in const contexts in the near future.

IIRC, it was migrated from a declarative to procedural macro only 1-2 years ago.

Actually 3 years ago. It was #59655. You commented that if we could use macro_rules then we should use macro_rules.

We could also test the performance:

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 1a53e93 with merge a08229a10eb3728f98c4b330da365247e3d8a90b...

[bors]

☀️ Try build successful - checks-actions
Build commit: a08229a10eb3728f98c4b330da365247e3d8a90b (a08229a10eb3728f98c4b330da365247e3d8a90b)

[rust-timer]

Queued a08229a10eb3728f98c4b330da365247e3d8a90b with parent 2310da4, future comparison URL.

[bjorn3]

FxHashMap has the raw_entry api which allows providing the hash directly AFAIK.

[bjorn3]

With some improvements to CTFE I think this can be done in const contexts in the near future.

Even if it could it may still be slower.

[rust-timer]

Finished benchmarking commit (a08229a10eb3728f98c4b330da365247e3d8a90b): comparison url.

Summary:

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: changes not relevant. 1 results were found to be statistically significant but the changes were too small to be relevant.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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

[Mark-Simulacrum]

I am not entirely convinced by this change -- the diagnostics cycle seems likely to be worse (a proc-macro gives you immediate feedback), and the macro itself is not as digestible to me. Proc macros are a little clunky, but macro-rules at least as it stands today forces into annoying and not easily comprehensible hacks like ____anchor here. (FWIW, it seems like using https://doc.rust-lang.org/nightly/std/mem/fn.variant_count.html should be a better fit there).

I think in terms of benefits, the strongest one is probably the completion for IDE users, but it was my recollection that rust-analyzer (and presumably eventually other IDEs) already support completion with proc-macros in some cases. Maybe there's something we can adjust to make that feasible? For example, with some adjustments, it might be possible to make most of this derive-macro capable, emitting some constants on the side to talk to the other macros -- that would probably greatly improve the IDE story?

[fee1-dead]

I am going to close this in favor of rust-lang/rust-analyzer#11956 which would allow customizing how rust-analyzer runs build scripts and expands procedural macros. A followup PR after that to rustc should make IDE support a lot better for procedural macros.