[PATCH] D12134: Improve debug info for implicitly captured vars in lambdas
David Blaikie via cfe-commits
cfe-commits at lists.llvm.org
Thu Aug 27 11:15:11 PDT 2015
On Tue, Aug 25, 2015 at 10:50 AM, Bataev, Alexey <a.bataev at 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 <dblaikie at gmail.com <mailto:
>> dblaikie at gmail.com>> wrote:
>>
>> On Tue, Aug 25, 2015 at 8:44 AM, Bataev, Alexey
>> <a.bataev at hotmail.com <mailto:a.bataev at 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.bataev at hotmail.com <mailto:a.bataev at hotmail.com>
>> <mailto:a.bataev at hotmail.com
>>
>> <mailto:a.bataev at 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 at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>
>> <mailto:cfe-commits at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>>
>> <mailto:cfe-commits at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>
>>
>> <mailto:cfe-commits at lists.llvm.org
>> <mailto:cfe-commits at 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 at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>
>> <mailto:cfe-commits at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>>
>> <mailto:cfe-commits at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>
>> <mailto:cfe-commits at lists.llvm.org
>> <mailto:cfe-commits at lists.llvm.org>>>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150827/667af93b/attachment-0001.html>
More information about the cfe-commits
mailing list