From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3500 invoked by alias); 11 Jul 2017 17:34: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 3476 invoked by uid 89); 11 Jul 2017 17:33:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Jul 2017 17:33:57 +0000 Received: by mail-wr0-f176.google.com with SMTP id r103so8632566wrb.0 for ; Tue, 11 Jul 2017 10:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=ExXYm2mri7XBvRMREONvmXZ5C5D7oktRrznhprWFJro=; b=nBk7Rn7wdA9v9BluYNRjOPocN90zVuGOLajTJCwGrwov2R2HYEbYBq74wY2/P3Cuq+ uuOxpapmiG6cSRan5uDxAcY+5PE487OSDhhiZXAbYhLoCLVBd0hafqXzN5WFWPHwHXXD /U+7PzwsKQ2kF0x/+qc7dpO94m4OaHVSMYZkwPlA4t+5bh8uLQ/mMouSZUnG+zL2WAiQ MXFEJuCm+V2Qe6IIw4kSlusVjERW2VJcCy0QOWskqOx11bSWJIF6MRUXBLUjwmb0fSVl dpYKFeN0XRi6DNdBdgaBUOaClES/f7jii2aN/uUyGy3shYT3zp2V+fjwWGDvuOayqts7 sSAA== X-Gm-Message-State: AIVw112sAf02rEzJ5ivdPKEvh6ReOaUFRNnBtAGGSrbik+Bp9e2D6eK5 vasJIYeE588rHzxDlhF5dA== X-Received: by 10.28.170.194 with SMTP id t185mr3567747wme.114.1499794435258; Tue, 11 Jul 2017 10:33:55 -0700 (PDT) Received: from localhost ([2.26.27.176]) by smtp.gmail.com with ESMTPSA id r70sm3147030wmb.16.2017.07.11.10.33.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Jul 2017 10:33:54 -0700 (PDT) From: Richard Sandiford To: David Malcolm Mail-Followup-To: David Malcolm ,gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: gcc-patches@gcc.gnu.org Subject: Re: [committed] diagnostics: support compact printing of secondary locations References: <87y3s5pcvm.fsf@linaro.org> <1499784198-36796-1-git-send-email-dmalcolm@redhat.com> Date: Tue, 11 Jul 2017 17:34:00 -0000 In-Reply-To: <1499784198-36796-1-git-send-email-dmalcolm@redhat.com> (David Malcolm's message of "Tue, 11 Jul 2017 10:43:18 -0400") Message-ID: <87tw2iswse.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-07/txt/msg00545.txt.bz2 David Malcolm writes: > On Mon, 2017-07-03 at 19:57 +0100, Richard Sandiford wrote: >> [Thanks for all your diagnostic work btw.] >> >> David Malcolm writes: >> > clang can also print notes about matching opening symbols >> > e.g. the note here: >> > >> > missing-symbol-2.c:25:22: error: expected ']' >> > const char test [42; >> > ^ >> > missing-symbol-2.c:25:19: note: to match this '[' >> > const char test [42; >> > ^ >> > which, although somewhat redundant for this example, seems much >> > more >> > useful if there's non-trivial nesting of constructs, or more than a >> > few >> > lines separating the open/close symbols (e.g. showing a stray >> > "namespace {" >> > that the user forgot to close). >> > >> > I'd like to implement both of these ideas as followups, but in >> > the meantime, is the fix-it hint patch OK for trunk? >> > (successfully bootstrapped & regrtested on x86_64-pc-linux-gnu) >> >> Just wondering: how easy would it be to restrict the note to the >> kinds >> of cases you mention? TBH I think clang goes in for extra notes too >> much, and it's not always that case that an "expected 'foo'" message >> really is caused by a missing 'foo'. It'd be great if there was some >> way of making the notes a bit more discerning. :-) >> >> Or maybe do something like restrict the extra note to cases in which >> the >> opening character is on a different line and use an underlined range >> when the opening character is on the same line? >> >> Thanks, >> Richard > > Thanks. > > This patch implements a new method: > > bool gcc_rich_location::add_location_if_nearby (location_t); > > to make it easy for a diagnostic to compactly print secondary locations > for these kinds of cases, falling back to printing them via a note > otherwise. > > Usage example (adapted from the one in the header): > > gcc_rich_location richloc (primary_loc); > bool added secondary = richloc.add_location_if_nearby (secondary_loc); > error_at_rich_loc (&richloc, "missing %qs", "}"); > if (!added secondary) > inform (secondary_loc, "here's the associated %qs", "{"); > > When primary_loc and secondary_loc are on the same line this will print: > > test.c:1:39: error: missing '}' > struct same_line { double x; double y; ; > ~ ^ > > When they are on different lines, this will print: > > test.c:6:1: error: missing '}' > ; > ^ > test.c:3:1: note: here's the associated '{' > { > ^ Thanks, this looks great! Richard