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

[Matt Asplund via cfe-dev]

Sorry I was missing half the conversation. Yes, I think adding ignore
unknown namespace or register a known namespace works great for bigger
projects that have many attributes. But I could see small one off solutions
that create just one or two new attributes that should be able to have
unqualified attributes if they want.  Why not add both namespace level and
individual attribute register flags?

-Matt

On Thu, Apr 25, 2019, 8:08 AM Matt Asplund <mwasplund at gmail.com> wrote:

> Why does an analysis tool have to use a custom namespace? Is it a
> requirement of the spec that the compiler only gets to use attributes in
> the root? I am not opposed to doing this, but that seems arbitrary to me.
>
> -Matt
>
> On Fri, Apr 19, 2019, 10:46 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>> On Fri, Apr 19, 2019 at 10:23 AM Matt Asplund via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> >
>> > I agree, I am playing around with using attributes to annotate my code
>> for style checking and code gen for a test framework and have had to turn
>> off attributes warnings entirely. It would be nice to be able to register
>> custom attributes to the know set so clang can ignore them.
>>
>> Does the proposed patch/design not address your use case here? (a
>> warning that ignores all attributes in unknown namespaces) - your
>> style checker and code generator could/should/would use custom
>> namespaces for their attributes, unknown to Clang so those would be
>> ignored with this new warning category & there would be no need to
>> register custom attributes to the known set.
>>
>> - Dave
>>
>> >
>> > -Matt
>> >
>> > On Thu, Apr 18, 2019, 8:10 AM Aaron Ballman via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>> >>
>> >> On Wed, Apr 17, 2019 at 12:55 PM Aaron Ballman <aaron at aaronballman.com>
>> wrote:
>> >> >
>> >> > 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.
>> >>
>> >> FYI: I put together a patch to explore this in
>> https://reviews.llvm.org/D60872
>> >>
>> >> ~Aaron
>> >>
>> >> >
>> >> > ~Aaron
>> >> >
>> >> > >
>> >> > > Regards,
>> >> > > Justin
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at lists.llvm.org
>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190425/1c173e2e/attachment.html>