[PATCH] Improve diagnostic message for misplaced square brackets

[Richard Smith]

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];
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140509/3d1ebd7c/attachment.html>