Re: Emacs and GFortran

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

On Wed, Nov 01, 2006 at 11:49:12PM +0100, Alfred M. Szmidt wrote:
> 
>    > | 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.
> 
> The error is not in the included file.

What do you mean the error is not the included file?  The include
statement may have been leftover from a debugging session and should
have been removed to not conflict with the CALL statement. 

>    > 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
> 
> No, this is not needed.  As has been repeated several times by various
> people.  The patch fixes the problem to the same extent that g77 fixed
> it.  Such extra conformance is not needed at this point.

First, you and others ask us to make gfortran conform to the GNU standard
for error formats.  I point out it is not trivial and gfortran's error
reporting mechanism works.  Someone comes up with a bandaid patch that
doesn't yield conformance but makes some people happy because it makes
their immediate problem go away.  I again point out the bandaid patch
does not yield conformance, and now your saying "Well, it's good enough.
We really did not mean that gfortran should conform to the GNU standard."  

-- 
Steve