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

2024-03-21 Thread mikael at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Mikael Morin  ---
(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.

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

2024-03-19 Thread kargl at gcc dot gnu.org via Gcc-bugs 
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.

2024-03-19 Thread mikael at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547

--- Comment #2 from Mikael Morin  ---
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.

2022-05-10 Thread mikael at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547

--- Comment #1 from Mikael Morin  ---
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)
602gfc_error_now ("Unclassifiable statement at %C");
603}