> On Feb 9, 2015, at 11:44 AM, David Blaikie <[email protected]> wrote:
>
>
>
> On Mon, Feb 9, 2015 at 11:28 AM, Frédéric Riss <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On Feb 9, 2015, at 11:09 AM, David Blaikie <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> On Mon, Feb 9, 2015 at 11:07 AM, Frédéric Riss <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> > On Feb 9, 2015, at 10:47 AM, David Blaikie <[email protected]
>> > <mailto:[email protected]>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
