From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76225 invoked by alias); 30 Jun 2017 15:40:45 -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 74872 invoked by uid 89); 30 Jun 2017 15:40:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:2823, click 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 ESMTP; Fri, 30 Jun 2017 15:40:41 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 81D7C7A16D for ; Fri, 30 Jun 2017 15:40:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 81D7C7A16D Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 81D7C7A16D Received: from localhost.localdomain (ovpn-117-103.phx2.redhat.com [10.3.117.103]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4E5AD60A98; Fri, 30 Jun 2017 15:40:40 +0000 (UTC) Subject: Re: [PING] Re: [PATCH] c/c++: Add fix-it hints for suggested missing #includes To: David Malcolm , gcc-patches@gcc.gnu.org References: <1493915800-40315-1-git-send-email-dmalcolm@redhat.com> <1495828478.9289.78.camel@redhat.com> From: Jeff Law Message-ID: <56989fdb-2510-c4d1-489f-bd6b3ba2041d@redhat.com> Date: Fri, 30 Jun 2017 15:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <1495828478.9289.78.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg02398.txt.bz2 On 05/26/2017 01:54 PM, David Malcolm wrote: > Ping: > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00321.html > > On Thu, 2017-05-04 at 12:36 -0400, David Malcolm wrote: >> As of r247522, fix-it-hints can suggest the insertion of new lines. >> >> This patch uses this to implement a new "maybe_add_include_fixit" >> function in c-common.c and uses it in the two places where the C and >> C++ >> frontend can suggest missing #include directives. [1] >> >> The idea is that the user can then click on the fix-it in an IDE >> and have it add the #include for them (or use -fdiagnostics-generate >> -patch). >> >> Examples can be seen in the test cases. >> >> The function attempts to put the #include in a reasonable place: >> immediately after the last #include within the file, or at the >> top of the file. It is idempotent, so -fdiagnostics-generate-patch >> does the right thing if several such diagnostics are emitted. >> >> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu. >> >> OK for trunk? >> >> [1] I'm working on a followup which tweaks another diagnostic so that >> it >> can suggest that a #include was missing, so I'll use it there as >> well. >> >> gcc/c-family/ChangeLog: >> * c-common.c (try_to_locate_new_include_insertion_point): New >> function. >> (per_file_includes_t): New typedef. >> (added_includes_t): New typedef. >> (added_includes): New variable. >> (maybe_add_include_fixit): New function. >> * c-common.h (maybe_add_include_fixit): New decl. >> >> gcc/c/ChangeLog: >> * c-decl.c (implicitly_declare): When suggesting a missing >> #include, provide a fix-it hint. >> >> gcc/cp/ChangeLog: >> * name-lookup.c (get_std_name_hint): Add '<' and '>' around >> the header names. >> (maybe_suggest_missing_header): Update for addition of '<' and >> '>' >> to above. Provide a fix-it hint. >> >> gcc/testsuite/ChangeLog: >> * g++.dg/lookup/missing-std-include-2.C: New text case. >> * gcc.dg/missing-header-fixit-1.c: New test case. Generally OK. But a few comments on how you find the location for where to suggest the new #include. It looks like you're walking the whole table every time?!? Shouldn't you at least bound things between start of file and the point where an error was issued? ie, if you used an undefined type on line XX, a #include after line XX makes no sense to resolve the error. I'm not sure how often this will get called when someone does something stupid and needs the #include. But ISTM you're looking for two bounds. For the "last" case you start at the statement which generated the error and walk backwards stopping when you find the last map. For the "first" case, you start at the beginning and walk forward to find the map, then quit. Are those not appropriate here? Jeff