From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1673 invoked by alias); 15 Nov 2009 17:34:12 -0000 Received: (qmail 1658 invoked by uid 22791); 15 Nov 2009 17:34:10 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 15 Nov 2009 17:33:04 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 9302F290025; Sun, 15 Nov 2009 18:33:01 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Yffajqnd8Y; Sun, 15 Nov 2009 18:33:00 +0100 (CET) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id AD61B29001F; Sun, 15 Nov 2009 18:33:00 +0100 (CET) Received: by province.act-europe.fr (Postfix, from userid 525) id 9C4AF164FB3; Sun, 15 Nov 2009 18:33:00 +0100 (CET) Date: Sun, 15 Nov 2009 17:34:00 -0000 From: Arnaud Charlet To: Tom Tromey Cc: gcc@gcc.gnu.org, Arnaud Charlet Subject: Re: handling of TAB in column number Message-ID: <20091115173300.GB38071@adacore.com> References: <20091115131047.GA97288@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00410.txt.bz2 > I never ran the patch through the test suite. I assume it would require > some test suite changes. OK, I can do that and see where things are. > Also, I've experimented more with Aldy's location improvement patch > (which is now on mainline, I think diagnostics-branch is closed), and > Emacs (I used Emacs 23 for my experiment -- automated code rewriting > using gcc error messages to decide where to edit) agrees with what GCC > generates now. So, changing this might actually be the wrong thing to > do now. Well, I guess it's a chicken and egg problem: Emacs might have been modified to follow whatever GCC is outputting right now (even though it's not following GNU standard). Since the addition of columns and in particular enabling of columns by default is pretty recent, I think it still makes sense to make this change, otherwise later might indeed be too late. Alternatively we could have an option, but that would be overkill IMO. > If you're interested in locations, I have a couple other unfinished > location patches that could use some attention. One is an attempt to > fix all the errors in libcpp to use the correct location. The other is > a patch to include macro expansion information in a location_t. I'm working on generating cross-ref info from GCC for C/C++ sources. So I'm not too interested directly in error location (your first patch above), but the second patch you mention might be of interest indeed, can you please send it to me? I'm not sure I understand what 'include macro expansion info in a location_t' means exactly, so I'm curious. Also, what about column info in libcpp itself, in particular when handling macros? It seems that when e.g. the define() or used_define() callbacks are called, the only useful sloc info stored in input_location (itself kind of deprecated as I understand it) is the current line, with column 0. Might actually be related to your first patch mentioned above? Arno