Why isn't the `unsafe` keyword necessary for custom MIR?

[extf33]

Why isn't the unsafe keyword necessary for custom MIR?
It seems like using custom MIR can potentially introduce memory-related bugs and even trigger internal compiler errors(ICE).

[jyn514]

cc @JakobDegen but this seems like a good idea to me

[JakobDegen]

I don't really see this adding any value. Custom mir is already behind two internal features, no one's using it by accident and then getting surprised that their code might have UB.

If someone wants to write a PR and can figure out how to do this in a way that doesn't worsen the ergonomics though, go for it

[compiler-errors]

I also don't think that this needs unsafe. There are plenty of internal features that may be used in unsound ways that are either unnecessarily inconvenienced by or actually impossible to mark with unsafe -- the documentation for custom MIR states that it is meant for testing only, and #108955 will make sure that folks acknowledge that they're using an internal feature, as well.

[compiler-errors]

Since this has to do with an internal-only feature, I don't think this needs to be tracked. Feel free to reopen it if y'all disagree.

[lukas-code]

I think we should wait for rust-lang/rfcs#3325 and then make the custom_mir attribute unsafe, similar to no_mangle.

[workingjubilee]

As long as macros are involved, no Rust code requires the visible presence of the unsafe keyword, as plutonium demonstrates. 👼