[cfe-commits] [PATCH] Parsing C++0x lambda expressions

David Blaikie dblaikie at gmail.com
Fri Jul 29 19:54:01 PDT 2011


> (error: expected ' or ] after &) :P

;)

> The standard prohibits [[ in any case that isn't to introduce an
> attribute ([decl.attr.grammar]/6) to avoid the need for
> headache-inducing tentative parsing. We should fail this parse.

Indeed - I realize it's ultimately illegal, I'm just not sure where to
fail it. Currently we just parse the thing inside the [] as an
expression - any expression. Then in sema we check whether it's a
sensible integer (& whether we can even return an array from a
function). This doesn't seem to create undue headaches while parsing
(the tentative parsing here is necessary to differentiate objC++
messages from C++ lambdas - not for reasons related to this example).

For example:

foo.cpp:3:20: error: size of array has non-integer type 'double'
  int bar() const [3.0];

is another case of the same kind of thing - let the [] contain an
expression, then worry about that expression not being an integer
later. (& worry about returning an array from a function after that).

Here's the equivalent failure to the lambda problem but with the
current clang code:

foo.cpp:3:22: error: invalid suffix '.' on floating constant
  int bar() const [3..];
                     ^
foo.cpp:3:10: error: function cannot return array type 'int []'
  int bar() const [3..];

We failed to parse the contents of the [], but we just glossed over
that & carried on anyway. The new lambda case looks much the same:

foo.cpp:3:22: error: expected body of lambda expression
  int bar() const [[]];
                     ^
foo.cpp:3:10: error: function cannot return array type 'int []'
  int bar() const [[]];
         ^



More information about the cfe-commits mailing list