From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43646 invoked by alias); 21 Nov 2015 08:22:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 43563 invoked by uid 89); 21 Nov 2015 08:21:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 21 Nov 2015 08:21:57 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id D8CA6B0CEE for ; Sat, 21 Nov 2015 08:21:55 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAL8LsSJ028088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Nov 2015 03:21:55 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id tAL8LqGD014050; Sat, 21 Nov 2015 09:21:53 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id tAL8LpfX014049; Sat, 21 Nov 2015 09:21:51 +0100 Date: Sat, 21 Nov 2015 08:22:00 -0000 From: Jakub Jelinek To: Jason Merrill Cc: David Malcolm , gcc-patches@gcc.gnu.org Subject: Re: [PATCH/RFC] C++ FE: expression ranges (v2) Message-ID: <20151121082151.GQ5675@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1446868737-3306-1-git-send-email-dmalcolm@redhat.com> <1447563717-24429-1-git-send-email-dmalcolm@redhat.com> <564E3512.9080701@redhat.com> <56501A61.6010806@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56501A61.6010806@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02565.txt.bz2 On Sat, Nov 21, 2015 at 02:16:49AM -0500, Jason Merrill wrote: > On 11/19/2015 03:46 PM, Jason Merrill wrote: > >On 11/15/2015 12:01 AM, David Malcolm wrote: > >>As with the C frontend, there's an issue with tree nodes that > >>don't have locations: VAR_DECL, INTEGER_CST, etc: > >> > >> int test (int foo) > >> { > >> return foo * 100; > >> ^^^ ^^^ > >> } > >> > >>where we'd like to access the source spelling ranges of the expressions > >>during parsing, so that we can use them when reporting parser errors. > > > >Hmm, I had been thinking to address this in the C++ front end by > >wrapping uses in another tree: NOP_EXPR for rvalues, VIEW_CONVERT_EXPR > >for lvalues. > > On the other hand, my direction seems likely to cause more issues, > especially with code that doesn't yet know how to handle VIEW_CONVERT_EXPR, > and could create ambiguity with explicit conversions. So I guess your > approach seems reasonable. But your approach would allow better diagnostics even in places where you don't have the structures with tree, location_t pairs around. With that it will be limited solely to the parser and nothing else, so even template instantiation if it is something that can be only detected when instantiating would be too late. I think using a new tree (rather than using NOP_EXPR/VIEW_CONVERT_EXPR) that would be just some expression with location and teaching the FE and folder about it might be even better. Jakub