[llvm-bugs] [Bug 35423] decltype((x)) inside lambda is considered odr-use if x is captured

via llvm-bugs llvm-bugs at lists.llvm.org
Sat Dec 16 08:59:02 PST 2017


https://bugs.llvm.org/show_bug.cgi?id=35423

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |richard-llvm at metafoo.co.uk

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> ---
Prior to P0588R1:

[expr.prim.lambda.capture]/14:

"Every occurrence of decltype((x)) where x is a possibly parenthesized
id-expression that names an entity of automatic storage duration is treated as
if x were transformed into an access to a corresponding data member of the
closure type that would have been declared if x were an odr-use of the denoted
entity."

This is clear that Clang is correct that B and D give decltype((x)) as const
int&, not int&. But the types of A and C are unclear.

After P0588R1, the wording is a bit clearer:

[expr.prim.id.unqual]/1:

"If the entity is a local entity and naming it from outside of an unevaluated
operand within the declarative region where the unqualified-id appears would
result in some intervening lambda-expression capturing it by copy, the type of
the expression is the type of a class member access expression ([expr.ref])
naming the non-static data member that would be declared for such a capture in
the closure object of the innermost such intervening lambda-expression. [ Note:
If that lambda-expression is not declared mutable, the type of such an
identifier will typically be const qualified. ]"

Here we see that A and C should have type int& and B and D should have type
const int&.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171216/9faa8750/attachment.html>


More information about the llvm-bugs mailing list