[PATCH] Improve diagnostic message for misplaced square brackets

[Richard Trieu]

================
Comment at: lib/Parse/ParseDecl.cpp:4721-4728
@@ +4720,10 @@
+  // save some information for a diagnostic later if the identifer is found.
+  if (Tok.is(tok::l_square) && !D.mayOmitIdentifier()) {
+    UnhandledError = true;
+    StartLoc = Tok.getLocation();
+    while (Tok.is(tok::l_square)) {
+      ParseBracketDeclarator(D);
+    }
+    EndLoc = PP.getLocForEndOfToken(D.getLocEnd());
+  }
+
----------------
Richard Smith wrote:
> It looks like this will behave strangely if the remaining declarator is not just a simple identifier:
> 
>   int[3] (*p);
> 
> ... will form an 'array of three pointers to int' type, rather than a 'pointer to array of three ints' type. Instead, to get this sort of thing right, I suggest you consume the array bound, then call ParseDeclarator, then add the array bound chunks to the declarator and issue your diagnostic.
> 
> To get the diagnostic location right, you could store the location of the '[' as the identifier location in the Declarator object or similar.
Switch to storing the bracket data, then letting the identifier parsing happen.  Right before the diagnostic is emitted, the bracket data is added to the Declarator, which now treats:

  int[3] (*p);

as

  int (*p)[3];



================
Comment at: lib/Parse/ParseDecl.cpp:4731
@@ -4715,3 +4730,3 @@
   if (getLangOpts().CPlusPlus && D.mayHaveIdentifier()) {
     // ParseDeclaratorInternal might already have parsed the scope.
     if (D.getCXXScopeSpec().isEmpty()) {
----------------
Richard Smith wrote:
> In this case, I think you probably shouldn't allow square brackets. That is, if someone writes:
> 
>   int foo::[3]
> 
> we shouldn't activate the special case.
This patch doesn't affect the diagnostic messages for this code.

http://reviews.llvm.org/D2712