On Fri, May 9, 2014 at 1:38 PM, Richard Smith <[email protected]> wrote:
> On Fri, May 9, 2014 at 1:31 PM, Richard Trieu <[email protected]> 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).
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
