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

[Matt Asplund via cfe-dev]

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/ba3163e2/attachment.html>