Fix debuginfo for generators

[lrh2000]

First, all fields except the discriminant (including outer_fields) should be put into structures inside the variant part, which gives an equivalent layout but offers us much better integration with debuggers.

Second, artificial flags in generator variants should be removed.

• Literally, variants are not artificial. We have yield statements, upvars and inner variables in the source code.
• Functionally, we don't want debuggers to suppress the variants. It contains the state of the generator, which is useful when debugging. So they shouldn't be marked artificial.
• Debuggers may use artificial flags to find the active variant. In this case, marking variants artificial will make debuggers not work properly.

Fixes #62572.
Fixes #79009.

And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.

[rust-highfive]

r? @matthewjasper

(rust-highfive has picked a reviewer for you, use r? to override)

[lrh2000]

There is actually another commit (lrh2000@e65c460) that names the upvars for closures and generators in debuginfo. Finally we'll be able to see something like

y::main::closure-0 {_upvar_ref_mut__b: 0x[...], _upvar_ref__a: 0x[...]}

But I am not sure whether what I did is right. Could I add the above commit into this PR or should I open a separate PR for it later?

Any comments are welcome. And thanks in advance.

[lrh2000]

cc @tmandry

[tmandry]

There is actually another commit (lrh2000@e65c460) that names the upvars for closures and generators in debuginfo. Finally we'll be able to see something like

y::main::closure-0 {_upvar_ref_mut__b: 0x[...], _upvar_ref__a: 0x[...]}

I'd remove upvar since it doesn't have meaning outside the compiler. mut also doesn't really matter in this context, imo. ref does help explain why you're seeing a pointer value, I like that.

[tmandry]

Closes #62572 too I think.

I'd like to eventually do this for GeneratorLayout itself, but that's another change.

Thanks! This is a nice improvement. I think this change is ready so I'm going to approve for now and you can open another PR with the upvar naming change.

@bors r+

[bors]

📌 Commit 5bf989e has been approved by tmandry

[lrh2000]

I'd remove upvar since it doesn't have meaning outside the compiler. mut also doesn't really matter in this context, imo. ref does help explain why you're seeing a pointer value, I like that.

Thanks a lot for your feedback. I'll take your advice. The trickiest problem is that if we simply remove upvar, we may encounter collision of names accidentally. For example, see the following code:

fn main() {
    let a = 3;
    let mut c = move || {
        let a = a;
        yield;
        let b = a;
    };
    Pin::new(&mut c).resume(());
    _zzz();
}

We could get something like

$1 = generator_objects::main::generator-0::Suspend0{a: 3, _upvar__a: 3}

But if we simply remove _upvar__, there are two fields named a in the same structure. I'll think about how to solve the problem, or if you have any suggestions, I'll appreciate them.

[lrh2000]

I'd remove upvar since it doesn't have meaning outside the compiler.

I think what you said is reasonable. How about just replacing upvar with captured? Do you think it is better? capture is widely used in Rust official documentation, here and there.

mut also doesn't really matter in this context, imo.

I agree. I added mut because it is consistent with the style of the Rust language. It may be helpful if finally we can add a pretty-printer in debuggers. It demangles something like _captured_ref_mut__a into &mut a and show it to the end users. (So in the meantime, it also hides captured or upvar, thus their name doesn't really matter if we can achieve the final goal.)

[tmandry]

I'd remove upvar since it doesn't have meaning outside the compiler.

I think what you said is reasonable. How about just replacing upvar with captured? Do you think it is better? capture is widely used in Rust official documentation, here and there.

I'd be fine with it. This should also affect closures. We should also support printing the original name of the variable while stepping through the closure/generator (I think we already do).

mut also doesn't really matter in this context, imo.

I agree. I added mut because it is consistent with the style of the Rust language. It may be helpful if finally we can add a pretty-printer in debuggers. It demangles something like _captured_ref_mut__a into &mut a and show it to the end users. (So in the meantime, it also hides captured or upvar, thus their name doesn't really matter if we can achieve the final goal.)

My sense is that could be confusing, since the user never writes &mut a in their code to get the capture. I don't feel too strongly about this.