We have a semantically relevant inlining pass? #597
Description
I was just made aware of rust-lang/rust#134082, which is a concerning PR: it seems to add an inlining pass that cannot be disabled. This is something that should have involved t-opsem and maybe even t-lang since it affects which code has UB.
I don't think we should have any MIR transforms that remain enabled under mir-opt-level=0, except for the ones that transform the MIR from one dialect to another -- at the moment, that should be drop elaboration and nothing else. Every such MIR transform is semantically relevant and needs to be accounted for in the documentation of what is and is not UB.
For the concrete example of inlining, rust-lang/rust#134082 had the side-effect of removing UB related to violating the Stacked Borrows protectors of references passed to force-inline functions. Was it an intended part of the PR to remove such UB? I assume not, since surely someone would have pinged t-opsem. So please take this into account for future work on MIR transforms: everything that can't be turned off becomes part of the opsem!
And then the next question is -- why is it so important that these functions be inlined that we have to adjust the opsem to make it happen? I found no use of rustc_force_inline in the standard library. The PR mentions ROP gadgets for pointer authentication instructions; those are AFAIK concerns that live outside the opsem so they should be resolved in a way that does not impact the opsem or Miri.