Convert some macros from LegacyBang to Bang.

[nnethercote]

Specifically: cfg!, column!, file!, line!, module_path!.

This requires changing BangProcMacro for F to use the ecx and span arguments, instead of ignoring them.

r? @petrochenkov

[nnethercote]

I don't know if this is a good idea or not, but I was curious and I converted a few of the easiest ones. There are several more than look easy. There are also harder ones like expand_env that return ExpandResult::Retry(()) if their arguments haven't been fully expanded. I don't know how to handle those.

[SparrowLii]

I think we can improve the return types here to handle ExpandResult::Retry(()) . e.g.

pub enum BangRetry {
    Yes,
    No,
}

impl<F> BangProcMacro for F
where
    F: Fn(&mut ExtCtxt<'_>, Span, TokenStream) -> Result<TokenStream, BangRetry>,
{
    fn expand<'cx>(
        &self,
        ecx: &'cx mut ExtCtxt<'_>,
        span: Span,
        ts: TokenStream,
    ) -> Result<TokenStream, (BangRetry, ErrorGuaranteed)> {
        self(ecx, span, ts).map_err(|retry| (retry, ErrorGuaranteed(())))
    }
}

[nnethercote]

It's a good suggestion. But I'll wait for feedback from @petrochenkov about whether converting LegacyBang to Bang is a good idea in general before putting more effort in.

@petrochenkov, what do you think?

[petrochenkov]

Right now built-in bang macros go through the next pipeline when expanding:

"Legacy" in eager positions in built-in macros: produced | AST | consumed
"Modern" in eager positions in built-in macros: produced | Tokens -> Parser -> AST | consumed
"Legacy" in normal positions: produced | AST | consumed
"Modern" in normal positions: produced | Tokens -> Parser -> AST | consumed

So currently we do not have any token-based eager expansion, we only ever consume AST, so we never need the token representation of builtin macros' outputs.
Therefore, the LegacyBang to Bang conversion only adds a performance cost of the unnecessary Tokens -> Parser step right now. (And also makes the macro implementations a bit more wordy, at least until we have some kind of quote! for writing them.)

When/if we have token-based eager expansions we will indeed need the built-in macro outputs in their token forms.
Eager expansions like this probably won't be common compared to regular macro calls, so we'll likely need to continue generate AST directly in most cases just for performance. Tokens will then be either produced from AST somehow (hopefully not by pretty-printing and reparsing) or just generated by an alternative token-based implementation supplied for each built-in macro.

Basically, I don't think we need to do this now.

[petrochenkov]

Very few macros are converted here, so I don't expect much perf difference, but let's try anyway.
@bors try @rust-timer queue

[bors]

⌛ Trying commit ca590a9 with merge 38deb65...

[bors]

☀️ Try build successful - checks-actions
Build commit: 38deb65 (38deb65e0d96b976877c54da863fbd9006c2f016)

[rust-timer]

Finished benchmarking commit (38deb65): comparison URL.

Overall result: ❌ regressions - no action needed

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

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.3%, 0.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

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

Binary size

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

Bootstrap: 673.262s -> 673.191s (-0.01%)
Artifact size: 315.60 MiB -> 315.71 MiB (0.03%)

[nnethercote]

Basically, I don't think we need to do this now.

Ok. My motivation was simple: I saw two ways of doing something, so I tried to take a step towards removing the one described as "legacy", to simplify things. Sounds like that's not appropriate.

[petrochenkov]

Sometimes things in the compiler are named "legacy" too soon.
At some point all macro_rules were referred as "legacy macros" internally (as opposed to "modern" macros 2.0).