Better type-specifier representation

I guess this isn't (strictly-speaking) a VLA since this is example is C
++ code.

As long as you realize that:

void foo(int i) {
   int a[i];
}

is a VM object (has a VLA type) and is C++ code in the sense that it is compiled by g++, which happens to be not in the C++ language (yet), but is in the gnu C++ language.

Nevertheless, should we treat these as VLAs in the ASTs?

I propose that we treat VLAs as VLAs and non-VLAs by a name other than VLA?! I shudder to think anyone would want something different. Surely I must misunderstand something.

If I recall correctly, in C++, in "const int i = 10; int a[i];", the
declaration of a is valid (and not a VLA) because "i" is a constant
expression (as opposed to C99, where it is a VLA).

In any case, I can't figure out what owns the expression in the
braces; I wouldn't be surprised if it leaks.

-Eli

I agree with Argiris that the same AST node represents these things (i.e.
an array which has a size expression instead of constant). Calling this
node a VLA node is a misnomer, however.

It is sema's responsibility to make sure that this node makes sense given
the current language (i.e. is it a VLA? Is it an array with a size expression
which evaluates to a constant and is thus accepted by gcc as a valid array
in non-C99? Similar situation for C++...).

And it is LLVM IR generation's responsibility to do the right thing
with it. For downstream convenience we may want Sema to annotate
such nodes with information about what the "array with size expression"
actually is.

In my opinion, the owner of the expression should most certainly be the
declaration. In fact, I'm not even sure it is correct for the size expression
to be in the type, but I haven't taken the time to fully understand VLA
rules and the interaction with what gcc accepts yet.

I'm fairly certain that this issue is independent of the type specifier one,
however.

- Daniel

Daniel Dunbar wrote:

In my opinion, the owner of the expression should most certainly be the
declaration. In fact, I'm not even sure it is correct for the size expression
to be in the type, but I haven't taken the time to fully understand VLA
rules and the interaction with what gcc accepts yet.

I'm fairly certain that this issue is independent of the type specifier one,
however.
  
Isn't the ownership issue similar to the RecordDecl ownership issue that the proposed TypeSpecifier node solves ?
e.g:

x = sizeof(int[y+10]); // who owns "y+10" ?

How about having the TypeSpecifier node own these expressions ?
sizeof(int[y+10]) -> sizeof(TypeSpecifier) -> TypeSpecifier owns "y+10"

-Argiris

x = sizeof(int[y+10]); // who owns "y+10" ?

How about having the TypeSpecifier node own these expressions ?
sizeof(int[y+10]) -> sizeof(TypeSpecifier) -> TypeSpecifier owns "y+10"

Yes, this is exactly what I think should happen. I said
declaration but really the specifier is the right place.

- Daniel