[RFC diagnostics/fortran] Move gfc_warning (buffered) to the common diagnostics machinery

[Steve Kargl]

On Thu, Nov 27, 2014 at 06:25:01PM +0100, Manuel López-Ibáñez wrote:
> 
> The ugliest part is how to handle warningcount and werrorcount. I
> could handle this in the common machinery in a better way by storing
> DK_WERROR in the diagnostic->kind and checking it after printing. This
> way we can first decrease both counters, then increase back the one
> not changed and store the kind somewhere. then if the diagnostic is
> canceled nothing is done, if it is flushed, then increase the
> appropriate counter (perhaps calling into the common part for any post
> action due to Wfatal-errors or -fmax-errors=).
> 
> I can also hide the output_buffer switching inside two helper
> functions, but the helper function would need to use either a static
> variable or a global one to save and restore the tmp_buffer. I'm not
> sure that is better or worse (the current code uses a global pointer
> &cur_error_buffer, so perhaps I should have used a similar approach).
> 

Hi Manuel,

First, thanks for all your work on the error/warning code in gfortran.

Second, I'm dredging through my memories from a decade or so ago.  Others
are encouraged to jump in and correct me.

The design of gfortran's warning/error code is largely unchanged from 
when g95 was originally imported into the tree.  There have been, of
course, some changes but the design was set.  My understanding of how
it all works(ed) is that gfortran's parsing runs a series of matchers
over the input.  A matcher may generate an error/warning, which is
written into a buffer.  But, instead of immediately reporting the issue
gfortran may continue to run a series of matchers to see if the input
is in fact validate.  gfortran will report the last buffered error/warning
message only after the last matcher fails.  In running the series of
matchers, there are times when a matcher may hit an error/warning
condition and it is, in fact, a problem and gfortran wants to report
the problem NOW.  This is the origin of the *_now variants.

I would need to go dredge through ChangeLogs, but I believe I may be
responsible for the counting of error messages. I know that I at least
set the default value for -fmax-error.  The origins to the counting
is that once gfortran encountered and reported an error, she would
discard the problematic statement and continue parsing the input.  This
often leads to a series of spurious run-on error messages, which are
all caused by the first error.  Thus, if one does -fmax-error=1 and
fixes the problem, then all the other problems disappear.

Finally, gfortran's error/warning mechanism isn't immediately available
at the start of execution.  However, errors can occur before the mechanism
is initialized.  This is one reason why one finds fatal_error() spinkled
throughout the code.

>
> * Fortran devs #2: The testsuite is testing that the warning is
> eventually printed. However, I'm not sure it is testing when the
> warning is buffered and then discarded, is it? If not, how can I
> produce such a test?
> 

I think that you can't check for a discarded buffered message.  In
fact, why bother?

-- 
Steve