Suggestion: hmm, this is also one of those cases where it's better to identify which mir opts are involved, like #133104. Probably split this off into another PR.

as far as I understand this only enables mir inlining.
does Zinline-mir also enable other opts than mir inlining?

cc @saethlin do you know? I'm not super familiar with the MIR-specific ones.

I'm not too convinced that this is too useful in general.
If we for example have a broken mir opt in the pipeline, and the mir opt gets banished to -Zunsave-mir-opts, this still fixes the bug from a user perspective as the mir opt is no longer run by default.

Also some mir opts rely on each other which is why I don't fuzz single mir opts, as there are probably bunch of cases where "one opt will break if that other opt is not run before it."

Since this is a crashes test we can also remove it easily if it becomes a problem, so yeah it's a whatever.

does Zinline-mir also enable other opts than mir inlining?

-Zinline-mir is the same as -Zmir-enable-passes=+Inline, and it takes work to make sure those flags don't diverge in behavior.

there are probably bunch of cases where "one opt will break if that other opt is not run before it."

There aren't supposed to be any such cases.

If we for example have a broken mir opt in the pipeline, and the mir opt gets banished to -Zunsave-mir-opts, this still fixes the bug from a user perspective as the mir opt is no longer run by default.

The crashes tests aren't about tracking the quality of the user experience, they are about tracking the state of open issues. If an ICEing MIR opt is put behind a flag, the bug is still in the code.