From: Jason Merrill <jason@redhat.com>
To: Marek Polacek <polacek@redhat.com>,
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Cc: Marek Polacek via Gcc-patches <gcc-patches@gcc.gnu.org>,
Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH v6] attribs: Implement -Wno-attributes=vendor::attr [PR101940]
Date: Tue, 9 Nov 2021 12:27:28 -0500 [thread overview]
Message-ID: <c6f49929-6e7c-5859-5286-5050df80cf74@redhat.com> (raw)
In-Reply-To: <YYqaAetLLKL0P76C@redhat.com>
On 11/9/21 10:55, Marek Polacek wrote:
> On Tue, Nov 09, 2021 at 08:09:10AM +0100, Bernhard Reutner-Fischer wrote:
>> On Tue, 9 Nov 2021 00:12:10 -0500
>> Jason Merrill <jason@redhat.com> wrote:
>>
>>> On 11/8/21 20:41, Marek Polacek wrote:
>>>> On Sat, Nov 06, 2021 at 03:29:57PM -0400, Jason Merrill wrote:
>>
>>>> + for (auto opt : v)
>>>> + {
>>>> + char *cln = strstr (opt, "::");
>>>> + /* We don't accept '::attr'. */
>>>> + if (cln == nullptr || cln == opt)
>>>> + {
>>>> + error ("wrong argument to ignored attributes");
>>>> + inform (input_location, "valid format is %<ns::attr%> or %<ns::%>");
>>>> + continue;
>>>> + }
>>>> + char *vendor_start = opt;
>>>> + ptrdiff_t vendor_len = cln - opt;
>>>> + char *attr_start = cln + 2;
>>>> + /* This could really use rawmemchr :(. */
>>>> + ptrdiff_t attr_len = strchr (attr_start, '\0') - attr_start;
>>>> + /* Verify that they look valid. */
>>>> + auto valid_p = [](const char *const s, ptrdiff_t len) {
>>>> + for (int i = 0; i < len; ++i)
>>>> + if (!ISALNUM (*s) && *s != '_')
>>>> + return false;
>>>> + return true;
>>>> + };
>>>> + if (!valid_p (vendor_start, vendor_len)
>>>> + || !valid_p (attr_start, attr_len))
>>>> + {
>>>> + error ("wrong argument to ignored attributes");
>>>> + continue;
>>>> + }
>>>> + /* Turn "__attr__" into "attr" so that we have a canonical form of
>>>> + attribute names. Likewise for vendor. */
>>>> + auto strip = [](char *&s, ptrdiff_t &l) {
>>>> + if (l > 4 && s[0] == '_' && s[1] == '_'
>>>> + && s[l - 1] == '_' && s[l - 2] == '_')
>>>> + {
>>>> + s += 2;
>>>> + l -= 4;
>>>> + }
>>>> + };
>>>> + strip (attr_start, attr_len);
>>>> + strip (vendor_start, vendor_len);
>>>> + /* We perform all this hijinks so that we don't have to copy OPT. */
>>>> + tree vendor_id = get_identifier_with_length (vendor_start, vendor_len);
>>>> + tree attr_id = get_identifier_with_length (attr_start, attr_len);
>>>> + /* If we've already seen this vendor::attr, ignore it. Attempting to
>>>> + register it twice would lead to a crash. */
>>>> + if (lookup_scoped_attribute_spec (vendor_id, attr_id))
>>>> + continue;
>>>
>>> Hmm, this looks like it isn't handling the case of previously ignoring
>>> vendor::; it seems we'll look for vendor::<empty string> instead, not
>>> find it, and register again.
> Yes, for -Wno-attributes=vendor::,vendor:: we call register_scoped_attributes
> twice, but I think that's OK: register_scoped_attributes will see that
> find_attribute_namespace finds the namespace and returns without creating a new
> one.
>
> I think the current code handles -Wno-attributes=vendor::a,vendor:: well so
> I'm not sure if I should change it.
Makes sense. But we should be able to avoid calling
lookup_scoped_attribute_spec, and even get_identifier_with_length
(attr...), if attr_len is 0.
>> I don't know if there are __attrib with 2 leading underscores but no
>> trailing that we accept and should normalize?
>>
>> And it is surprising that we do not have a simple normalize_attr_name().
>> There must be existing spots where we would normalize attribute names?
>> extract_attribute_substring does about the same but with a struct substring(?).
>> Maybe that's just to avoid a normal string hash.
>
> We have canonicalize_attr_name which I based my code on.
We could factor out of that function an overload equivalent to your
strip lambda?
Jason
next prev parent reply other threads:[~2021-11-09 17:27 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 17:06 [PATCH] " Marek Polacek
2021-09-20 17:38 ` Jakub Jelinek
2021-09-20 18:37 ` Marek Polacek
2021-09-20 19:03 ` [PATCH v2] " Marek Polacek
2021-09-20 19:08 ` [PATCH] " Jakub Jelinek
2021-09-20 22:59 ` [PATCH v3] " Marek Polacek
2021-09-23 18:25 ` Jason Merrill
2021-09-28 20:20 ` [PATCH v4] " Marek Polacek
2021-10-11 15:17 ` Marek Polacek
2021-10-29 16:47 ` Marek Polacek
2021-11-05 18:48 ` Jason Merrill
2021-11-06 0:21 ` [PATCH v5] " Marek Polacek
2021-11-06 1:32 ` Bernhard Reutner-Fischer
2021-11-06 18:28 ` Marek Polacek
2021-11-06 19:29 ` Jason Merrill
2021-11-06 20:29 ` Bernhard Reutner-Fischer
2021-11-09 1:41 ` [PATCH v6] " Marek Polacek
2021-11-09 5:12 ` Jason Merrill
2021-11-09 7:09 ` Bernhard Reutner-Fischer
2021-11-09 15:55 ` Marek Polacek
2021-11-09 17:27 ` Jason Merrill [this message]
2021-11-09 19:17 ` [PATCH v7] " Marek Polacek
2021-11-09 19:47 ` Bernhard Reutner-Fischer
2021-11-09 19:57 ` Bernhard Reutner-Fischer
2021-11-09 20:23 ` Marek Polacek
2021-11-09 21:30 ` [PATCH v8] " Marek Polacek
2021-11-10 5:53 ` Jason Merrill
2021-11-09 15:51 ` [PATCH v6] " Marek Polacek
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=c6f49929-6e7c-5859-5286-5050df80cf74@redhat.com \
--to=jason@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=polacek@redhat.com \
--cc=rep.dot.nop@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).