From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 449BB3834E5D for ; Tue, 24 May 2022 13:57:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 449BB3834E5D Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-557-P7oxOkrqOWWQFnSN4GSMKg-1; Tue, 24 May 2022 09:57:04 -0400 X-MC-Unique: P7oxOkrqOWWQFnSN4GSMKg-1 Received: by mail-qv1-f69.google.com with SMTP id kl23-20020a056214519700b0046200065604so10167431qvb.19 for ; Tue, 24 May 2022 06:57:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=FLyFyjHxG0RCB7AY9V/EiDqcxUvRz2HOzTlV0TCi3U4=; b=yfe+PZtDvH6SC0jn4p2xrW1tM0T9Qdj8nj4LDKmpTa60S++19kpNRyZHnsgP4acnW4 STFLesbArhsL7LPEOGi6/XI9ehwSvnQCqbbTTuBy/yO3QXgGazum5AXZsXiKhPnoPVP9 A9uu5FchcxvvD+X5OM1CKepeAGKeFebXX756tCS8aTQnoQhBOMUfaCw/2v+aU+8L2NoM 8XfOFdYs5SJMFIl9R2Pkr47wzT1F++m8mjvUn+2NScAUHfd2pyRRE2znEbbyZXZ8WmS3 b2uWbAP14jgR5Rnb1i4jZwjbMP8pCi272ROTyFsSzcISQnFGUjIB8u0sLFBIB+a3F0hn Lqhw== X-Gm-Message-State: AOAM532eSy8o0RXdSZObfmoqXRUxqHmcTrKrFIgVhC85n+eGeU1XNqYg Y8AOOy/SCWo034y0YowK6VlB4uzxzo/HxVNbF9E9T3lNdQOg6IeYPVgThgyknPBIzpdn0lg/Yz3 4C4yKlDbV8JfCKeSAmQ== X-Received: by 2002:ac8:7c51:0:b0:2f3:cb71:c7a6 with SMTP id o17-20020ac87c51000000b002f3cb71c7a6mr20015028qtv.409.1653400623301; Tue, 24 May 2022 06:57:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxyXxXAcOyXarkbALHzkcyAszGHusjw8BwcQCNGgqLDqqzMdLiAhj9WisaSNG9NVvc+8KfCcw== X-Received: by 2002:ac8:7c51:0:b0:2f3:cb71:c7a6 with SMTP id o17-20020ac87c51000000b002f3cb71c7a6mr20015012qtv.409.1653400623021; Tue, 24 May 2022 06:57:03 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id z3-20020ae9f443000000b0069fc13ce225sm6039340qkl.86.2022.05.24.06.57.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 06:57:02 -0700 (PDT) Message-ID: <801f6986dc99c122fb095459fe943dbadd58333c.camel@redhat.com> Subject: Re: [PATCH] c: Improve build_component_ref diagnostics [PR91134] From: David Malcolm To: Jakub Jelinek , "Joseph S. Myers" , Marek Polacek Cc: gcc-patches@gcc.gnu.org Date: Tue, 24 May 2022 09:57:01 -0400 In-Reply-To: References: User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2022 13:57:06 -0000 On Tue, 2022-05-24 at 09:25 +0200, Jakub Jelinek via Gcc-patches wrote: > Hi! > > On the following testcase (the first dg-error line) we emit a weird > diagnostics and even fixit on pointerpointer->member > where pointerpointer is pointer to pointer to struct and we say > 'pointerpointer' is a pointer; did you mean to use '->'? > The first part is indeed true, but suggesting -> when the code > already > does use -> is confusing. > The following patch adjusts callers so that they tell it if it is > from > . parsing or from -> parsing and in the latter case suggests to > dereference > the left operand instead by adding (* before it and ) after it > (before ->). > Or would a suggestion to add [0] before -> be better? > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > [...snip implementation...] >   > --- gcc/testsuite/gcc.dg/pr91134.c.jj   2022-05-23 20:31:11.751001817 > +0200 > +++ gcc/testsuite/gcc.dg/pr91134.c      2022-05-23 20:30:45.291268997 > +0200 > @@ -0,0 +1,13 @@ > +/* PR c/91134 */ > + > +struct X { int member; } x; > + > +int > +foo (void) > +{ > +  struct X *pointer = &x; > +  struct X **pointerpointer = &pointer; > +  int i = *pointerpointer->member;     /* { dg-error > "'pointerpointer' is a pointer to pointer; did you mean to > dereference it before applying '->' to it\\\?" } */ > +  int j = pointer.member;              /* { dg-error "'pointer' is a > pointer; did you mean to use '->'\\\?" } */ > +  return i + j; > +} Ideally we'd have an automated check that the fix-it hint fixes the code, but failing that, I like to have at least some DejaGnu test coverage for fix-it hints - something like the tests in gcc.dg/fixits.c or gcc.dg/semicolon-fixits.c, perhaps? Dave