Re: Is this really the right location for the error pointer?

[Bernhard Fischer <rep dot nop at aon dot at>]

On Tue, Oct 10, 2006 at 12:00:48PM -0700, Brooks Moses wrote:
>When testing out the STAT example (to make sure I hadn't mucked up the 
>formatting, I got the following error (due to the fact that "staterr" 
>was implicitly declared as real):
>
>---------------------------------------------------------------------
>~/temp> ~/gcc-trunk/bin/gfortran test_stat.f90 -o test_stat.exe
> In file test_stat.f90:5
>
>  CALL STAT("/etc/passwd", statarr, status)
>                         1
>Error: 'values' argument of 'stat' intrinsic at (1) must be INTEGER
>---------------------------------------------------------------------
>
>It took me a couple of false starts to realize that that "1" was 
>intended to be pointing at the _second_ variable, and not the first one. 
>  Would it be possible to bump it a spot to the right, after the comma, 
>to make this clearer?
>
>(Should I file a PR about this?)

I couldn't find a PR diagnostic "incorrect locus", fwiw.

A vaguely related note:
The parser often is advancing gfc_current_locus where it shouldn't,
resp. emits an improper locus where a diagnostic should get passed
an %L instead of the %C (==gfc_current_locus).
E.g.:
$ cat parser_locus_1.f90 
1 ! { dg-warning "Ignoring statement label in empty statement" }
end
$ gfortran-4.1 -Wall parser_locus_1.f90 
 In file parser_locus_1.f90:1

1 ! { dg-warning "Ignoring statement label in empty statement" }
                                                               1
Warning: Ignoring statement label in empty statement at (1)

The attached non-patch was a start of looking into the problems with the
locus WRT comment parsing.
IIRC it fails on things like
common /c/ g, h, !comment
i, j, !another comment
k
As said, not a patch, but perhaps it is useful to point to some of the
functions involved with this kind of locus bookkeeping.

HTH,

Attachment: parser_locus.00.diff
Description: Text document