Investigate why repr-128-dwarf doesn't fail in CI test jobs

[jieyouxu]

I'm not sure why this passes in CI though. Surely we have some jobs that enable LLVM assertions? Seems like not, test jobs typically don't enable LLVM assertions due to slowness.

That doesn't sound right. LLVM assertions are supposed to be enabled for all test jobs, except those marked NO_LLVM_ASSERTIONS, which is only the apple ones.

Originally posted by @nikic in #138254

[jieyouxu]

See also #138254 (comment):

For reference, this issue is being caused by debuginfo for std enums being included in the binary built by the test. Testing locally with the config from #138254 (comment), the issue seems to also require download-rustc.

[jieyouxu]

Thread: #t-compiler > tests/run-make/repr128-dwarf @ 💬

[ehuss]

I think I understand what happened.

• The tests/run-make/repr128-dwarf test would fail if std had debuginfo-level-std set.
• None of the jobs that run that test have debuginfo-level-std set.
• All the builds from when it was introduced in Add DWARF test case for non-C-like repr128 enums #137643 were modifying things like the compiler or bootstrap, and so were not downloading rustc.
  • The cargo update was the first one that used the download rustc logic.
• The download rustc logic (uncertain?) downloads a rustc from a dist builder that does have debuginfo-level-std set.
  • Thus the test failed only when downloading rustc.

I'm not sure what the best resolution would be. Some ideas:

• Make sure the download-rustc logic only downloads a rustc that has the exact same configuration as the current build.
  • I think this would prevent the download-rustc logic from working on many jobs.
  • This may be difficult to implement or keep in sync.
  • We could have each job cache its own rustc separately instead of sharing. Not sure how expensive or complicated that would be.
• Introduce some builder that runs tests with debuginfo enabled so that we have better coverage of that scenario (since that is how most users are using Rust).
  • Or enable it on all test builders? I don't know how expensive it is, but I assume it is expensive.
• Do nothing and hope a similar scenario doesn't happen.

[jieyouxu]

I think it may be worth trying to enable it on at least some test builders, subject to the usual CI build time efforts.

[jieyouxu]

And for compiletest side, I think that test probably needs to be gated by sth like

//@ min-std-debuginfo-level: 2