[PATCH] Improve diagnostic message for misplaced square brackets

[Richard Smith]

On Fri, May 9, 2014 at 1:38 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On Fri, May 9, 2014 at 1:31 PM, Richard Trieu <rtrieu at google.com> wrote:
>
>> ================
>> Comment at: lib/Parse/ParseDecl.cpp:4841
>> @@ -4824,3 +4840,3 @@
>>      // portion is empty), if an abstract-declarator is allowed.
>>      D.SetIdentifier(0, Tok.getLocation());
>>
>> ----------------
>> Richard Smith wrote:
>> > This looks like it'll provide the wrong location if there were
>> misplaced brackets.
>> The recovery for brackets requires !D.mayOmitIdentifier() [line 4710]
>> while this branch requires D.mayOmitIdentifier().  Either bracket recovery
>> happens or this code executes, but not both.
>>
>> ================
>> Comment at: lib/Parse/ParseDecl.cpp:4862
>> @@ -4838,3 +4861,3 @@
>>                                          :
>> D.getDeclSpec().getSourceRange());
>> -    else if (getLangOpts().CPlusPlus) {
>> -      if (Tok.is(tok::period) || Tok.is(tok::arrow))
>> +    } else if (getLangOpts().CPlusPlus) {
>> +      if (!UnhandledError && (Tok.is(tok::period) || Tok.is(tok::arrow)))
>> ----------------
>> Richard Smith wrote:
>> > Have you considered putting the bracket parsing code way down here (and
>> recursively calling back into this function after parsing them)?
>> Currently, the error correction of:
>>   int [1] a [2];
>> to
>>   int a[1][2];
>>
>> If this was done recursively, the bracket recovery would go to the end
>> instead to:
>>   int a[2][1];
>
>
> I think the latter is the right answer. If we think of
>
>   int [1] a [2];
>
> ... as meaning
>
>   T a[2]; with T = int[1]
>
> ... then that's the same as
>
>   int a[2][1];
>

Another example:

  int [3] *f();

... should be interpreted as/corrected to

  int (*f())[3]

... (that is, a function returning a pointer to an array of three ints) not
as:

  int *f[3]()

(which is an ill-formed declaration of an array of three functions).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140509/f4375713/attachment.html>