From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72683 invoked by alias); 15 Nov 2018 17:35:49 -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 72642 invoked by uid 89); 15 Nov 2018 17:35:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=unusual, candidates, standing X-HELO: mail-qk1-f195.google.com Received: from mail-qk1-f195.google.com (HELO mail-qk1-f195.google.com) (209.85.222.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Nov 2018 17:35:43 +0000 Received: by mail-qk1-f195.google.com with SMTP id d135so33039749qkc.12 for ; Thu, 15 Nov 2018 09:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DvgCvd2cbcURS0/ylELw+HmGcHF1NPehL8jooRinFQM=; b=mOMUzr/IkQ9mxQbu7WuT494hy3GAtWNfcBUgej7fx4Qcawg5aSvUIdK5APYtTDi1oK uOjt04VYHsIrJAX0Hqmi+ul78bciohPJloDclgF0Bi4yvQBX6ilibnqfVYl3lYr74+Og puxad+UPpY8XthTbxC2sfw64BCX7Oe1fPgnTjuv3uB+u91H27fNb1acCaoqchmQuYfN3 IA95JvXdhutypdVxe9qjm9jVijR1ZvI5VGyyZU5H5Q2CQTp4JadScQISzXBxHJXc+nHb d9sIri8Qec6dShYGY6SXGR1Po5Aab3Mh+5mIWNmRgi5Es1kAOhdTd6mw852Zdl2k89A6 2/9A== Return-Path: Received: from localhost.localdomain (184-96-239-209.hlrn.qwest.net. [184.96.239.209]) by smtp.gmail.com with ESMTPSA id n71sm7776789qkh.59.2018.11.15.09.35.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 09:35:40 -0800 (PST) Subject: Re: [PATCH] RFC: elide repeated source locations (PR other/84889) To: David Malcolm , gcc-patches@gcc.gnu.org References: <1541990633-4614-1-git-send-email-dmalcolm@redhat.com> <37cb2057-f9dd-828d-5428-46f85e1c3c83@gmail.com> <1542229976.4619.41.camel@redhat.com> From: Martin Sebor Message-ID: <39fa7092-b7c9-bede-f685-5268df229da1@gmail.com> Date: Thu, 15 Nov 2018 17:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1542229976.4619.41.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg01397.txt.bz2 On 11/14/2018 02:12 PM, David Malcolm wrote: > On Mon, 2018-11-12 at 13:37 -0700, Martin Sebor wrote: >> On 11/11/2018 07:43 PM, David Malcolm wrote: >>> We often emit more than one diagnostic at the same source location. >>> For example, the C++ frontend can emit many diagnostics at >>> the same source location when suggesting overload candidates. >>> >>> For example: >>> >>> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C: In >>> function 'int test_3(s, t)': >>> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: >>> error: no match for 'operator&&' (operand types are 's' and 't') >>> 38 | return param_s && param_t; >>> | ~~~~~~~~^~~~~~~~~~ >>> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: >>> note: candidate: 'operator&&(bool, bool)' >>> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: >>> note: no known conversion for argument 2 from 't' to 'bool' >>> >>> This is overly verbose. Note how the same location has been >>> printed >>> three times, obscuring the pertinent messages. >>> >>> This patch add a new "elide" value to -fdiagnostics-show-location= >>> and makes it the default (previously it was "once"). With elision >>> the above is printed as: >>> >>> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C: In >>> function 'int test_3(s, t)': >>> ../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C:38:18: >>> error: no match for 'operator&&' (operand types are 's' and 't') >>> 38 | return param_s && param_t; >>> | ~~~~~~~~^~~~~~~~~~ >>> = note: candidate: 'operator&&(bool, bool)' >>> = note: no known conversion for argument 2 from 't' to >>> 'bool' >>> >>> where the followup notes are printed with a '=' lined up with >>> the source code margin. >>> >>> Thoughts? >> >> I agree the long pathname in the notes is at first glance redundant >> but I'm not sure about using '=' as a shorthand for it. I have >> written many scripts to parse GCC output to extract all diagnostics >> (including notes) and publish those on a Web page somewhere, as I'm >> sure must have others. All those scripts would stop working with >> this change and require changes to the build system to work again. >> Making those changes can be a substantial undertaking in some >> organizations. >> >> Have you considered printing just the file name instead? Or any >> other alternatives? > > "-fdiagnostics-show-location=once" will restore the old behavior. > Alternatively, if you want to parse GCC output, I'm adding a JSON > output format; see: > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01038.html > (I'm testing an updated version of that patch) I understand the change can be disabled by an option. I also like making the repetitive pathnames shorter, but the concern I have is that the change to use the '=' notation by default, besides being rather unusual and not necessarily intuitive, will break scripts that search for the pattern: "[^:]*:[1-9][0-9]*:[1-9][0-9]*: (error|note|warning): " and adding a new option to a large build system can be quite difficult. I suspect it would also make the notes difficult or even impossible to associate with the corresponding errors or warnings in parallel builds (where they may be interleaved with diagnostics from different compilations). I think it's possible to make the output shorter/less repetitive without these side-effects by keeping the current format and instead abbreviating the pathname, e.g. by printing just the file name (or ".../filename.c:" with the ellipsis standing in for the long pathname, though the ellipsis would require adjusting the scripts that sort diagnostics by the pathname). Martin PS As an aside, if we wanted to shorten all pathnames this same idea could be extended to errors and warnings as well by printing the pathname in the first one and just the filename in subsequent ones in the same file.