Handle lifetimes correctly in sym in inline and global asm

[compiler-errors]

Fixes #111709
Fixes #96304

sym in global-asm can never reference regions other than 'static, so it suffices to fold the constant and replace erased regions with 'static (see first commit). However, we want to be able to mention both early- and late-bound (and local, e.g. #111709) regions from the function in inline-asm.

This change is a bit invasive, but I'm not really convinced it can be simpler, at least without having to teach global_asm! how to be an inference body or something.

This conceptually reverts part of dc345d8 for inline asm, insofar as we return to treating SymFn in non-global_asm bodies as a regular HIR exprs.

cc @Amanieu who stabilized sym in #93333

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[Amanieu]

This is not reachable here since this is only reached for ExprKind::InlineAsm, not `ItemKind::GlobalAsm``.

[Amanieu]

Why is it necessary to change SymFnInInline to no longer use an AnonConst? Aren't inline const blocks able to properly handle lifetimes?

[compiler-errors]

inline consts (const {}) can handle lifetimes, but sym are not represented as inline consts -- theyre AnonConst, which act somewhat differently. They're separate items, so they are type checked totally separately from their enclosing item. Inline consts act more like closures where they're type checked together with their enclosing body.

[bors]

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

[petrochenkov]

inline consts (const {}) can handle lifetimes, but sym are not represented as inline consts -- theyre AnonConst, which act somewhat differently. They're separate items, so they are type checked totally separately from their enclosing item. Inline consts act more like closures where they're type checked together with their enclosing body.

Is anon const actually the desirable semantics here, or it just happens to be the current semantics?
I suspect that references in inline asm are an uncommon corner case, and we can change it if necessary.

at least without having to teach global_asm! how to be an inference body or something.

That's what I'd expect to do.
If the piece of code is an expression, that may have generic arguments and lifetimes in it (and value path is such an expression), then it should be represented as a body, no? Regardless of whether it's a global or local asm.

[compiler-errors]

If the piece of code is an expression, that may have generic arguments and lifetimes in it (and value path is such an expression), then it should be represented as a body, no? Regardless of whether it's a global or local asm.

This is not possible at the moment. Global-asm aren't type-checked in the sense of HIR bodies, nor are they represented with a HIR body.

I'd rather just altogether deny lifetime arguments in sym, if both of y'all are unconvinced by the complexity of this approach.

[petrochenkov]

This is not possible at the moment. Global-asm aren't type-checked in the sense of HIR bodies, nor are they represented with a HIR body.

What do you mean by not possible?
If e.g. enum discriminants can be bodies, then symbols in global asm certainly could as well.

I'd rather just altogether deny lifetime arguments in sym

Why it it ok to have type arguments, but not lifetime arguments?
I'm actually not sure how the path expressions in sym are type checked if they are not bodies, but they are indeed type checked at least to some extent because this fails

fn foo<T: Copy>() {}

sym foo::<NonCopy>

---

The question about anon consts vs inline consts also wasn't answered.
@rustbot author

[compiler-errors]

enum discriminants can be bodies, then symbols in global asm certainly could as well.

That's because enum discriminants actually correspond to expressions in HIR.

Why it it ok to have type arguments, but not lifetime arguments?

Because we explicitly erase lifetime arguments during writeback in HIR.

I'm actually not sure how the path expressions in sym are type checked if they are not bodies, but they are indeed type checked at least to some extent because this fails

They are bodies. They just don't have a parent body, which is required for inline-consts to make sense. Inline consts are type-checked in the parent body, like closures. It's like having a closure with no enclosing body -- it doesn't make sense.

@petrochenkov: Remind me what specific question about inline you want answered, though?

[petrochenkov]

Remind me what specific question about inline you want answered, though?

What would be the preferable semantics for sym - inline const or anon const (if backward compatibility, etc is out of question).

[petrochenkov]

That's because enum discriminants actually correspond to expressions in HIR.

Okay, then sym should correspond to expressions in HIR.
SymFnInInline does correspond to an expression, SymFnInGlobal should do that too, I don't see why they should diverge.

Yes, SymFnInGlobal is an expression in a "global" context, outside of any parent body, but that's exactly the same situation as with const initializers or enum variant discriminants, if there's no top level body then we should create it.

[compiler-errors]

Yes, SymFnInGlobal is an expression in a "global" context, outside of any parent body, [...] if there's no top level body then we should create it.

I predict this is going to be prohibitively complicated.

but that's exactly the same situation as with const initializers or enum variant discriminants

This is not exactly the same situation as const initializers or enum variant discriminants, since they never have the possibility of participating in region inference with infer lifetimes that may be inherited from the parent, nor can they reference late-bound regions (which are very very broken, even with #[feature(generic_const_expressions)], cc #115486).

Their restrictions means that it's okay for them to be represented as an AnonConst, which only allows them to reference lifetimes from the parent in certain situations, and even then, only when generic_const_exprs is enabled due to the way we set up the generics for an anon-const.

[compiler-errors]

Don't care to work on this anymore. inline_asm is still super broken when lifetimes are involved, and I still maintain that it needs a more invasive fix like this, for the reasons I elaborated above.