Compiletest: add proc-macro header

[ehuss]

This adds a proc-macro header to simplify using proc-macros, and to reduce boilerplate. This header works similar to the aux-build header where you pass a path for a proc-macro to be built.

This allows the force-host, no-prefer-dynamic headers, and crate_type attribute to be removed. Additionally it uses --extern like aux_crate (allows implicit extern crate in 2018) and --extern proc_macro (to place in the prelude in 2018).

This also includes a secondary change which defaults the edition of proc-macros to 2024. This further reduces boilerplate (removing extern crate proc_macro;), and allows using modern Rust syntax. I was a little on the fence including this. I personally prefer it, but I can imagine it might be confusing to others. EDIT: Removed

Some tests were changed so that when there is a chain of dependencies A→B→C, that the @ proc-macro is placed in B instead of A so that the --extern flag works correctly (previously it depended on -L to find C). I think this is better to make the dependencies more explicit. None of these tests looked like the were actually testing this behavior.

There is one test that had an unexplained output change: tests/ui/macros/same-sequence-span.rs. I do not know why it changed, but it didn't look like it was particularly important. Perhaps there was a normalization issue?

This is currently not compatible with the rustdoc build-aux-docs header. It can probably be fixed, I'm just not feeling motivated to do that right now.

Implementation steps

• Document this new behavior in rustc-dev-guide once we figure out the specifics. Update //@ proc-macro aux build directive docs rustc-dev-guide#2149

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[jieyouxu]

Thanks. I'm very much in favor of reducing proc-macro boilerplate but changing the default edition for proc-macro tests as far as I can tell regresses our test coverage -- this is the one thing I'm not sure about. i.e.

This allows the force-host, no-prefer-dynamic headers, and crate_type attribute to be removed. Additionally it uses --extern like aux_crate (allows implicit extern crate in 2018) and --extern proc_macro (to place in the prelude in 2018).

This is great, thank you for the effort!

This also includes a secondary change which defaults the edition of proc-macros to 2024. This further reduces boilerplate (removing extern crate proc_macro;), and allows using modern Rust syntax. I was a little on the fence including this. I personally prefer it, but I can imagine it might be confusing to others.

This, however, I hesistant about. This means that test writers by default won't remember to cover older editions.

Very cool regardless.

[jieyouxu]

The compiletest change LGTM, I'll review the test diff tmrw.

[jieyouxu]

I manually looked through the tests, and AFAICT the transformations are correct.

[jieyouxu]

Thank you!

@ehuss would you like to update the rustc-dev-guide docs for proc-macro auxiliaries, or do you want me to?

In any case,

@bors r+ rollup=iffy

[bors]

📌 Commit f94142b has been approved by jieyouxu

It is now in the queue for this repository.

[jieyouxu]

@bors p=1 (conflict-prone)

[jieyouxu]

Actually I'll update the dev-guide docs.

[jieyouxu]

Something else came to my mind, actually: if we support transitive builds, i.e. auxiliary can itself declare auxiliaries, technically we can have a cycle... right? What happens then? Does compiletest explode? i.e. if aux A -> aux B but aux B -> aux A... Do we just, infinitely try to compile each other until we run out of disk space?

Whereas the previous scheme disallows auxiliaries from declaring auxiliaries themselves AFAIK, which is also what ui_test does AFAIK, to prevent such build cycles from being possible in the first place.

[jieyouxu]

@bors r- (one question)

[jieyouxu]

I agree that properly supporting transitive builds is something that would be desirable, but that might require proper cycle detection.

[ehuss]

I agree that properly supporting transitive builds is something that would be desirable, but that might require proper cycle detection.

That's nothing new, is it? This PR isn't changing that. Transitive builds have always been supported with aux-build and aux-crate, and compiletest has always had a stack overflow if it has a cycle.

[jieyouxu]

That's nothing new, is it? This PR isn't changing that. Transitive builds have always been supported with aux-build and aux-crate, and compiletest has always had a stack overflow if it has a cycle.

Hm, I think you're right, I might be misremembering as in ui_test may have introduced the restriction to fix this bug in compiletest 😅

@bors r+

[bors]

📌 Commit f94142b has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit f94142b with merge a2545fd...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing a2545fd to master...

[rust-timer]

Finished benchmarking commit (a2545fd): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (secondary -3.3%)

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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.3%	[-3.3%, -3.3%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (primary -2.5%, secondary 2.3%)

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)	2.3%	[2.3%, 2.3%]	1
Improvements ✅ (primary)	-2.5%	[-2.5%, -2.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-2.5%, -2.5%]	1

Binary size

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

Bootstrap: 792.194s -> 791.904s (-0.04%)
Artifact size: 335.92 MiB -> 335.89 MiB (-0.01%)