public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Martin Sebor <msebor@gmail.com>,
	David Malcolm <dmalcolm@redhat.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 1/13] v2 [PATCH 1/13] Add support for per-location warning groups (PR 74765)
Date: Wed, 23 Jun 2021 23:26:27 -0600	[thread overview]
Message-ID: <dfa0b276-a6be-309b-4948-6ad9b06f0f1f@gmail.com> (raw)
In-Reply-To: <015d6a49-d4d8-3ed8-d2b9-2999b466da55@gmail.com>



On 6/23/2021 1:47 PM, Martin Sebor via Gcc-patches wrote:
> On 6/22/21 5:28 PM, David Malcolm wrote:
>> On Tue, 2021-06-22 at 19:18 -0400, David Malcolm wrote:
>>> On Fri, 2021-06-04 at 15:41 -0600, Martin Sebor wrote:
>>>> The attached patch introduces the suppress_warning(),
>>>> warning_suppressed(), and copy_no_warning() APIs without making
>>>> use of them in the rest of GCC.  They are in three files:
>>>>
>>>>     diagnostic-spec.{h,c}: Location-centric overloads.
>>>>     warning-control.cc: Tree- and gimple*-centric overloads.
>>>>
>>>> The location-centric overloads are suitable to use from the
>>>> diagnostic
>>>> subsystem.  The rest can be used from the front ends and the middle
>>>> end.
>>>
>>> [...snip...]
>>>
>>>> +/* Return true if warning OPT is suppressed for decl/expression
>>>> EXPR.
>>>> +   By default tests the disposition for any warning.  */
>>>> +
>>>> +bool
>>>> +warning_suppressed_p (const_tree expr, opt_code opt /* =
>>>> all_warnings */)
>>>> +{
>>>> +  const nowarn_spec_t *spec = get_nowarn_spec (expr);
>>>> +
>>>> +  if (!spec)
>>>> +    return get_no_warning_bit (expr);
>>>> +
>>>> +  const nowarn_spec_t optspec (opt);
>>>> +  bool dis = *spec & optspec;
>>>> +  gcc_assert (get_no_warning_bit (expr) || !dis);
>>>> +  return dis;
>>>
>>> Looking through the patch, I don't like the use of "dis" for the "is
>>> suppressed" bool, since...
>
> It's an argument to a a function, unlikely to confuse anyone.  But
> I also don't think it's important enough to argue about so I changed
> it along with the comment below.
>
>>>
>>> [...snip...]
>>>
>>>> +
>>>> +/* Enable, or by default disable, a warning for the statement STMT.
>>>> +   The wildcard OPT of -1 controls all warnings.  */
>>>
>>> ...I find the above comment to be confusingly worded due to the double-
>>> negative.
>>>
>>> If I'm reading your intent correctly, how about this wording:
>>>
>>> /* Change the supression of warnings for statement STMT.
>>>     OPT controls which warnings are affected.
>>>     The wildcard OPT of -1 controls all warnings.
>>>     If SUPP is true (the default), enable the suppression of the
>>> warnings.
>>>     If SUPP is false, disable the suppression of the warnings.  */
>>>
>>> ...and rename "dis" to "supp".
>>>
>>> Or have I misread the intent of the patch?
>>>
>>>> +
>>>> +void
>>>> +suppress_warning (gimple *stmt, opt_code opt /* = all_warnings */,
>>>> +                 bool dis /* = true */)
>>>
>>>> +{
>>>> +  if (opt == no_warning)
>>>> +    return;
>>>> +
>>>> +  const key_type_t key = convert_to_key (stmt);
>>>> +
>>>> +  dis = suppress_warning_at (key, opt, dis) || dis;
>>>> +  set_no_warning_bit (stmt, dis);
>>>> +}
>>>
>>> [...snip...]
>>
>> Also, I think I prefer having a separate entrypoints for the "all
>> warnings" case; on reading through the various patches I think that in
>> e.g.:
>>
>> -      TREE_NO_WARNING (*expr_p) = 1;
>> +      suppress_warning (*expr_p);
>>
>> I prefer:
>>
>>            suppress_warnings (*expr_p);
>>
>> (note the plural) since that way we can grep for them, and it seems
>> like better grammar to me.
>>
>> Both entrypoints could be implemented by a static suppress_warning_1
>> internally if that makes it easier.
>>
>> In that vein, "unsuppress_warning" seems far clearer to me that
>> "suppress_warning (FOO, false)"; IIRC there are very few uses of this
>> non-default arg (I couldn't find any in a quick look through the v2
>> kit).
>>
>> Does this make sense?
>
> In my experience, names that differ only slightly (such as in just
> one letter) tend to easily lead to frustrating mistakes.  The new
> warning_suppressed_p() added in this patch also handles multiple
> warnings (via a wildcard) and uses a singular form, and as do
> the gimple_{get,set}no_warning() functions that are being replaced.
> So I don't think the suggested change is needed or would be
> an improvement.
>
> Similarly, there is no gimple_unset_no_warning() today and I don't
> think adding unsuppress_warning() is necessary or would add value,
> especially since there are just a handful of callers that re-enable
> warnings.  For the callers that might need to enable or disable
> a warning based on some condition, it's more convenient to do so
> in a single call then by having to call different functions based
> the value of the condition.
>
> In the attached patch I've changed the comment as you asked and
> also renamed the dis argument to supp but kept the function names
> the same.  I've also moved a few changes to tree.h from a later
> patch to this one to let it stand alone and regtested it on its
> own on x86_64-linux.  I'll plan to go ahead with this version
> unless requestsfor substantive changes come up in the review of
> the rest  of the changes.
>
> Thanks
> Martin
>
> gcc-no-warning-1.diff
>
> Add support for per-location warning groups.
>
> gcc/ChangeLog:
>
> 	* Makefile.in (OBJS-libcommon): Add diagnostic-spec.o.
> 	* gengtype.c (open_base_files): Add diagnostic-spec.h.
> 	* diagnostic-spec.c: New file.
> 	* diagnostic-spec.h: New file.
> 	* tree.h (no_warning, all_warnings, suppress_warning_at): New
> 	declarations.
> 	* warning-control.cc: New file.
>
> diff --git a/gcc/diagnostic-spec.h b/gcc/diagnostic-spec.h
> new file mode 100644
> index 00000000000..62d9270ca6d
> --- /dev/null
> +++ b/gcc/diagnostic-spec.h
> @@ -0,0 +1,140 @@
> +/* Language-independent APIs to enable/disable per-location warnings.
> +
> +   Copyright (C) 2021 Free Software Foundation, Inc.
> +   Contributed by Martin Sebor <msebor@redhat.com>
> +
> +   This file is part of GCC.
> +
> +   GCC is free software; you can redistribute it and/or modify it under
> +   the terms of the GNU General Public License as published by the Free
> +   Software Foundation; either version 3, or (at your option) any later
> +   version.
> +
> +   GCC is distributed in the hope that it will be useful, but WITHOUT ANY
> +   WARRANTY; without even the implied warranty of MERCHANTABILITY or
> +   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> +   for more details.
> +
> +   You should have received a copy of the GNU General Public License
> +   along with GCC; see the file COPYING3.  If not see
> +   <http://www.gnu.org/licenses/>.  */
> +
> +#ifndef DIAGNOSTIC_SPEC_H_INCLUDED
> +#define DIAGNOSTIC_SPEC_H_INCLUDED
> +
> +#include "hash-map.h"
> +
> +/* A "bitset" of warning groups.  */
> +
> +struct nowarn_spec_t
Should probably be "class" not "struct".  Though I don't think we're 
necessarily consistent with this.
> +private:
> +  /* Bitset of warning groups.  */
> +  unsigned bits;
Our conventions are to prefix member fields with m_.

Note that a simple "unsigned" may just be 32 bits.  Though with your 
grouping that may not matter in practice.

I think with the nits fixed this is fine.  I know there's some 
disagreement on singular vs plural, but having two names differing by 
just that is probably going to be more confusing in the end, so I'm on 
the side of using the names as-is.

jeff

  reply	other threads:[~2021-06-24  5:26 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 22:02 [PATCH 0/11] warning control by group and location " Martin Sebor
2021-05-24 22:07 ` [PATCH 1/11] introduce xxx_no_warning APIs Martin Sebor
2021-05-24 22:09   ` [PATCH 2/11] use xxx_no_warning APIs in Ada Martin Sebor
2021-05-25  8:59     ` Eric Botcazou
2021-05-27 20:29       ` Martin Sebor
2021-05-24 22:10   ` [PATCH 3/11] use xxx_no_warning APIs in C Martin Sebor
2021-05-24 22:11   ` [PATCH 4/11] use xxx_no_warning APIs in C family Martin Sebor
2021-05-24 22:11   ` [PATCH 5/11] use xxx_no_warning APIs in C++ Martin Sebor
2021-05-24 22:12   ` [PATCH 6/11] use xxx_no_warning APIs in Fortran Martin Sebor
2021-05-24 22:13   ` [PATCH 7/11] " Martin Sebor
2021-05-24 22:14   ` [PATCH 8/11] use xxx_no_warning APIs in Objective-C Martin Sebor
2021-05-25 14:01     ` Iain Sandoe
2021-05-25 15:48       ` Martin Sebor
2021-05-25 15:56         ` Iain Sandoe
2021-05-24 22:15   ` [PATCH 9/11] use xxx_no_warning APIs in rl78 back end Martin Sebor
2021-05-24 22:16   ` [PATCH 10/11] use xxx_no_warning APIs in libcc1 Martin Sebor
2021-05-24 22:16   ` [PATCH 11/11] use xxx_no_warning APIs in the middle end Martin Sebor
2021-05-24 23:08     ` David Malcolm
2021-05-25  0:44       ` Martin Sebor
2021-05-24 23:08 ` [PATCH 0/11] warning control by group and location (PR 74765) David Malcolm
2021-05-25  0:42   ` Martin Sebor
2021-05-25  9:04     ` Richard Biener
2021-05-25 20:50       ` Martin Sebor
2021-05-27 11:19     ` Richard Sandiford
2021-05-27 16:41       ` Martin Sebor
2021-05-27 21:55         ` David Malcolm
2021-05-28  4:40           ` Jason Merrill
2021-06-04 21:27   ` [PATCH 0/13] v2 " Martin Sebor
2021-06-04 21:41     ` [PATCH 1/13] v2 [PATCH 1/13] Add support for per-location warning groups " Martin Sebor
2021-06-21 21:34       ` [PING][PATCH " Martin Sebor
2021-06-22 23:18       ` [PATCH " David Malcolm
2021-06-22 23:28         ` David Malcolm
2021-06-23 19:47           ` Martin Sebor
2021-06-24  5:26             ` Jeff Law [this message]
2021-06-25  1:34               ` Martin Sebor
2021-09-01 19:35             ` Thomas Schwinge
2021-09-02  0:14               ` Martin Sebor
2021-09-03 19:16                 ` Thomas Schwinge
2021-09-10  7:45                   ` [PING] Don't maintain a warning spec for 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION' [PR101574] (was: [PATCH 1/13] v2 [PATCH 1/13] Add support for per-location warning groups (PR 74765)) Thomas Schwinge
2021-09-13 14:00                     ` Jeff Law
2021-11-09 14:18                   ` Use 'location_hash' for 'gcc/diagnostic-spec.h:nowarn_map' " Thomas Schwinge
2021-11-15 15:01                     ` [ping] Use 'location_hash' for 'gcc/diagnostic-spec.h:nowarn_map' Thomas Schwinge
2021-11-15 16:43                       ` Martin Sebor
2021-11-09 10:28                 ` Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204] (was: [PATCH 1/13] v2 [PATCH 1/13] Add support for per-location warning groups (PR 74765)) Thomas Schwinge
2021-11-09 10:54                   ` Richard Biener
2021-11-09 12:25                     ` Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204, PR103157] Thomas Schwinge
2021-11-10  4:52                   ` Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204] Martin Sebor
2021-11-24 10:28                     ` 'gengtype' (was: Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204]) Thomas Schwinge
2021-06-04 21:41     ` [PATCH 2/13] v2 Use new per-location warning APIs in Ada Martin Sebor
2021-06-24  5:07       ` Jeff Law
2021-06-28 21:20         ` Martin Sebor
2021-06-04 21:41     ` [PATCH 3/13] v2 Use new per-location warning APIs in C front end Martin Sebor
2021-06-21 21:35       ` [PING][PATCH " Martin Sebor
2021-06-24  5:09       ` [PATCH " Jeff Law
2021-06-25  1:35         ` Martin Sebor
2021-06-04 21:42     ` [PATCH 4/13] v2 Use new per-location warning APIs in C family code Martin Sebor
2021-06-21 21:35       ` [PING][PATCH " Martin Sebor
2021-06-24  5:06       ` [PATCH " Jeff Law
2021-06-25  1:36         ` Martin Sebor
2021-06-04 21:42     ` [PATCH 5/13] v2 Use new per-location warning APIs in the RL78 back end Martin Sebor
2021-06-24  5:06       ` Jeff Law
2021-06-04 21:42     ` [PATCH 6/13] v2 Use new per-location warning APIs in the C++ front end Martin Sebor
2021-06-21 21:37       ` [PING][PATCH " Martin Sebor
2021-06-24  5:12       ` [PATCH " Jeff Law
2021-06-25  1:38         ` Martin Sebor
2021-06-04 21:42     ` [PATCH 7/13] v2 Use new per-location warning APIs in the FORTRAN " Martin Sebor
2021-06-21 21:42       ` [PING][PATCH " Martin Sebor
2021-06-24  5:05       ` [PATCH " Jeff Law
2021-06-28 21:21         ` Martin Sebor
2021-06-04 21:42     ` [PATCH 8/13] v2 Use new per-location warning APIs in libcc1 Martin Sebor
2021-06-24  5:04       ` Jeff Law
2021-06-28 21:22         ` Martin Sebor
2021-06-04 21:43     ` [PATCH 9/13] v2 Use new per-location warning APIs in LTO Martin Sebor
2021-06-21 21:54       ` [PING][PATCH " Martin Sebor
2021-06-24  9:32         ` Richard Biener
2021-06-24 15:27           ` Martin Sebor
2021-06-25  7:46             ` Richard Biener
2021-06-24  5:03       ` [PATCH " Jeff Law
2021-06-04 21:43     ` [PATCH 10/13] v2 Use new per-location warning APIs in the middle end Martin Sebor
2021-06-21 21:58       ` [PING][PATCH " Martin Sebor
2021-06-24  5:15       ` [PATCH " Jeff Law
2021-06-25  1:40         ` Martin Sebor
2021-06-04 21:43     ` [PATCH 11/13] v2 Use new per-location warning APIs in the Objective-C front end Martin Sebor
2021-06-24  5:02       ` Jeff Law
2021-06-28 21:22         ` Martin Sebor
2021-06-04 21:43     ` [PATCH 12/13] v2 Remove TREE_NO_WARNING and gimple*no_warning* APIs Martin Sebor
2021-06-24  5:01       ` Jeff Law
2021-06-04 21:43     ` [PATCH 13/13] v2 Add regression tests for PR 74765 and 74762 Martin Sebor
2021-06-24  4:56       ` Jeff Law
2021-06-28 21:23         ` Martin Sebor
2021-06-15  1:29     ` [PING][PATCH 0/13] v2 warning control by group and location (PR 74765) Martin Sebor
2021-07-17 20:36     ` [PATCH " Jan-Benedict Glaw
2021-07-19 15:08       ` Martin Sebor
2021-07-28 11:14         ` Andrew Burgess
2021-07-28 16:16           ` Martin Sebor
2021-07-29  8:26             ` Andrew Burgess
2021-07-29 14:41               ` Martin Sebor
2021-05-30  2:06 ` [PATCH 0/11] " Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfa0b276-a6be-309b-4948-6ad9b06f0f1f@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=msebor@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).