From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 67E803858CDA for ; Sun, 31 Jul 2022 15:05:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 67E803858CDA Received: by mail-lj1-x22b.google.com with SMTP id r14so9795733ljp.2 for ; Sun, 31 Jul 2022 08:05:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=hCOowCgtFVb5OiIge1T/XuW0P30oyf1GQaS03C5JS4Q=; b=Hxdo7hAKvkHLso8FWXjukaY8F79JTG0KPHTpnpbuAJKPQYvRAXJXYRKyv6SsSROc3M B/OsYq0EUm81qKVvWT87Uu0qC0Fw1FWmHy6GWEtpGQMWOt0lDhJd5vsumHDBZFwMVRna eWBHnnYVWXQ2EtY0nC64cdSJLNEk56j4osB8Y9zNCbi40v9Ewul9lC46FT10n5qjhcRk PjysqOUoQhwFv7ZAAx+5X6hDf70tUXN3+q7qZqsoyimYN2aROB/GW18aWrFoExPjn+Ad xnElHkq6yAdAoRKd+/MKU8FGerTfUnwKtG91q/HOJIhYTj6OM9pC4xWB+kJdqSgjRApG Pguw== X-Gm-Message-State: AJIora8zHO4BYZPj4EEEGqwohOAKpvTj857PnY6ug4l2ckEo2QE3vtfJ YoO+Q4YiZcJ8PNwAJeYJ+xa/4AhOkiDoVgCTRVg= X-Google-Smtp-Source: AGRyM1vhaWcf3WAIDAtAwfjXzZHsIIvygwzBkasFYvMOLJPhx9SbpuOgaOnoBaKdICqKuXINApoRyooCTo1MtsIbSnI= X-Received: by 2002:a2e:854e:0:b0:25e:2f45:5212 with SMTP id u14-20020a2e854e000000b0025e2f455212mr3749283ljj.449.1659279940599; Sun, 31 Jul 2022 08:05:40 -0700 (PDT) MIME-Version: 1.0 References: <20220724043902.1777378-1-tom@honermann.net> <20220724043902.1777378-2-tom@honermann.net> In-Reply-To: From: Lewis Hyatt Date: Sun, 31 Jul 2022 11:05:29 -0400 Message-ID: Subject: Re: [PATCH 1/1] c++/106423: Fix pragma suppression of -Wc++20-compat diagnostics. To: Tom Honermann , Joseph Myers Cc: gcc-patches List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3029.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Sun, 31 Jul 2022 15:05:44 -0000 On Sat, Jul 30, 2022 at 7:06 PM Tom Honermann via Gcc-patches wrote: > > On 7/27/22 7:09 PM, Joseph Myers wrote: > > On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote: > > > >> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode" > >> (see handle_pragma_diagnostic_early) for the C++ frontend and, as such, > >> require that the target diagnostic option be enabled for the preprocessor > >> (see c_option_is_from_cpp_diagnostics). This change modifies the > >> -Wc++20-compat option definition to register it as a preprocessor option > >> so that its associated diagnostics can be suppressed. The changes also > > There are lots of C++ warning options, all of which should support pragma > > suppression regardless of whether they are relevant to the preprocessor or > > not. Do they all need this kind of handling, or is it only -Wc++20-compat > > that has some kind of problem? > > I had only checked -Wc++20-compat when working on the patch. > > I did some spot checking now and confirmed that suppression works as > expected for C++ for at least the following warnings: > -Wuninitialized > -Warray-compare > -Wbool-compare > -Wtautological-compare > -Wterminate > > I don't know the diagnostic framework well. As best I can tell, this > issue is specific to the -Wc++20-compat option and when the particular > diagnostic is issued (e.g., during lexing as opposed to during parsing). > The following call chains appear to be relevant. > cp_lexer_new_main -> cp_lexer_handle_early_pragma -> > c_invoke_early_pragma_handler > cp_parser_* -> cp_parser_pragma -> c_invoke_pragma_handler > (where * might be "declaration", "toplevel_declaration", > "class_head", "objc_interstitial_code", ...) > > The -Wc++20-compat enabled warning regarding new keywords in C++20 is > issued from cp_lexer_get_preprocessor_token. > > Tom. > I have been working on improving the handling of "#pragma GCC diagnostic" lately. The behavior for C++ changed since r13-1544 (https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e46f4d7430c5210465791603735ab219ef263c51). I have some more comments about the patch's approach on the PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c44). "#pragma GCC diagnostic" formerly did not work in C++ at all, for diagnostics generated by libcpp, because C++ obtains all the tokens from libcpp first (including deferred pragmas), and then processes them afterward, too late to take effect for diagnostics that libcpp has already emitted. r13-1544 fixed this up by adding an early pragma handler, which runs as soon as a deferred pragma token is seen and handles diagnostic pragmas if they pertain to libcpp-controlled diagnostics. Non-libcpp diagnostics still need to be handled later, during parsing, or else they get processed too early and it leads to other problems. Basically, now each diagnostic pragma is handled as close in time as possible to the time the associated diagnostics might be generated. The early pragma handler determines that an option comes from libcpp, and so should be subject to early processing, if it was marked as such in the options definition file. Tom's patch points out that -Wc++20-compat needs to be handled early, and so marking it as a libcpp diagnostic in c-family/c.opt arranges for that to work as intended. Now one potential objection here is that -Wc++20-compat warnings are not technically generated by libcpp. They are generated by the C++ frontend immediately after lexing an identifier token from libcpp (cp_lexer_get_preprocessor_token()). But the distinction between these two steps is rather blurry and it seems logical to me, to denote this as a libcpp-related option. Also, the same is already done for -Wc++11-compat. Otherwise, we would need to add some new option property to indicate which ones need to be handled for pragmas at lexing time rather than parsing time. At the moment I don't see any other diagnostics issued from cp_lexer_get_preprocessor_token() that would need similar adjustments. Assuming the approach is OK, it might be nice to add a comment to that function, indicating that any diagnostics emitted there should be annotated as libcpp options in the .opt file? -Lewis