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
