Add new safety enum for inner extern items

[spastorino]

This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.

r? @compiler-errors

[rustbot]

changes to the core type system

cc @compiler-errors, @lcnr

Some changes occurred in need_type_info.rs

cc @lcnr

This PR changes Stable MIR

cc @oli-obk, @celinval, @ouz-a

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

HIR ty lowering was modified

cc @fmease

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[rustbot]

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

[oli-obk]

Why aren't we expanding the Unsafe enum instead? Is that too annoying for the places where Safe can't occur?

[spastorino]

Why aren't we expanding the Unsafe enum instead? Is that too annoying for the places where Safe can't occur?

My reasoning was not only this but also so things can be a bit safer as we won't need to handle safe when it basically can't happen.

[spastorino]

I'm having second thoughts about naming this FnSafety maybe just Safety is better as this is going to be applied to fns and statics.

[oli-obk]

Maybe name this Inherited or FromContext. Without an explanation it's not obvious what this is supposed to be

[spastorino]

Yeah, I've used Default as a way of saying no safety explicitly written means is going to take a default value.
Another possible name could be Implicit.
Out of all the values mentioned I slightly prefer Default but I don't mind changing it neither.
Another name we are using is Normal which I also think is not great, but it is another option.
Let's see if somebody else have some thought about this.

[oli-obk]

I'm having second thoughts about naming this FnSafety maybe just Safety is better as this is going to be applied to fns and statics.

Yea, just naming it Safety is fine as long as there's an explanation why it's different from Unsafe

[bors]

☔ The latest upstream changes (presumably #124621) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #123602) made this pull request unmergeable. Please resolve the merge conflicts.

[celinval]

Can you please add documentation to these two enumerations? It isn't clear to me why we need two different enumerations here.

[celinval]

Don't we already know if a function / static is safe or unsafe by the time we are translating to StableMIR? If so, wouldn't it be better to keep Unsafe / Safe (Normal)?

I'm assuming that the way this is designed today, the Default value will require users to perform an extra query to know the context where this Fn / Static was declared to know whether it is safe or not.

[celinval]

BTW, this is just a suggestion. I know this is a big change already. If it makes sense, maybe just add a fixme comment for us to improve this later. Thanks

[spastorino]

I'm going to wait on a review and decision about this or #125077 or any other alternative before solving the conflicts and @celinval's thoughts as it is a lot of work to keep all these in a mergeable state.