http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054
--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Tobias Burnus from comment #10) > Looks good to me at a glance. However, I have not yet applied the patch and > played around with it. > > Thanks for working on this! Thanks for looking at it. If you have a suggestion for a warning that doesn't use %L, I could produce a simpler but more complete proof-of-concept. > > Also, is there any case where gcf_linebuf.file->filename != > > LOCATION_FILE(gcf_linebuf.location) ? > > Seemingly not. I tried to use: It would simplify the work on this PR to remove it and use LOCATION_FILE() in gfortran. > > So the only remaining major issue is the offset. It is not clear to me why > > Fortran needs an explicit offset, don't you track locations when parsing > > using line-map.c > > Seemingly, we don't. The offset within a line is calculated using: > c1 = l1->nextc - l1->lb->line; > and in "next_char" one simply uses: > c = *gfc_current_locus.nextc++; > > For the line map, we just use: > b->location > = linemap_line_start (line_table, current_file->line++, 120); > which gives the line but not the offset. > > > One might handle this in a more clever way, but can't you use in > gfc_warning2, gfortran's normal "locus" and use > linemap_position_for_column() to map from the offset to the column? You cannot insert new locations out of order in a line-map. Perhaps one could create a dummy line-map, but it would be easier if the diagnostics machinery handled arbitrary offsets, so I would favor that. Arbitrary offsets are useful also to other FEs for some special cases anyway. Of course, the two things are not incompatible: 1) gfortran could use the full linemaps for tracking column numbers, thus removing another duplication of code and 2) for particular cases, the diagnostic machinery could handle explicit offsets passed by gfortran. > Another thing I wonder how to handle best is the case of having two > locations in the same line, e.g. > integer, allocatable :: v(:) > allocate (v(3), v(4)) > end > that currently prints: > foo.f90:foo.f90:2.10-16: > allocate (v(3), v(4)) > 1 2 > Error: Allocate-object at (1) also appears at (2) > > or with line break (note the "&"): > allocate (v(3), & > v(4)) > as > foo.f90:foo.f90:2.10: > allocate (v(3), & > 1 > foo.f90:foo.f90:3.10: > v(4)) > 2 > Error: Allocate-object at (1) also appears at (2) To implement this, the diagnostic machinery should be able to handle two locations first. Then diagnostic_show_locus should handle two locations as well. The particular format used by gfortran will be achieved by playing with the prefix in gcf_diagnostic_starter. The major difficulty is in implementing the one with the line break. A possible solution would be to make diagnostic_build_prefix a hook that can be overriden by the FE and call it from diagnostic_show_locus for each extra line shown. It doesn't seem a lot of work in any case, so I think this is not a show-stopper. But I'd rather start with the simplest cases (for example, those warnings that don't use any explicit %L). However, I don't want to spend a lot of effort on this if there is no interest in the Fortran side. I'm happy to give guidance, to implement things in the common diagnostic machinery and to implement proof-of-concept patches for the Fortran side, but someone else needs to go over the list of Fortran warnings and update them, build and test one by one. As I said, the work can be done incrementally, but I don't have the time to do it all and I'd rather not start if no one on the Fortran side plans to continue it.
