Re: Emacs and GFortran

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

On Wed, Nov 01, 2006 at 10:51:42PM +0100, Alfred M. Szmidt wrote:
>    Have you actually read gfortran source code other than error.c?
> 
> I have.

Good, then you can appreciate that the problem isn't trivial.

> 
>    > Here is another version that is should be backward compatible
>    > with the bits that the testsuite parses.  This will fix the
>    > problem the original user reported; namley allowing programs that
>    > parse GNU style error message to jump to the location of the
>    > error/warning.
> 
>    I've already posted a counter example that will not allow a
>    person to jump to the location of the error.  You need to 
>    read the entire error message to decide where the error is.
> 
> Your example doesn't counter anything, this is your example with GNU
> style error messages (simply removing "In file", and adding a extra
> semi-colon):
> 
> | l.inc:1:
> | 
> |      Included at l.f90:2
> | 
> |    integer i
> |            1
> | l.f90:3:
> | 
> |    call i(j)
> |            2
> | Error: 'i' at (1) has a type, which is not consistent with the CALL at (2)
> 
> Which will work with any program that parses GNU style error messages
> by producing two places where one can go to; the user can choose which
> place to edit.  It doesn't have to catch the exact place, it is after
> all not a substitute for a brain.

What about the third location?  You need to parse "Included at l.f90:2"
to jump to that location to remove the included file.

> Can you please apply one of those patches?  They both fix the problem.

But it does not fix the nonconformance to the GNU standard.  The above 
message would need to become

l.f90:3-l.inc:1: error: 'i' has a type, which is not consistent with the CALL

or

l.f90:3.7-l.inc:1.3: error: 'i' has a type, which is not consistent with the CALL

In neither case, do we see the problem is actually at line 2 of l.f90.

-- 
Steve