From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20659 invoked by alias); 3 Aug 2016 15:59:19 -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 20649 invoked by uid 89); 3 Aug 2016 15:59:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=escaped, literals, concatenated, circumstances 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; Wed, 03 Aug 2016 15:59:18 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9DC768122E; Wed, 3 Aug 2016 15:59:16 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-194.phx2.redhat.com [10.3.116.194]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u73FxGuj021089; Wed, 3 Aug 2016 11:59:16 -0400 Subject: Re: [PATCH 1/3] (v2) On-demand locations within string-literals To: Joseph Myers , David Malcolm References: <97742eee-c1f8-d6ee-d86c-9af4113719eb@redhat.com> <1469553065-13642-1-git-send-email-dmalcolm@redhat.com> Cc: gcc-patches@gcc.gnu.org From: Jeff Law Message-ID: Date: Wed, 03 Aug 2016 15:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00213.txt.bz2 On 07/29/2016 03:42 PM, Joseph Myers wrote: > On Tue, 26 Jul 2016, David Malcolm wrote: > >> This patch implements precise tracking of source locations for the >> individual chars within string literals, so that we can e.g. underline >> specific ranges in -Wformat diagnostics. It handles macros, >> concatenated tokens, escaped characters etc. > > What if the string literal results from stringizing other tokens (which > might have arisen in turn from macro expansion, including expansion of > built-in macros not just those defined in source files, etc.)? "You don't > get precise locations" would be a fine answer for such cases - provided > there is good testsuite coverage of them to show they don't crash the > compiler or underline nonsensical characters. I think losing precise locations in some circumstances would be fine as well -- as long as we understand the limitations. And, yes, crashing or underlining nonsensical characters would be bad, so it'd be obviously good to test some of that to ensure the fallbacks work as expected. jeff