[cfe-dev] Feature request: Don't warn for specified "unknown" attribute
David Blaikie via cfe-dev
cfe-dev at lists.llvm.org
Fri Apr 19 10:46:38 PDT 2019
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.
> 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
>> > >
>> > > Regards,
>> > > Justin
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
More information about the cfe-dev