[Bug fortran/105547] New: No further "Unclassifiable statement" after the first one if multiple syntax errors.

[Bug fortran/105547] New: No further "Unclassifiable statement" after the first one if multiple syntax errors.

[mikael at gcc dot gnu.org]

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

            Bug ID: 105547
           Summary: No further "Unclassifiable statement" after the first
                    one if multiple syntax errors.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

Testcase as reported by Harald here:
https://gcc.gnu.org/pipermail/fortran/2022-May/057841.html

subroutine a
  errorstop
end
subroutine b
  errorstop
end 


This gives only one error as output instead of two:

xxx.f90:2:3:

     2 |   errorstop
       |   1
Error: Unclassifiable statement at (1)

[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.

[mikael at gcc dot gnu.org]

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

--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> ---
In parse.cc, we avoid emitting an error if an other has been emitted.
But it uses the total error count, not the number of errors since we started
matching the current statement.

597  if (!gfc_error_check ())
598    {
599      int ecnt;
600      gfc_get_errors (NULL, &ecnt);
601      if (ecnt <= 0)
602        gfc_error_now ("Unclassifiable statement at %C");
603    }

[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.

[mikael at gcc dot gnu.org]

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

--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 57739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739&action=edit
Patch fixing the problem

This small patch fixes the problem.
Unfortunately allowing more errors seems counter-productive here.
As seen in the testsuite changes, the additional errors have little value, and
add more noise than anything else.
I'm tempted to close this as WONTFIX.

[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #2)
> Created attachment 57739 [details]
> Patch fixing the problem
> 
> This small patch fixes the problem.
> Unfortunately allowing more errors seems counter-productive here.
> As seen in the testsuite changes, the additional errors have little value,
> and add more noise than anything else.
> I'm tempted to close this as WONTFIX.

I like your approach to limit the run-on errors.

I am, however, of the mind that if gfortran gets to the
"Unclassifiable error" message, that perhaps, this should be
a fatal error.

[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to kargl from comment #3)
> (In reply to Mikael Morin from comment #2)
> > Created attachment 57739 [details]
> > Patch fixing the problem
> > 
> > This small patch fixes the problem.
> > Unfortunately allowing more errors seems counter-productive here.
> > As seen in the testsuite changes, the additional errors have little value,
> > and add more noise than anything else.
> > I'm tempted to close this as WONTFIX.
> 
> I like your approach to limit the run-on errors.
> 
Well, the intent of this PR was on the contrary to avoid silent errors.

> I am, however, of the mind that if gfortran gets to the
> "Unclassifiable error" message, that perhaps, this should be
> a fatal error.
I guess one can find cases where later errors are useless noise, and cases
where they remain useful and are not caused by bad error recovery.

Anyway, I'm closing this.