rustc_interface: Add a new query pre_configure

[petrochenkov]

It partially expands crate attributes before the main expansion pass (without modifying the crate), and the produced preliminary crate attribute list is used for querying a few attributes that are required very early.

Crate-level cfg attributes on the crate itself are then expanded normally during the main expansion pass, like attributes on any other nodes.
This is a continuation of #92473 and one more step to very unstable crate-level proc macro attributes maybe actually working.

Previously crate attributes were pre-configured simultaneously with feature extraction, and then written directly into ast::Crate.

[rustbot]

r? @michaelwoerister

(rustbot has picked a reviewer for you, use r? to override)

[petrochenkov]

@bjorn3
I remember your PR introducing the DEPRECATED_CFG_ATTR_CRATE_TYPE_NAME lint, I didn't think about it in too much detail back then, but now I'm not sure that lint makes much sense.

There are 10 attributes that are used as early as crate_type and crate_name

compiler_builtins
crate_name
crate_type
feature
no_core
no_implicit_prelude
no_std
plugin
recursion_limit
register_tool

, i.e. before the crate root is actually expanded by the main expansion pass (expand_crate).
(See uses of pre_configured_attrs in this PR.)

I don't think it's feasible to delay use of all (*) of these attributes to post-expansion.
So we won't be able to get rid of this "pre-configuration" as a concept.
So we can continue using it for crate_type and crate_name as well, and do not produce warnings.

However, we need to produce an error if any of these attributes appears after expansion of a crate-level procedural macro attribute.

(*) Some of them could potentially be delayed though. It would be nice, because in that case they would work even if produced by crate-level procedural macros.

[bjorn3]

crate_name and crate_type affect what the output files are and as such need to be known by the driver. This for example results in us having to modify the Session after it was constructed. If we push back incr comp much further this is going to hurt I think. Disallowing incr comp allows us to scan for crate_type amd crate_name attributes before creating the Session. All other attributes you listed only affect the content of the compilation and not what files are produced or the Session.

Another reason is gccrs which can't really support conditional crate_name and crate_type because as I understand it to the driver needs to know these things before invoking the actual compiler executable (which does macro expansion) to pass the right arguments. Even ignoring this I think rustc itself benefits from it.

[petrochenkov]

This should probably be run through crater.
@bors try

[bors]

⌛ Trying commit 13a91c09c660eba2434e10b49b8cc99795d085cb with merge 8df314f433990f5163039edae8245e89581f72ca...

[bors]

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

[petrochenkov]

@craterbot check

[craterbot]

👌 Experiment pr-108221 created and queued.
🤖 Automatically detected try build 8df314f433990f5163039edae8245e89581f72ca
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-108221 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[michaelwoerister]

Thanks for the PR, @petrochenkov! I'll take a closer look shortly.

[craterbot]

🎉 Experiment pr-108221 is completed!
📊 104 regressed and 0 fixed (255796 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[petrochenkov]

@rust-lang/infra
A lot of "No space left on device" errors in this crater report.
Not sure whether it's expected or not.

[petrochenkov]

Quite a few regressions from 4cf92c4 (i.e. the fix for #104633).

It's mostly the "unknown feature" errors on fully unconfigured crates.

The second source of regressions is that fully unconfigured crates with #![no_std] annotations are considered no_std now and produce errors like "#[panic_handler] function required, but not found" because the panic handler is obviously configured away together with everything else.

So, in practice the attributes from the list in #108221 (comment) aren't supposed to be accounted for in fully-unconfigured crates, I guess.

[petrochenkov]

https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/binary-tree-0.2.0/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/daemon-engine-0.6.0/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/ecs-0.23.1/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/find-winsdk-0.2.0/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/hotg-runicos-base-wasm-0.11.3/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/lazy_static-1.1.1/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/merkle_light-0.4.0/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/promising-future-0.2.4/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/ruspiro-boot-0.5.4/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/ruspiro-cache-0.4.1/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/rwcell-0.1.2/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/tear-0.5.1/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/tokio-async-await-0.1.7/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/tuifw-screen-winapi-0.21.1/log.txt
https://crater-reports.s3.amazonaws.com/pr-108221/try%238df314f433990f5163039edae8245e89581f72ca/reg/vswhere-0.1.0/log.txt

plus almost everything in the build failed (unknown) group.

[petrochenkov]

#104633 (comment)

I'll try to implement this left-to-right amendment for a second crater run

[petrochenkov]

@bors try

[petrochenkov]

@bors retry

[petrochenkov]

@bors r=michaelwoerister

[bors]

📌 Commit aca1b1e has been approved by michaelwoerister

It is now in the queue for this repository.

[bors]

⌛ Testing commit aca1b1e with merge df7fd99...

[bors]

☀️ Test successful - checks-actions
Approved by: michaelwoerister
Pushing df7fd99 to master...

[rust-timer]

Finished benchmarking commit (df7fd99): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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)	-	-	0
Regressions ❌ (secondary)	1.2%	[0.6%, 2.1%]	4
Improvements ✅ (primary)	-3.7%	[-3.7%, -3.7%]	1
Improvements ✅ (secondary)	-2.0%	[-2.1%, -2.0%]	3
All ❌✅ (primary)	-3.7%	[-3.7%, -3.7%]	1

Cycles

Results

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)	-	-	0
Regressions ❌ (secondary)	0.7%	[0.4%, 0.9%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0