r183597 - Debug info: An if condition now creates a lexical scope of its own.

[David Blaikie]

On Mon, Jun 10, 2013 at 3:36 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On Jun 10, 2013, at 11:38 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> With this (or Eric's) change do we get the right (same as (or
>> justified if different) GCC) number/placement of scopes/variables for:
>>
>> if (x)
>>  a();
>> else
>>  b();
>>
>> if (int x = ...)
>>  a();
>> else
>>  b();
>>
>> if (int x = ...) {
>>  int y = ...;
>>  a();
>> } else {
>>  int z = ...;
>> }
>>
>> (in theory 'x' should be in-scope across both the if and the else, but
>> we probably don't bother creating a scope if there's no variable in
>> that scope - and just create one for the if/else bodies... but not
>> sure)
> I’m not sure if I understand what you are trying to say...
>
> For the code above we generate a
> (unsure)
>
> DW_TAG_lexical scope
>   DW_TAG_variable (x)
>
> DW_TAG_lexical scope
>   DW_TAG_variable (x)
>   DW_TAG_lexical scope
>     DW_TAG_variable (y)
>   DW_TAG_lexical scope
>     DW_TAG_variable (z)
>
> I’m not sure how to interpret the x at the beginning of the function.

They were intended to be 3 separate examples - the first wasn't too
interesting (the 'x' being implied declaration outside that scope),
except in that we could potentially emit lexical_scopes for
instruction ranges even when they don't contain variables, but that's
probably just pure DWARF bloat there's no reason to bother with.

> The only difference between GCC and clang I can spot is that GCC puts the entire function into a DW_TAG_lexical scope, but I don’t think that this is strictly necessary.

*nod* (interestingly we used to always emit that scope but GCC doesn't
emit it in C mode - we now don't emit it in C or C++ (based on changes
I made) which gives slightly better behavior from GDB (you can refer
to local variables and labels at the top scope with func::var (for
watches, jumps, etc) which you can't do once there's 'var' is within a
scope nested further within the function scope)

> Does that answer the question?

Yes, thank you - hopefully these are tested somewhere, if not they
could be tested alongside the case you've fixed just to make sure
we're covering the the broad range of cases like this.