Add a method to create an arbitrary OpTy from outside rustc_mir

[bjorn3]

r? @oli-obk

This is necessary to make priroda work again without the ugly catch panic hack at https://github.com/oli-obk/priroda/blob/0810d79b474f6ad66686c664925fd595f011c581/src/render/locals.rs#L39-L54.

[wesleywiser]

Can you expand a bit on why this shouldn't be used from inside rustc? Is it just that this operation is unchecked or does it violate some other assumption?

[bjorn3]

I thought that somebody wanted to prevent having a method like this to prevent accidental misusage or something like that, but in #55179 I can really find anything like that except for "I wanted to have something like an abstraction here" by @RalfJung.

[RalfJung]

The *Ty types have successfully found and prevent several bugs. Currently the only "hole" in the scheme is ImmTy, you can construct arbitrary immediates from the outside. I was very happy when I managed to make OpTy private and only expose ImmTy instead, having to un-do this would be very sad. :(

[RalfJung]

Really the advice here should be "do not use this, period". This is not an inside-rustc vs outside-rustc distinction.

[RalfJung]

Does that mean we can make the method private?

[RalfJung]

This is necessary to make priroda work again without the ugly catch panic hack at https://github.com/oli-obk/priroda/blob/0810d79b474f6ad66686c664925fd595f011c581/src/render/locals.rs#L39-L54.

Looking at that, what about making access_local return an Option<OpTy> instead?

[bjorn3]

Looking at that, what about making access_local return an Option instead?

That's possible.

[RalfJung]

I'd strongly prefer that.

[oli-obk]

Closing in favour of making access_local return an Option