Skip to content

Should debuggers treat ZSTs initializers as code to step through? #97083

Open
@pnkfelix

Description

@pnkfelix

Spawned off of #33013 (comment)

If you look at the beginning of the example there:

fn main () {
    let a = ();
    let b : [i32; 0] = [];
    let mut c = 27;
    let d = c = 99;
    [...]
}

the first two variables, a and b, are both ZSTs.

When you run this in a debugger and try to step though each statement, like so:

(gdb) break step::main
(gdb) run
Breakpoint 1, step::main () at step.rs:4
4       let mut c = 27;
(gdb) next
5       let d = c = 99;

you can see that the gdb next command has "skipped" the initialization of a and b.

This is understandable to a Rust expert, because a and b are both zero-sized types, and so no code is generated for initializing those local variables.

But for a Rust beginner, it is confusing.

If we wanted to, we could make -g mode deal with this. For example, we could generate nop's for such initializers, and then give the nop's corresponding debug info. But that is also pessimizing the code generation to accommodate beginners.

This is something we need to make a decision on whether it is an actual bug we would like to fix or not.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-debuginfoArea: Debugging information in compiled programs (DWARF, PDB, etc.)I-needs-decisionIssue: In need of a decision.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions