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