Hi Tobias, Good catch! It looks 'obvious' to me too :-)
Regards Paul On Fri, 11 Oct 2024 at 14:08, Tobias Burnus <tbur...@baylibre.com> wrote: > I found always error.cc rather confusing but I just realized that > we can reduce number of lines in that file by 40% - and remove a lot of > (apparent) complexity. > > The removed code is from the old days, when gfortran handled a lot of > diagnostic itself, also because it wanted to show lines with carets, > while the C/C++ diagnostic did not support this. > > Well, that changed and gfortran mostly converted to the common diagnostic > code, but somehow the old code remained - without actually being used. > > Thus, this patch simply removes it. > > > I regarding the change as trivial and obvious and to intent to commit > it as obvious. Nonetheless, any comments, suggestions, review remarks? > > > Tobias > > > PS: I also wanted to reduce code duplication, but an assert that was > previously > only in one code path triggered, showing at least one case where 'locus' is > broken. Something to fix first before sending in that part ... > > There are also some other changes in the pipeline: > * I want to move support range-based locations, which is also a good > opportunity to fix some misplaced '1' (e.g. which point at white space > instead of the actual declaration or ...). > > * David wants to improve json/sarif output, including stderr + sarif/json > output at the same time, but that has issues with > delayed/suppressed/buffered > diagnostic in gfortran (because of the try & error parsing* in Fortran) > → https://gcc.gnu.org/PR116613 for the former and > https://gcc.gnu.org/105916 > for the buffering issue. > > [(*) e.g., in fixed-form Fortran where spaces have no meaning, the question > when parsing is whether 'd o i = ...' is a 'do i =' loop or a 'doi = ' > assignment. > If the statement ends without finding a ',' it was an assignment... > To avoid bogus errors, the diagnostic has to be suppressed at times.] >
