Line numbers in debug info for range based for

When we emit a range-based for, we get debug info for the __range,
__begin, and __end variables of the equivalent construct:

  {
    auto && __range = range-init;
    for (auto __begin = begin-expr, __end = end-expr;
         __begin != __end; ++__begin) {
      for-range-declaration = *__begin;
      // ...
    }
  }

Currently, these variables don't have any line information associated
with them. It looks to me like they did before r188651:

  commit fc946271e008544b518321fdecc77ca076663c12
  Author: David Blaikie <dblaikie@gmail.com>
  
      DebugInfo: Do not include line/file info for artificial parameters &
      parameters of artificial functions
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188651
      91177308-0d34-0410-b5e6-96231b3b80d8

That commit message is specifically about functions, so it's not clear
if the change to artificial variables was intentional.

Should these variables have line information? On the one hand, they're
artificial, but on the other, they do have a pretty obvious source
location they correspond to.

Thoughts?

Off-hand thought: do you have a debug info consumer that would benefit
from this information? (if so, I'd be curious to hear what the
consumer is/how it's using this information)

And the usual retort: GCC does the same thing:

0x0000008c: DW_TAG_variable [5]
                      DW_AT_name [DW_FORM_strp] (
.debug_str[0x00000019] = "__for_range")
                      DW_AT_type [DW_FORM_ref4] (cu + 0x00d1 => {0x000000d1})
                      DW_AT_artificial [DW_FORM_flag_present] (true)
                      DW_AT_location [DW_FORM_exprloc] (<0x2> 91 58 )

0x00000098: DW_TAG_variable [5]
                      DW_AT_name [DW_FORM_strp] (
.debug_str[0x00000025] = "__for_begin")
                      DW_AT_type [DW_FORM_ref4] (cu + 0x00d7 => {0x000000d7})
                      DW_AT_artificial [DW_FORM_flag_present] (true)
                      DW_AT_location [DW_FORM_exprloc] (<0x2> 91 60 )

0x000000a4: DW_TAG_variable [5]
                      DW_AT_name [DW_FORM_strp] (
.debug_str[0x00000031] = "__for_end")
                      DW_AT_type [DW_FORM_ref4] (cu + 0x00d7 => {0x000000d7})
                      DW_AT_artificial [DW_FORM_flag_present] (true)
                      DW_AT_location [DW_FORM_exprloc] (<0x2> 91 50 )

David Blaikie <dblaikie@gmail.com> writes:

That commit message is specifically about functions, so it's not clear
if the change to artificial variables was intentional.

Should these variables have line information? On the one hand, they're
artificial, but on the other, they do have a pretty obvious source
location they correspond to.

Thoughts?

Off-hand thought: do you have a debug info consumer that would benefit
from this information? (if so, I'd be curious to hear what the
consumer is/how it's using this information)

Not really. I only noticed this because it exposed a bug in llvm-cov,
and I wasn't sure if it was intentional.

And the usual retort: GCC does the same thing:

0x0000008c: DW_TAG_variable [5]
                      DW_AT_name [DW_FORM_strp] (
.debug_str[0x00000019] = "__for_range")
                      DW_AT_type [DW_FORM_ref4] (cu + 0x00d1 => {0x000000d1})
                      DW_AT_artificial [DW_FORM_flag_present] (true)
                      DW_AT_location [DW_FORM_exprloc] (<0x2> 91 58 )

0x00000098: DW_TAG_variable [5]
                      DW_AT_name [DW_FORM_strp] (
.debug_str[0x00000025] = "__for_begin")
                      DW_AT_type [DW_FORM_ref4] (cu + 0x00d7 => {0x000000d7})
                      DW_AT_artificial [DW_FORM_flag_present] (true)
                      DW_AT_location [DW_FORM_exprloc] (<0x2> 91 60 )

0x000000a4: DW_TAG_variable [5]
                      DW_AT_name [DW_FORM_strp] (
.debug_str[0x00000031] = "__for_end")
                      DW_AT_type [DW_FORM_ref4] (cu + 0x00d7 => {0x000000d7})
                      DW_AT_artificial [DW_FORM_flag_present] (true)
                      DW_AT_location [DW_FORM_exprloc] (<0x2> 91 50 )

Good enough for me. Thanks!

From: cfe-dev-bounces@cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu]
>> That commit message is specifically about functions, so it's not
clear
>> if the change to artificial variables was intentional.
>>
>> Should these variables have line information? On the one hand,
they're
>> artificial, but on the other, they do have a pretty obvious source
>> location they correspond to.
>>
>> Thoughts?
>
> Off-hand thought: do you have a debug info consumer that would benefit
> from this information? (if so, I'd be curious to hear what the
> consumer is/how it's using this information)

Not really. I only noticed this because it exposed a bug in llvm-cov,
and I wasn't sure if it was intentional.

Actually I think our debugger shows them even though they're artificial.
I don't know that our debugger deeply cares whether there is source
location info--I'll ask--but we don't ignore the variables completely.
(In fact we were thinking about ways to unique the names; currently all
of these get the same name, even in nested loops, IIRC.)
--paulr