Add support for macro expansion in rustdoc source code pages

[GuillaumeGomez]

This is what it looks like:

You can test it here. In this case, I also enabled the --generate-link-to-definition to show that both options work well together.

Note: There is a bug currently in firefox where the line numbers are not displayed correctly if they're inside the "macro expansion" span: https://bugzilla.mozilla.org/show_bug.cgi?id=1949948 Found a workaround around this bug.

r? @notriddle

[rustbot]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez, @jsha

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[notriddle]

Why is this done differently than the normal expand/collapse system, but in code and in presentation?

[GuillaumeGomez]

Because it would force to duplicate all the common code. For example in:

func(arg, macro!(blabla), arg3);

Only macro!(blabla) will be different, so it's not interesting to duplicate all the rest. Instead, we put the original code in a span, the expanded one in another and then we can simply switch them based on the status of the checked property of the input. I'm also not a big fan of our current details approach as it requires more JS to be working fully as expected but it's a debate for another time.

[rustbot]

This PR modifies tests/run-make/. If this PR is trying to port a Makefile
run-make test to use rmake.rs, please update the
run-make port tracking issue
so we can track our progress. You can either modify the tracking issue
directly, or you can comment on the tracking issue and link this PR.

cc @jieyouxu

[GuillaumeGomez]

I opened the firefox bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1949948

[bors]

☔ The latest upstream changes (presumably #137511) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

PR is ready for review.

[bors]

☔ The latest upstream changes (presumably #140702) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Fixed merge conflict.

[GuillaumeGomez]

Went around firefox bug, so now it's always displayed as expected.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[GuillaumeGomez]

Applied code improvement suggestions, improved code comments and added a test with a macro coming from another file.

[GuillaumeGomez]

Seems like I didn't forget one a test this time. :')

[lolbinarycat]

@bors r+

[bors]

📌 Commit d0913c5 has been approved by lolbinarycat

It is now in the queue for this repository.

[bors]

⌛ Testing commit d0913c5 with merge 809200e...

[bors]

☀️ Test successful - checks-actions
Approved by: lolbinarycat
Pushing 809200e to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 3776358 (parent) -> 809200e (this PR)

Test differences

Show 8 test diffs

Stage 1

• [rustdoc] tests/rustdoc/macro/macro_expansion.rs: [missing] -> pass (J0)

Stage 2

• [rustdoc] tests/rustdoc/macro/macro_expansion.rs: [missing] -> pass (J1)

Additionally, 6 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3
• J1: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-19-1, aarch64-msvc-1, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, x86_64-gnu, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 809200ec956983fce4ae178b87dada69f01d0820 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-aarch64-apple: 5659.3s -> 7302.3s (29.0%)
2. dist-x86_64-apple: 6082.1s -> 7300.1s (20.0%)
3. dist-x86_64-freebsd: 6041.5s -> 5076.3s (-16.0%)
4. dist-apple-various: 4593.0s -> 5239.3s (14.1%)
5. aarch64-msvc-1: 7438.1s -> 6639.5s (-10.7%)
6. x86_64-mingw-1: 10449.0s -> 9843.5s (-5.8%)
7. dist-arm-linux-gnueabi: 4979.6s -> 4692.3s (-5.8%)
8. dist-x86_64-mingw: 8851.6s -> 8378.5s (-5.3%)
9. aarch64-msvc-2: 4976.6s -> 4726.0s (-5.0%)
10. x86_64-gnu-llvm-19: 2396.5s -> 2508.7s (4.7%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (809200e): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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)	1.5%	[0.4%, 6.6%]	16
Regressions ❌ (secondary)	5.8%	[0.6%, 16.5%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.5%	[0.4%, 6.6%]	16

Max RSS (memory usage)

Results (primary 3.1%, secondary 4.6%)

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

	mean	range	count
Regressions ❌ (primary)	3.1%	[1.5%, 5.0%]	5
Regressions ❌ (secondary)	7.6%	[2.0%, 20.0%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.4%	[-3.0%, -2.2%]	3
All ❌✅ (primary)	3.1%	[1.5%, 5.0%]	5

Cycles

Results (primary 4.0%, secondary 14.1%)

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

	mean	range	count
Regressions ❌ (primary)	4.0%	[2.3%, 5.8%]	3
Regressions ❌ (secondary)	14.1%	[3.1%, 30.9%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.0%	[2.3%, 5.8%]	3

Binary size

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

Bootstrap: 467.391s -> 469.654s (0.48%)
Artifact size: 378.34 MiB -> 378.39 MiB (0.01%)

[GuillaumeGomez]

Sadly the perf impact was to be expected since it adds more code.

[klensy]

If this option turned off by default, it shouldn't slowdown anything (at least over noise level), weird.

[GuillaumeGomez]

It changed how the highlighting is working to handle the new case, and that is run all the time. I will need to rethink a bit how it works though because code could likely be better and less bad perf-wise.