Fix x test src/tools/error_index_generator --stage {0,1}

[jyn514]

There were two fixes needed:

1. Use top_stage instead of top_stage - 1. There was a long and torturous comment about trying to match rustdoc's version, but it works better without the hard-coding than with (before it gave errors that libtest.so couldn't be found).
2. Make sure that ci-llvm/lib is added to LD_LIBRARY_PATH. Previously the error index would be unable to load LLVM for stage0 builds.

At some point we should probably have a discussion about how rustdoc stages should be numbered;
confusion between 0/1/2 has come up several times in bootstrap now. cc #92538

Note that this is still broken when using download-rustc = true and --stage 1,
but that's really a corner case and should affect almost no one. --stage {0,2}
work fine with download-rustc.

Fixes #80096.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[yaahc]

fwiw, I've been running into the libllvm not found issue consistently recently, specifically the one consistent with nick's description here, and tested out this fix and it resolved the issue. I am eager for this to land.

[Mark-Simulacrum]

@bors r+

There was a long and torturous comment about trying to match rustdoc's version, but it works better without the hard-coding than with (before it gave errors that libtest.so couldn't be found).
...
At some point we should probably have a discussion about how rustdoc stages should be numbered;
confusion between 0/1/2 has come up several times in bootstrap now.

Yeah, I agree that there's work to be done here. The comment there was probably authored by me (too long ago for it to be in cache, but I recall vaguely). I think this patch is probably fine -- particularly given your testing -- though it may cause some additional builds in edge cases. I think our bootstrap tests should be largely catching any likely regressions, and my own CI timing scripts will catch anything on the slower builders, so I'm hopeful we're OK there.

We can revert or further iterate if this causes trouble to some workloads. My personal take has long been that consuming rustdoc as a library, not a binary, is a mistake and we should avoid it. I think the easiest way to do that is to just special-case any of the logic the error index wants behind a -Z flag and use that (rustdoc -Z ...) in combination with moving any generation logic into rustbuild itself. That should be fairly straightforward and will likely eliminate a good chunk of operational pain here.

[bors]

📌 Commit 7470592 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 7470592 with merge dc1f829...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing dc1f829 to master...

[rust-timer]

Finished benchmarking commit (dc1f829): comparison url.

Summary:

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: 😿 relevant regressions found

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	2	6	0	0	2
mean2	0.3%	1.0%	N/A	N/A	0.3%
max	0.3%	1.2%	N/A	N/A	0.3%

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[rylev]

Looks like the perf regressions here we just a blip. The run for the next PR shows the exact same test cases improving by the same amount as they regressed here. Going to remove the perf regression label since this isn't actually a regression at all.

@rustbot label: -perf-regression