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

[John Freeman]

On 7/6/2011 4:07 PM, Douglas Gregor wrote:
>>> +  bool first = true;
>>> +  while (Tok.isNot(tok::r_square)) {
>>> +    if (first) {
>>> +      first = false;
>>> +
>>> +      // Parse capture-default.
>>> +      if (Tok.is(tok::amp)&&   NextToken().isNot(tok::identifier)) {
>>> +        List.Default = DEFAULT_CAPTURE_BY_REF;
>>> +      } else if (Tok.is(tok::equal)) {
>>> +        List.Default = DEFAULT_CAPTURE_BY_COPY;
>>> +      }
>>> +
>>> +      if (List.Default != DEFAULT_CAPTURE_NONE) {
>>> +        // Consume '&' or '='.
>>> +        ConsumeToken();
>>> +        continue;
>>> +      }
>>> +    } else {
>>> +      if (ExpectAndConsume(tok::comma,
>>> +                           diag::err_expected_comma,
>>> +                           "",
>>> +                           tok::r_square)) {
>>> +        // FIXME: We could also expect end of capture list. Should the
>>> +        // diagnostic indicate this?
>>> +        return ExprError();
>>> +      }
>>> +    }
>>>
>>> I find this logic to be a bit twisty. Why not do an initial check for&   (followed by non-identifier) or = to set the default capture kind, then go into the loop that handles individual captures?
>>
>> I believe it will still require some twisty logic. What will the loop handle? If it succeeds on an empty list, then we will need special logic if the default is followed by a comma but no capture past that. If it succeeds only on a non-empty list, then we will need special logic for an empty list. I thought this was the best solution.
>
> I think the weirdness is because of the way you handle the comma. Each time you go through the loop, you should consume one thing (default capture or a single capture), and then expect either a comma or a ']' at the end.

If I were to move the comma parse to the end of the loop, then what you 
describe is essentially what I do now, except I have a check so that a 
default will not be allowed in the middle of the list.

- John