c++ question: can lambda be used in VLA?

Clang Frontend
1

clang currently errors out if I use lambda to compute the size of an array:

$ cat t.cpp
int foo3();

void foo() {
unsigned char a1[((int a) {return a; })(1)];
}

$ clang++ t.cpp -c -std=c++11

error: a lambda expression may not appear inside of a constant expression

unsigned char a1[((int a) { return a; })(1)];

I was wondering why this isn’t allowed since clang supports VLA. If a1 is a VLA, the size of the array doesn’t have to be a constant expression, so it seems that we should be able to use lambda in this example?

2

I believe this is not allowed in standard c++ but is allowed as a C99 extension.

I can silence the error if I replace the call to ParseConstantExpression at ParseDecl.cpp:6098 with ParseExpression, but it also causes other regression tests to fail.

I also tried adding a flag IsArrayBound to ExpressionEvaluationContextRecord, which indicates the expression is used for an array bound. The value of the flag is checked In Sema::PopExpressionEvaluationContext and diagnostics for lambda expression are not emitted if the flag is true.

3

Sure, yes, that’s one way of allowing this, but why do you want to? What would justify the added complexity of allowing this special case?

4

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.

5

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.

https://isocpp.org/files/papers/N4487.pdf proposed constexpr lambdas for a
future standard, and was accepted by EWG; draft wording is in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0170r1.pdf

-- James

6

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.

For example, if we declare the following variable length arrays,

(1) unsigned char a1[foo1()];
(2) unsigned char a1[dynamic_cast<S*>(s) + 3];

clang compiles (1) and (2) without any warnings or errors (unless -pedantic
is used). However, if we use lambda for the array size, clang complains
that lambda cannot be used in constant expressions:

(3) unsigned char a1[((int a){ return a; })(4)];

https://isocpp.org/files/papers/N4487.pdf proposed constexpr lambdas for a

7

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.

-- James

8

From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Akira Hatanaka" <ahatanak@gmail.com>
Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev"
<cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

>

> > > 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?

-Hal

9

From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Akira Hatanaka" <ahatanak@gmail.com>
Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

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?

10

From: "Duncan P. N. Exon Smith" <dexonsmith@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "James Dennett" <james.dennett@gmail.com>, "Akira Hatanaka" <ahatanak@gmail.com>, "Richard Smith"
<richard@metafoo.co.uk>, "Clang Dev" <cfe-dev@lists.llvm.org>
Sent: Thursday, May 26, 2016 5:58:04 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

>
>
> From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
> To: "Akira Hatanaka" <ahatanak@gmail.com>
> Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev"
> <cfe-dev@lists.llvm.org>
> Sent: Wednesday, May 25, 2016 6:37:46 PM
> Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?
>
> 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:
Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a
constant-expression_opt to an expression_opt:
Working Draft, Technical Specification — Array Extensions

I think the Array TS was killed in Jacksonville due to lack of
interest,

Unfortunately; but not exactly for lack of interest. As far as I can tell, there was a lack of progress on the second more-C++-like companion part that was part of the compromise to get the ARBs.

-Hal

11

From: "Duncan P. N. Exon Smith" <dexonsmith@apple.com>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "James Dennett" <james.dennett@gmail.com>, "Akira Hatanaka" <ahatanak@gmail.com>, "Richard Smith"
<richard@metafoo.co.uk>, "Clang Dev" <cfe-dev@lists.llvm.org>
Sent: Thursday, May 26, 2016 5:58:04 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Akira Hatanaka" <ahatanak@gmail.com>
Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev"
<cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

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:
Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a
constant-expression_opt to an expression_opt:
Working Draft, Technical Specification — Array Extensions

I think the Array TS was killed in Jacksonville due to lack of
interest,

Unfortunately; but not exactly for lack of interest. As far as I can tell, there was a lack of progress on the second more-C++-like companion part that was part of the compromise to get the ARBs.

Ah.

12

>
>
> From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
> To: "Akira Hatanaka" <ahatanak@gmail.com>
> Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <
cfe-dev@lists.llvm.org>
> Sent: Wednesday, May 25, 2016 6:37:46 PM
> Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?
>
> 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:

Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a
constant-expression_opt to an expression_opt:

Working Draft, Technical Specification — Array Extensions

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];

13

>
>
> From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
> To: "Akira Hatanaka" <ahatanak@gmail.com>
> Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <cfe-dev@lists.llvm.org>
> Sent: Wednesday, May 25, 2016 6:37:46 PM
> Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?
>
> 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:
Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a constant-expression_opt to an expression_opt:
Working Draft, Technical Specification — Array Extensions

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.

14

From: “James Dennett via cfe-dev” <cfe-dev@lists.llvm.org>
To: “Akira Hatanaka” <ahatanak@gmail.com>
Cc: “Richard Smith” <richard@metafoo.co.uk>, “Clang Dev” <cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

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:
Working Draft, Technical Specification — Array Extensions

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.

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.

15

From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Akira Hatanaka" <ahatanak@gmail.com>
Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

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:
Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a constant-expression_opt to an expression_opt:
Working Draft, Technical Specification — Array Extensions

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.

It turns out r261278 added a -Wcomma that does almost exactly what
I suggested. I guess we just need to add it to -Wall or -Wextra if
we want to go this route.

16

From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Akira Hatanaka" <ahatanak@gmail.com>
Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <
cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

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:

Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a
constant-expression_opt to an expression_opt:

Working Draft, Technical Specification — Array Extensions

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.

17

From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Akira Hatanaka" <ahatanak@gmail.com>
Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <cfe-dev@lists.llvm.org>
Sent: Wednesday, May 25, 2016 6:37:46 PM
Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?

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:
Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a constant-expression_opt to an expression_opt:
Working Draft, Technical Specification — Array Extensions

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.

18

The comma operator is rather useful for RAII objects and to disambiguate the vexing parse in favour of the expression.

For example (note: Clang does not handle this correctly; PR on the way):
struct ContextRAII {
ContextRAII(int);
};

int x[100];

void bar();

void foo(int idx) {
ContextRAII(x[0, idx]), bar();
}

19

The comma operator is rather useful for RAII objects and to disambiguate
the vexing parse in favour of the expression.

For example (note: Clang does not handle this correctly; PR on the way):
struct ContextRAII {
   ContextRAII(int);
};

int x[100];

void bar();

void foo(int idx) {
   ContextRAII(x[0, idx]), bar();

We should warn on both of these commas. If you give ContextRAII a
non-trivial destructor, we should warn on the first one but not the second.

20

>
>
> From: "James Dennett via cfe-dev" <cfe-dev@lists.llvm.org>
> To: "Akira Hatanaka" <ahatanak@gmail.com>
> Cc: "Richard Smith" <richard@metafoo.co.uk>, "Clang Dev" <
cfe-dev@lists.llvm.org>
> Sent: Wednesday, May 25, 2016 6:37:46 PM
> Subject: Re: [cfe-dev] c++ question: can lambda be used in VLA?
>
> 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:

Working Draft, Technical Specification — Array Extensions

The changes to 8.3.4 Arrays [dcl.array] change the argument from a
constant-expression_opt to an expression_opt:

Working Draft, Technical Specification — Array Extensions

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 isn't quite that simple... We do not have a C++ language extension for
VLAs that can be turned on and off in the way you seem to expect. What we
have is an extension warning that can be disabled or turned into an error.
Following our usual philosophy for warning flags, it's not reasonable for
-Wno-vla to affect how we parse an array bound.