[cfe-dev] Feature request: Don't warn for specified "unknown" attribute

[Aaron Ballman via cfe-dev]

On Wed, Apr 17, 2019 at 12:45 PM Justin Bassett <jbassett271 at gmail.com> wrote:
>>
>> We support around 300 attributes currently, and this is a
>> fraction of the total attributes supported by all vendors and our list
>> of supported attributes (as well as other compiler's similar lists)
>> change with every release. I haven't seen any evidence that a list of
>> specific attributes to not diagnose is useful in the face of the sheer
>> number of possible attributes.
>
>
> I severely underestimated the amount of attributes which may need to be listed through whitelisting. The 300 clang-supported attributes wouldn't need to be whitelisted since they are already known, but it's certainly conceivable that some unknown third party attributes could reach 30s to 100s or above, which is no longer that reasonable to list individually.

I believe GCC currently supports even more attributes than Clang does,
so 100s is a pretty reasonable estimation. I'm very wary of
arbitrary-length lists of arbitrary identifiers in command line
arguments as it always tends to have weird issues. For instance, : is
a reserved character in some shells, so spelling something
-Wunknown-attributes=foo::bar would fail for some users and have to be
written as -Wunknown-attributes="foo::bar" instead. Command line
length limits are also a concern with arbitrary lists. Having an
option where the user doesn't have to spell out specific attributes
alleviates all of my concerns and I think the granularity will be
sufficiently useful.

>> I would be comfortable having two separate "unknown attribute" warning
>> flags: -Wunknown-attributes and -Wunknown-attribute-namespaces (or
>> something) where the distinction is the former warns on any unknown
>> attribute regardless of namespace, and the latter only diagnoses
>> unknown attributes in namespaces for which Clang does not support any
>> attributes. This seems like it would have a useful level of
>> granularity while not requiring the user to maintain a separate list
>> of things in the build system. It also nicely sidesteps problems like
>> attributes with multiple spellings or target-specific attributes.
>
>
> I agree with this option. I already thought was reasonable, but now that I realize how many attributes there are, it seems to be one of the better options.

I'd like some time to think on this one a bit more, but it does seem
tenable to me -- I'm glad that it may work for your use case. I don't
think this would be too difficult to implement; we don't currently
have a list of supported attribute namespaces anywhere, but I think it
would be easy to generate one automatically, so there shouldn't be
much maintenance overhead to support something like
-Wunknown-attribute-namespaces.

~Aaron

>
> Regards,
> Justin