<div dir="auto">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?<div dir="auto"><br></div><div dir="auto">-Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 25, 2019, 8:08 AM Matt Asplund <<a href="mailto:mwasplund@gmail.com">mwasplund@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">-Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2019, 10:46 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank" rel="noreferrer">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Apr 19, 2019 at 10:23 AM Matt Asplund via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> 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.<br>
<br>
Does the proposed patch/design not address your use case here? (a<br>
warning that ignores all attributes in unknown namespaces) - your<br>
style checker and code generator could/should/would use custom<br>
namespaces for their attributes, unknown to Clang so those would be<br>
ignored with this new warning category & there would be no need to<br>
register custom attributes to the known set.<br>
<br>
- Dave<br>
<br>
><br>
> -Matt<br>
><br>
> On Thu, Apr 18, 2019, 8:10 AM Aaron Ballman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On Wed, Apr 17, 2019 at 12:55 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" rel="noreferrer noreferrer" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>> ><br>
>> > On Wed, Apr 17, 2019 at 12:45 PM Justin Bassett <<a href="mailto:jbassett271@gmail.com" rel="noreferrer noreferrer" target="_blank">jbassett271@gmail.com</a>> wrote:<br>
>> > >><br>
>> > >> We support around 300 attributes currently, and this is a<br>
>> > >> fraction of the total attributes supported by all vendors and our list<br>
>> > >> of supported attributes (as well as other compiler's similar lists)<br>
>> > >> change with every release. I haven't seen any evidence that a list of<br>
>> > >> specific attributes to not diagnose is useful in the face of the sheer<br>
>> > >> number of possible attributes.<br>
>> > ><br>
>> > ><br>
>> > > 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.<br>
>> ><br>
>> > I believe GCC currently supports even more attributes than Clang does,<br>
>> > so 100s is a pretty reasonable estimation. I'm very wary of<br>
>> > arbitrary-length lists of arbitrary identifiers in command line<br>
>> > arguments as it always tends to have weird issues. For instance, : is<br>
>> > a reserved character in some shells, so spelling something<br>
>> > -Wunknown-attributes=foo::bar would fail for some users and have to be<br>
>> > written as -Wunknown-attributes="foo::bar" instead. Command line<br>
>> > length limits are also a concern with arbitrary lists. Having an<br>
>> > option where the user doesn't have to spell out specific attributes<br>
>> > alleviates all of my concerns and I think the granularity will be<br>
>> > sufficiently useful.<br>
>> ><br>
>> > >> I would be comfortable having two separate "unknown attribute" warning<br>
>> > >> flags: -Wunknown-attributes and -Wunknown-attribute-namespaces (or<br>
>> > >> something) where the distinction is the former warns on any unknown<br>
>> > >> attribute regardless of namespace, and the latter only diagnoses<br>
>> > >> unknown attributes in namespaces for which Clang does not support any<br>
>> > >> attributes. This seems like it would have a useful level of<br>
>> > >> granularity while not requiring the user to maintain a separate list<br>
>> > >> of things in the build system. It also nicely sidesteps problems like<br>
>> > >> attributes with multiple spellings or target-specific attributes.<br>
>> > ><br>
>> > ><br>
>> > > 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.<br>
>> ><br>
>> > I'd like some time to think on this one a bit more, but it does seem<br>
>> > tenable to me -- I'm glad that it may work for your use case. I don't<br>
>> > think this would be too difficult to implement; we don't currently<br>
>> > have a list of supported attribute namespaces anywhere, but I think it<br>
>> > would be easy to generate one automatically, so there shouldn't be<br>
>> > much maintenance overhead to support something like<br>
>> > -Wunknown-attribute-namespaces.<br>
>><br>
>> FYI: I put together a patch to explore this in <a href="https://reviews.llvm.org/D60872" rel="noreferrer noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D60872</a><br>
>><br>
>> ~Aaron<br>
>><br>
>> ><br>
>> > ~Aaron<br>
>> ><br>
>> > ><br>
>> > > Regards,<br>
>> > > Justin<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div>