[cfe-dev] c++ question: can lambda be used in VLA?
Duncan P. N. Exon Smith via cfe-dev
cfe-dev at lists.llvm.org
Tue May 31 15:04:54 PDT 2016
> On 2016-May-31, at 14:46, Hubert Tong <hubert.reinterpretcast at gmail.com> wrote:
>
> On Tue, May 31, 2016 at 5:28 PM, James Grosbach via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>
>> On May 26, 2016, at 4:55 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>
>>>
>>> On 2016-May-26, at 16:16, Akira Hatanaka <ahatanak at gmail.com> wrote:
>>>
>>> On Thu, May 26, 2016 at 3:58 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>>>
>>>> On 2016-May-25, at 16:41, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>
>>>> From: "James Dennett via cfe-dev" <cfe-dev at lists.llvm.org>
>>>> To: "Akira Hatanaka" <ahatanak at gmail.com>
>>>> Cc: "Richard Smith" <richard at metafoo.co.uk>, "Clang Dev" <cfe-dev at lists.llvm.org>
>>>> Sent: Wednesday, May 25, 2016 6:37:46 PM
>>>> Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?
>>>>
>>>> On Wed, May 25, 2016 at 4:19 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:
>>>> On Tue, May 24, 2016 at 7:11 PM, James Dennett <james.dennett at gmail.com> wrote:
>>>> On Tue, May 24, 2016 at 6:25 PM, Akira Hatanaka via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>>> I wasn't requesting that clang accept lambda expressions used for array bounds but was asking whether it was valid in c++. Is this something that is open to interpretation because it's not covered by the standard?
>>>>
>>>> FYI, this isn't something that I made up. It was in a code a user wrote.
>>>>
>>>>
>>>> It's covered by the standard, and as Clang's error message says, lambdas are not allowed in constant expressions in C++11 or C++14.
>>>>
>>>>
>>>> Yes, the c++ standard gives a list of subexpressions that are not allowed in constant expressions and lambda expression is one of them.
>>>>
>>>> This doesn't seem to apply to C99's extension for variable length arrays because array sizes are not required to be constant expressions.
>>>>
>>>>
>>>> I was replying to you saying that you were "asking whether it was valid in C++", and whether "it's not covered by the standard".
>>>>
>>>> C99 doesn't have lambdas, so it doesn't allow this. C++ doesn't have VLAs, so it doesn't allow it.
>>>>
>>>> The de facto language accepted by Clang doesn't accept it, as you already noted.
>>>>
>>>> There's no specification that tells us what the "right thing to do" is here. We could extend Clang to support this non-standard combination of C99 with C++11, and it might even make it a little more consistent, but if it adds any implementation complexity then it may not be worthwhile to support a corner case that's not allowed by any language standard.
>>>> What did the most recent wording for C++ ARBs say about this issue?
>>>
>>> The latest version I could find is here:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#Introduction
>>>
>>> The changes to 8.3.4 Arrays [dcl.array] change the argument from a constant-expression_opt to an expression_opt:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3820.html#dcl.array
>>>
>>> I think the Array TS was killed in Jacksonville due to lack of interest, but the interaction between these features seems straightforward to me. When the C++ language extension for VLAs is turned on, we shouldn't treat the array argument as a constant-expression. This effectively allows lambdas in array bounds.
>>>
>>> Akira, what does the patch for this look like?
>>>
>>>
>>> My first patch just replaced the call to ParseConstantExpresssion at ParseDecl.cpp:6106 with ParseExpression. I didn't see the error message about lambda after applying the patch. It also caused clang to accept expressions like this, if I remember correctly:
>>>
>>> char a[1,2];
>>
>> Hmm. That would merit a warning. IMO, -Wcomma should fire on every
>> use of the built-in comma operator that's not in the "increment"
>> statement of a for loop... I'm not sure if others agree though.
>>
>
> I’m curious what that would look like on a large codebase. It sounds good to me, but potentially very noisy and perhaps a step too far in the direction of style enforcement rather than bug finding.
> As it is, I find -Wlogical-op-parentheses and -Wmismatched-tags to be too noisy already.
I agree that -Wlogical-op-parentheses is fairly noisy, but IMO this
would generate a *lower* amount of noise. I think very few people
actually use `,`, whereas `&&` and `||` are frequently used.
> A case I’d like to make sure gets caught is:
>
> int foo();
> int bar();
> ...
> a = foo(), (void)bar();
>
> There’s no warning or error for this code. However, change the assignment to a “return” and it’s a hard error. Precedence is a pain.
>
> The real issue is the far more nefarious:
> a = foo(), bar();
>
> It’s going to be pretty darn rare to see that and the actual results being what was intended by the author.
>
>
>>
>>
>>>>
>>>> -Hal
>>>>
>>>> -- James
>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Hal Finkel
>>>> Assistant Computational Scientist
>>>> Leadership Computing Facility
>>>> Argonne National Laboratory
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
More information about the cfe-dev
mailing list