Convert a few builtin macros from LegacyBang to Bang

[joshtriplett]

Based atop #146849 .

Experiment to see if this impacts performance positively or negatively.

[joshtriplett]

@bors try @rust-timer queue

[rust-bors]

💔 Test for 49a017e failed: CI. Failed jobs:

• try - dist-x86_64-linux (web logs, extended logs)

[joshtriplett]

@bors try @rust-timer queue

[rust-bors]

💔 Test for 796d6cf failed: CI. Failed jobs:

• try - dist-x86_64-linux (web logs, extended logs)

[joshtriplett]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 9e8be47 (9e8be47f56e72ad50bea013465dee66408998eae, parent: f6092f224d2b1774b31033f12d0bee626943b02f)

[rust-timer]

Finished benchmarking commit (9e8be47): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.9%, secondary -4.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.9%	[-2.5%, -1.1%]	3
Improvements ✅ (secondary)	-4.4%	[-4.8%, -3.1%]	9
All ❌✅ (primary)	-1.9%	[-2.5%, -1.1%]	3

Cycles

Results (secondary 1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.3%	[2.6%, 4.5%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.9%	[-1.9%, -1.9%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 471.715s -> 472.281s (0.12%)
Artifact size: 389.94 MiB -> 387.91 MiB (-0.52%)

[petrochenkov]

I'll look a bit later, but I rejected something similar a few months ago (#125094 (comment)).
LegacyBang should probably be renamed to something less deprecated-looking.

[joshtriplett]

I'll look a bit later, but I rejected something similar a few months ago (#125094 (comment)). LegacyBang should probably be renamed to something less deprecated-looking.

The only reason I was looking into this was the possibility that macro_rules! might be able to use Bang in the future, once we fully jettison the support for allowing ; in expression macros. (macro_rules! already generates tokens, and AFAICT it's just using the context-sensitive AST-generation support to determine whether it's in an expression context for the purposes of the ; compatibility hack.) I wanted to find out whether, once that happened, it might make sense to convert other macros. Having performance data seemed useful.

It seems roughly performance neutral (seems more like noise from touching macros at all, rather than anything to do with line/column), but at the same time, it does seem like a waste of time to go through tokens rather than AST.

I'm going to close this; it's not worth reviewing.

[petrochenkov]

the possibility that macro_rules! might be able to use Bang in the future

Yeah, for macro_rules switching to a "tokens -> tokens" expander makes sense.