MIR always initializes variables with them in (debuginfo) scope.

[eddyb]

That is, given let x = expr;, MIR will produce the same code as let x; x = expr; (modulo borrows).
When breaking inside expr in a debugger, x will be in scope, uninitialized.
It can be really annoying when dealing with shadowing or arguments.
For example, if you break on the call in let x = ...; let x = f(x); and try to print x, you will get the second x, which is uninitialized at that point.

cc @michaelwoerister

[michaelwoerister]

This might be interesting here:

rust/src/librustc_trans/debuginfo/create_scope_map.rs

Line 246 in c9f1501

// LLVM does not properly generate 'DW_AT_start_scope' fields

How would I best be able to take a look at what the scoping structure of a function looks like (i.e. what expression is assigned to what scope)?

[eddyb]

@michaelwoerister MIR scopes? rustc --unpretty=mir -Z unstable-options on master should print scope IDs for all variables, statements and terminators.

[michaelwoerister]

@eddyb Thanks! I'll take a look.

[michaelwoerister]

r? @michaelwoerister
I'll review this if nobody minds.

Oops, wrong tab...

[michaelwoerister]

@eddyb This looks rather suspicious to me:

rust/src/librustc_mir/build/block.rs

Line 55 in 8b09372

let remainder_scope_id = this.push_scope(remainder_scope, block);

At least from a visibility point of view, the init-scope should not be nested within the remainder-scope.

[eddyb]

@michaelwoerister that nesting is necessary for MIR borrowck AFAICT - if a variable is not in scope, you can't actually initialize it, since it doesn't exist.

[michaelwoerister]

Hm, then I'm inclined to suggest that we do not re-use these scopes for debuginfo and instead build an additional visibility scope tree, as not to conflate two things that are not really the same.

[eddyb]

How terrible would it be to have two scopes, one starting before the let and one after it?
The visibility problems would be fixed by having each VarDecl track two scopes, the one in which it's declared and the one in which it's initialized.

[michaelwoerister]

So, the this code...

let x = 3 + 4;
<subsequent statements>

... would map to the following?

{ // "lifetime scope"
    let x;
    {  // "initializer scope"
        tmp1 = 3 + 4;
        x = tmp1;
    }
    {  // scope within which x is visible, i.e. "remainder scope" of the let binding
        <subsequent statements>
    }
}

That would be worth a try, I think. If it turns out not to cause to many problems with "accidental" interactions with borrow-checking, it would save us the work of maintaining two scope trees.

[eddyb]

@michaelwoerister Yeah, that's what I meant. I'm pretty sure it can work, although I'd like someone who actually is going to work on MIR borrowck look at it. @nikomatsakis?

[nikomatsakis]

@eddyb having an extra scope (the innermost enclosing block) seems... fine. I'm still somewhat unconvinced that we want those variables to be visible before you have stepped to the let in question though, but I guess that's a (somewhat) separate question.

[eddyb]

@nikomatsakis Why would they be visible before? I'm only suggesting changing the scope we use in debuginfo from starting "just before the let" to " just after the let", i.e. not including the let RHS.

[nikomatsakis]

@eddyb oh, hmm, I was not understanding what you meant. The issue is that today the "suffix" scopes include the initializer, and you would rather that they do not? In any case, having an extra scope seems fine.

[eddyb]

@nikomatsakis Correct, that would result in the expected behavior in a debugger.
But borrowck has to know that the initializer is in the scope of the definition, doesn't it?
Can we actually get away with only recording the post-initializer "suffix"?
Because that's the trivial fix @michaelwoerister mentioned, for let, while match already works like that.

[nikomatsakis]

@eddyb I think borrowck does want the lifetime to include the initializer, in order to allow things like let foo = &3

[eddyb]

So it appears that the whole "definition scope" isn't used right now, but rather "remainder scope", which is the visibility scope, and the problem, as @michaelwoerister pointed out, is that the initializer scope is nested in it at the MIR level (its parent is the remainder scope), even though they're not lexically nested.