From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Kargl Newsgroups: gmane.comp.gcc.fortran,gmane.emacs.devel Subject: Re: Emacs and GFortran Date: Wed, 1 Nov 2006 14:35:48 -0800 Message-ID: <20061101223548.GA72295@troutmask.apl.washington.edu> References: <200611011037.12356.wt@atmos.colostate.edu> <20061101180354.GA62686@troutmask.apl.washington.edu> <20061101203931.E775C4401A@Psilocybe.Update.UU.SE> <20061101213056.GA63890@troutmask.apl.washington.edu> <20061101215142.51A0944013@Psilocybe.Update.UU.SE> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1162420710 2931 80.91.229.2 (1 Nov 2006 22:38:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Nov 2006 22:38:30 +0000 (UTC) Cc: wt@atmos.colostate.edu, fortran@gcc.gnu.org, emacs-devel@gnu.org Original-X-From: fortran-return-15396-gcgf-fortran=m.gmane.org@gcc.gnu.org Wed Nov 01 23:38:27 2006 Return-path: Envelope-to: gcgf-fortran@gmane.org Original-Received: from sourceware.org ([209.132.176.174]) by ciao.gmane.org with smtp (Exim 4.43) id 1GfOix-0003py-Q9 for gcgf-fortran@gmane.org; Wed, 01 Nov 2006 23:38:20 +0100 Original-Received: (qmail 32674 invoked by alias); 1 Nov 2006 22:38:18 -0000 Original-Received: (qmail 32665 invoked by uid 22791); 1 Nov 2006 22:38:17 -0000 X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Original-Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.208.78.105) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Nov 2006 22:38:12 +0000 Original-Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.13.8/8.13.8) with ESMTP id kA1MZn59020701; Wed, 1 Nov 2006 14:35:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Original-Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.8/8.13.8/Submit) id kA1MZmIF020700; Wed, 1 Nov 2006 14:35:48 -0800 (PST) (envelope-from sgk) Original-To: "Alfred M. Szmidt" Content-Disposition: inline In-Reply-To: <20061101215142.51A0944013@Psilocybe.Update.UU.SE> User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Post: List-Help: , Original-Sender: fortran-owner@gcc.gnu.org Xref: news.gmane.org gmane.comp.gcc.fortran:15365 gmane.emacs.devel:61577 Archived-At: 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