On Tue, Aug 25, 2015 at 10:50 AM, Bataev, Alexey <a.bat...@hotmail.com> wrote:
> Guys, talking about implicitly captured variables we have to deal with 2 > locations: 1) point of real capturing (it is the point of '=' or '&' > symbols in lambda capture-list); I'm not sure that's "the point of real capturing" if it's an implicit capture - nature of it being implicit is that there is no point where the variable is explicitly captured. > 2) a point of first use of variable inside lambda's body. > When we're talking about diagnostic for implicitly captured variables we > have to deal with the second point, not the first one, because of usability. That's what I'm trying to understand - why is (2) relevant for diagnostic usability, but not for debugger usability? > I don't think that the "diagnostic consumer" would be happy to see a > message like "unnamed variable cannot be implicitly captured in a lambda > expression" pointing to '=' or '&'. Here we have to emit the diagnostic at > the point of the very first use of the variable we're going to capture to > make diagnostic more user-friendly. But actual point of capturing is still > a point, where we have '=' or '&' symbols in capture-list. > > Best regards, > Alexey Bataev > ============= > Software Engineer > Intel Compiler Team > > 25.08.2015 19:00, Eric Christopher пишет: > >> >> Yeah. I can't see a difference here being useful, and more likely harmful. >> >> >> On Tue, Aug 25, 2015, 8:48 AM David Blaikie <dblai...@gmail.com <mailto: >> dblai...@gmail.com>> wrote: >> >> On Tue, Aug 25, 2015 at 8:44 AM, Bataev, Alexey >> <a.bat...@hotmail.com <mailto:a.bat...@hotmail.com>> wrote: >> >> Debug info points to the real place where it is captured, >> while diagnostics points to the first use of implicitly >> captured variable. >> >> >> Right, but I'm trying to understand the justification for why >> that's the right thing to do. Why the debug info user would want a >> different experience than the compiler diagnostic consumer would want. >> >> >> - David >> >> >> >> Best regards, >> Alexey Bataev >> ============= >> Software Engineer >> Intel Compiler Team >> >> 25.08.2015 18 <tel:25.08.2015%2018>:22, David Blaikie пишет: >> >> >> >> On Tue, Aug 25, 2015 at 8:18 AM, Bataev, Alexey >> <a.bat...@hotmail.com <mailto:a.bat...@hotmail.com> >> <mailto:a.bat...@hotmail.com >> >> <mailto:a.bat...@hotmail.com>>> wrote: >> >> I though about this. I think it will be more >> convenient for user >> to see the diagnostic on the first use of the variable >> rather than >> on '=' or '&' symbol. >> >> >> Why the difference between the diagnostic & the debug >> info, then? >> >> >> Best regards, >> Alexey Bataev >> ============= >> Software Engineer >> Intel Compiler Team >> >> 25.08.2015 18 <tel:25.08.2015%2018> >> <tel:25.08.2015%2018>:07, David Blaikie пишет: >> >> >> >> On Tue, Aug 18, 2015 at 9:05 PM, Alexey Bataev via >> cfe-commits >> <cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org> >> <mailto:cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org>> >> <mailto:cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org> >> >> <mailto:cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org>>>> wrote: >> >> ABataev created this revision. >> ABataev added reviewers: echristo, rjmccall, >> rsmith. >> ABataev added a subscriber: cfe-commits. >> >> When variables are implicitly captured in >> lambdas, debug info >> generated for captured variables points to >> location where >> they are >> used first. This patch makes debug info to >> point to capture >> default location. >> >> >> Not sure if this is the right tradeoff, or if it >> is, perhaps >> we should reconsider how our diagnostics work too? >> >> Currently if you, say, capture a variable by value >> and that >> variable doesn't have an accessible copy ctor, the >> diagnostic >> points to the first use. Should we change that too? >> >> >> http://reviews.llvm.org/D12134 >> >> Files: >> lib/Sema/SemaLambda.cpp >> test/CodeGenCXX/debug-lambda-expressions.cpp >> >> Index: lib/Sema/SemaLambda.cpp >> >> =================================================================== >> --- lib/Sema/SemaLambda.cpp >> +++ lib/Sema/SemaLambda.cpp >> @@ -1377,10 +1377,10 @@ >> } >> >> static ExprResult >> performLambdaVarCaptureInitialization( >> - Sema &S, LambdaScopeInfo::Capture &Capture, >> - FieldDecl *Field, >> + Sema &S, LambdaScopeInfo::Capture >> &Capture, FieldDecl >> *Field, >> SmallVectorImpl<VarDecl *> &ArrayIndexVars, >> - SmallVectorImpl<unsigned> >> &ArrayIndexStarts) { >> + SmallVectorImpl<unsigned> >> &ArrayIndexStarts, bool >> ImplicitCapture, >> + SourceLocation CaptureDefaultLoc) { >> assert(Capture.isVariableCapture() && "not a variable >> capture"); >> >> auto *Var = Capture.getVariable(); >> @@ -1399,7 +1399,10 @@ >> // An entity captured by a >> lambda-expression is >> odr-used (3.2) in >> // the scope containing the >> lambda-expression. >> ExprResult RefResult = >> S.BuildDeclarationNameExpr( >> - CXXScopeSpec(), >> DeclarationNameInfo(Var->getDeclName(), >> Loc), Var); >> + CXXScopeSpec(), >> + DeclarationNameInfo(Var->getDeclName(), >> + ImplicitCapture ? >> CaptureDefaultLoc : Loc), >> + Var); >> if (RefResult.isInvalid()) >> return ExprError(); >> Expr *Ref = RefResult.get(); >> @@ -1561,7 +1564,8 @@ >> Expr *Init = From.getInitExpr(); >> if (!Init) { >> auto InitResult = >> performLambdaVarCaptureInitialization( >> - *this, From, *CurField, >> ArrayIndexVars, >> ArrayIndexStarts); >> + *this, From, *CurField, >> ArrayIndexVars, >> ArrayIndexStarts, >> + CaptureDefault != LCD_None, >> CaptureDefaultLoc); >> if (InitResult.isInvalid()) >> return ExprError(); >> Init = InitResult.get(); >> Index: >> test/CodeGenCXX/debug-lambda-expressions.cpp >> >> =================================================================== >> --- test/CodeGenCXX/debug-lambda-expressions.cpp >> +++ test/CodeGenCXX/debug-lambda-expressions.cpp >> @@ -14,6 +14,19 @@ >> struct D { D(); D(const D&); int x; }; >> int d(int x) { D y[10]; return [x,y] { return >> y[x].x; }(); } >> >> +// CHECK-LABEL: foo >> +int foo(int x) { >> +// CHECK: [[X:%.+]] = alloca i32, >> +// CHECK: call void @llvm.dbg.declare( >> +// CHECK: [[X_REF:%.+]] = getelementptr >> inbounds %{{.+}}, >> %{{.+}}* %{{.+}}, i32 0, i32 0, !dbg >> ![[DBG_FOO:[0-9]+]] >> +// CHECK: [[X_VAL:%.+]] = load i32, i32* >> [[X]], align 4, !dbg >> ![[DBG_FOO]] >> +// CHECK: store i32 [[X_VAL]], i32* >> [[X_REF]], align 4, !dbg >> ![[DBG_FOO]] >> +// CHECK: call i32 @{{.+}}, !dbg ![[DBG_FOO]] >> + return [=] { >> + return x; >> + }(); >> +} >> + >> // Randomness for file. -- 6 >> // CHECK: [[FILE:.*]] = !DIFile(filename: >> "{{.*}}debug-lambda-expressions.cpp", >> >> @@ -100,3 +113,5 @@ >> // CHECK-SAME: line: [[VAR_LINE]], >> // CHECK-SAME: elements: >> ![[VAR_ARGS:[0-9]+]] >> // CHECK: ![[VAR_ARGS]] = !{!{{[0-9]+}}} >> + >> +// CHECK: [[DBG_FOO:![0-9]+]] = >> !DILocation(line: 25, >> >> >> >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org> >> <mailto:cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org>> >> <mailto:cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org> >> <mailto:cfe-commits@lists.llvm.org >> <mailto:cfe-commits@lists.llvm.org>>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> >> >> >> >> >> >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
