Test that the compiler/library builds with validate-mir

[chenyukang]

Fixes #105706

[rustbot]

r? @jyn514

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

[saethlin]

@jyn514 I think this is good to go now, the fix just merged

[chenyukang]

@saethlin
Seems some UI are still failing, I rebased with master.

[saethlin]

Ah, those are not going to pass as a result of any other PR, you need to do something here to get their output back to what they're supposed to be. Probably we want to default all test suites to MIR opt level 3, except for the mir-opt suite.

You'll probably also run into breakage in codegen or debuginfo tests from changing their MIR opt level, that might resolve itself when #105577 lands.

[jyn514]

Ah, those are not going to pass as a result of any other PR, you need to do something here to get their output back to what they're supposed to be. Probably we want to default all test suites to MIR opt level 3, except for the mir-opt suite.

That implies we need to not set mir-opt-level for the mir-opt test suite, right? So this change probably needs to happen at least partly in compiletest, not just bootstrap.

[chenyukang]

Ah, those are not going to pass as a result of any other PR, you need to do something here to get their output back to what they're supposed to be. Probably we want to default all test suites to MIR opt level 3, except for the mir-opt suite.

That implies we need to not set mir-opt-level for the mir-opt test suite, right? So this change probably needs to happen at least partly in compiletest, not just bootstrap.

Is it this line make compiletest run with different options?

https://github.com/rust-lang/rust/pull/105736/files#diff-79e3e43fa59f1f75c3e925ab874d736286eb2ac7e1e08f3b7f05bae1a67f082fR67

when in mir-opt mode, we set mir-opt-level here:
https://github.com/rust-lang/rust/blob/e3961864075eaa9e855e5eec6b4f148029684539/src/tools/compiletest/src/runtest.rs#LL1952

[chenyukang]

@saethlin
do you know why we add mir-opt-level for stage1 std will make mir-opt fail?

x test --stage 1 src/test/mir-opt

If so, we can not enable it for stage1 std.
I plan to enable it for test cases(except for those mir-opt testcases).

[saethlin]

Ah yeah I should have expected this. Let me do some experimentation (based on your branch) locally, I'll get back to you within a day.

[chenyukang]

Ah yeah I should have expected this. Let me do some experimentation (based on your branch) locally, I'll get back to you within a day.

Thanks, use this to reproduce it locally:

./configure --set rust.validate-mir-opts=3
x test --stage 1 src/test/mir-opt

[saethlin]

I think we're in a sticky situation here. What I originally envisioned was a fully separate step in CI where we only build and do not run any tests, we would just rely on the MIR validation. If that's possible to do, I think it is the best way to dodge the situation I will ramble on about now.

The problem you're running into is we compile the standard library ahead of time with a separate set of flags than are specified in mir-opt and codegen tests (and I suppose various other UI tests as well). So changing the build settings for the standard library will break tests when standard library functions get inlined into the tests. One other way around this is to always build the distributed standard library at the higher MIR opt level, then bless the tests. I'm told cranelift uses a higher MIR opt level for the standard library already, though based on gestures broadly I don't think I would advise doing that at this moment. (This also drags in the question of what happens to users of build-std, do they get a standard library with less optimizations because the default release build is mir opt level 2? That seems bad.)

[jyn514]

I think for now we should only land this for the standard library itself; I think that would have avoided most of the issues @saethlin mentioned in the past. We can worry about doing it for the test suite and compiler later.

[jyn514]

Oh I see, even doing it for just the standard library causes issues. That's ... very unfortunate.

We don't run any tests on mingw-check - maybe we can add this new check to only that builder? Then the different MIR output shouldn't cause any tests to fail.

I'm told cranelift uses a higher MIR opt level for the standard library already, though based on gestures broadly I don't think I would advise doing that at this moment. (This also drags in the question of what happens to users of build-std, do they get a standard library with less optimizations because the default release build is mir opt level 2? That seems bad.)

I don't think we should penalize all users just because some users wouldn't benefit. As long as we're not actively hurting build-std people, I don't think that should be a reason to avoid adding more optimizations for dist builds (Mark-Simulacrum has already said a few times people should use the official builds if they want to match performance characteristics anyway). But if you're not confident all the opt-level=2 opts are sound, we can avoid turning them on for now.

[jyn514]

This looks good to me! can you just verify by looking at the CI logs that validate-mir-opts is actually being passed to configure? github actions is being annoying and won't let me look at the full logs until the run finishes 😞 but it will look something like configure: build.configure-args := ['--set', 'rust.validate-mir-opts']

[jyn514]

ah, here it is: https://github.com/rust-lang/rust/actions/runs/4266886160/jobs/7427913259#step:26:1091

@bors r+

[bors]

📌 Commit 7d3457bb1220df1afac72eab41806c82cb67d250 has been approved by jyn514

It is now in the queue for this repository.

[jyn514]

oh sorry, can you fix #105736 (comment) first?

@bors r- delegate=chenyukang

(please use @bors r=jyn514 when you've fixed it :)

[bors]

✌️ @chenyukang can now approve this pull request

[bors]

📌 Commit 7d3457bb1220df1afac72eab41806c82cb67d250 has been approved by `jyn514``

It is now in the queue for this repository.

[jyn514]

@bors r-

[chenyukang]

@bors r=jyn514

[bors]

📌 Commit 001bcee has been approved by jyn514

It is now in the queue for this repository.