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

[Frédéric Riss]

> 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 <mailto:friss at apple.com>> wrote:
> 
>> On Feb 9, 2015, at 11:09 AM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, Feb 9, 2015 at 11:07 AM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>> 
>> > On Feb 9, 2015, at 10:47 AM, David Blaikie <dblaikie at gmail.com <mailto: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 <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 <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.

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