[Bug fortran/56520] Syntax error causes misleading message: "Invalid character in name"

["casey.webster at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520

--- Comment #9 from Casey Webster <casey.webster at gmail dot com> ---
(In reply to Steve Kargl from comment #8)
> On Tue, Jul 07, 2015 at 07:10:48PM +0000, casey.webster at gmail dot com
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520
> > 
> > --- Comment #7 from Casey Webster <casey.webster at gmail dot com> ---
> > (In reply to Steve Kargl from comment #6)
> > > On Tue, Jul 07, 2015 at 05:23:17PM +0000, casey.webster at gmail dot com
> > > wrote:
> > > > 
> > > > Also, while I'll agree that "Unclassifiable statement" is better
> > > > than "Invalid character in name", it would be nicer to see
> > > > "Unbalanced parenthesis".
> > > > 
> > > 
> > > I'm sorry that gfortran does not meet your needs.  But, given
> > > how gfortran's matchers work, I doubt that anyone will produce
> > > a patch to do what you want.  I could be wrong.  Maybe someone
> > > will take up the challenge.
> > > 
> > > The patch I developed and committed specifically addresses a
> > > problem where the error message and the locus to which it
> > > pointed are simply wrong.  In 'c = exp(+a))', the old error
> > > message pointed to '+', which is a valid token in a valid
> > > expression.
> > 
> > Understood.  In this case would it be proper to request the other bug I filed
> > be un-marked as a duplicate of this one so this one can be resolved and the
> > other can still be fodder for someone with enough spare time and desire to look
> > into it?  Thanks for your patch btw, I only complained here since my bug was
> > duped to this one.
> > 
> 
> Sure, you could re-open the bug, but I doubt any of the current
> gfortran contributors will ever attempt to 'fix' the issue.  The
> problem lies in how gfortran matches statements.  It attempts to
> match a valid statement.  If it fails, gfortran will queue an
> error message, back-up to what it considers a known good state,
> and then call another matcher.  gfortran repeats this process 
> for a collection of matchers.  Consider an implied do-loop
> in a print statement:
> 
>   print *, (x(i), i = 1, 2)
> 
> gfortran will first attempt to match a complex constant of the
> form (x, y).  This fails and an error is queued.  Then a matcher
> for implied-do is run.  It successes and clears the error queue.
> 
> Now, your problem is all matchers fail and the first error
> (or last because I can't remember) is printed.  Sometimes those
> error messages are a little muddled.

Thanks for the information.  I'm looking into this and I see there is already a
matcher written for balanced parens:

gcc/gfortran/match.c:124  match_parens (void)

which is only called from gfc_match_if() and gfc_match_do() in match.c and from
match_attr_spec() in decl.c.  When I get some free time I'll familiarize myself
better with the matchers and decoding in parse.c and if I come up with
something I'll reopen the duped bug and propose a patch.