From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37720 invoked by alias); 8 Jul 2015 02:21:11 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 37668 invoked by uid 48); 8 Jul 2015 02:21:04 -0000 From: "casey.webster at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/56520] Syntax error causes misleading message: "Invalid character in name" Date: Wed, 08 Jul 2015 02:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.7.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: casey.webster at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: kargl at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg00584.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520 --- Comment #9 from Casey Webster --- (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 --- > > (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.