r228588 - DebugInfo: Suppress the location of instructions in aggregate default arguments.

[David Blaikie]

On Mon, Feb 9, 2015 at 2:35 PM, Frédéric Riss <friss at apple.com> wrote:

>
> On Feb 9, 2015, at 11:44 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Mon, Feb 9, 2015 at 11:28 AM, Frédéric Riss <friss at apple.com> wrote:
>
>>
>> On Feb 9, 2015, at 11:09 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>> On Mon, Feb 9, 2015 at 11:07 AM, Frédéric Riss <friss at apple.com> wrote:
>>
>>>
>>> > On Feb 9, 2015, at 10:47 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>> >
>>> > Author: dblaikie
>>> > Date: Mon Feb  9 12:47:14 2015
>>> > New Revision: 228588
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=228588&view=rev
>>> > Log:
>>> > DebugInfo: Suppress the location of instructions in aggregate default
>>> arguments.
>>> >
>>> > Matches the existing code for scalar default arguments. Complex default
>>> > arguments probably need the same handling too (test/fix to that coming
>>> > next).
>>>
>>> What was the behavior before that? Was the location set to the
>>> declaration with the default argument description?
>>
>>
>> Yes
>>
>>
>>> I think I wouldn’t matter my debugger jumping there when the code
>>> actually does something non-trivial to initialize the argument(s).
>>>
>>
>> Perhaps - though it is a bit jarring whenever you step passed a
>> std::string, std::vector, etc ctor and leap into the standard library
>> header to see the Allocator() ctor call, then go back to your code.
>>
>>
>> This is true, however from a purely semantic POV I think a ‘step’ should
>> really get you there. I mostly asked out of curiosity, I’m not objecting to
>> the change. I guess people could find it strange and that hiding the
>> initialization is a sane choice (although remembering the developer that
>> something non-trivial is happening here also has its advantages).
>>
>
> I'm not sure how to remind the developer in a sufficiently gentle way
> (perhaps some way we could communicate this to a debugger & come up with an
> appropriate debugger user experience) - default arguments are /really/
> common in C++. If we attributed their location to where the expression was
> written, it would be very disruptive.
>
>
>>
>> I do wonder if maybe the same is_stmt change we're discussing for dtors
>> would be suitable here, so you don't step to it, but it does appear in the
>> backtrace. Still awkward line table entry "foo() : basic_string:20473" or
>> something - "wait, foo isn't in basic_string…".
>>
>>
>> Not sure I’m totally following here. The basic_string code in foo()
>> should appear as an inlined function, shouldn’t it?
>>
>
> It's not the body of basic_string's ctor, it's basic_string's ctor's
> default argument (changed somewhat in C++14, but prior to that there was no
> no-args ctor in basic_string, only one that took an Allocator and provided
> a default value:
> http://en.cppreference.com/w/cpp/string/basic_string/basic_string - but
> you can see the other ctors that have the same default argument post-14,
> including the common const char* converting ctor)
>
> class basic_string {
>   basic_string(const Allocator &alloc = Allocator());
>   ...
> };
>
> void func() {
>   basic_string s;
> }
>
> In this code, there is a call to "Allocator()" in the body of func() -
> this is not the inlined body of basic_string, it's not an inlined function
> of any kind, the C++ language just says, basically, that the default
> argument expression is evaluated in the context of the call site (modulo
> some stuff). So the compiler generates that call to Allocator() at every
> call to basic_string's construction with no args.
>
>
> Thanks for the detailed example! It helped.
>
> So nexting through 'func()' would result in you jumping off to where
> "Allocator()" was written, then jumping back to 'func()’.
>
> (you can try commenting out the code - refactored in r228589 - and
> debugging some STL code)
>
>
> Now I see where this is coming from. I wholeheartedly agree ‘next’
> shouldn’t get you there. I was confused thinking that you changed what
> ‘step’ might do, but that didn’t make sense. Thanks for taking the time for
> the detailed answer.
>

Sure thing  -thanks for checking!

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150209/5c6d9d27/attachment.html>