[PATCH] New syntax and functionality for __has_attribute

[dblaikie at gmail.com]

On Sat Jan 11 2014 at 10:57:22 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Sat, Jan 11, 2014 at 1:49 PM, dblaikie at gmail.com <dblaikie at gmail.com>
> wrote:
> > I'm not sure this is necessary - do any compilers (including different
> > versions of clang itself, which I believe is the main use of
> has_attribute)
> > support the same attribute but in differing syntaxes?
>
> Yes, clang has numerous attributes instances of this. I believe GCC
> does as well. For instance, it's quite common to have a GNU spelling
> and a C++11 syntax for the same attribute. There are also cases where
> attributes with the same spelling but different syntax provide
> differing semantics, such as the aligned attribute (which has five
> different syntaxes).
>

Sorry, I'm not trying to be obtuse, but I'm not sure if/how that answers my
question.

What I'm asking is, is there ever a case where a compile-time check is
required to decide which syntax to use? (where two compilers (including two
different versions of the same compiler) have support for the same
attribute but in disparate syntaxes?)

The existence of an attribute with more than one, or less than all syntaxes
is not an issue - if in every compiler that implements the attribute it is
implemented in the same set of syntaxes, then there's no need to query
which syntax is valid, is there? It would be a universal constant.


>
> > Otherwise it just
> > seems an invariant of the attribute and not something that would need
> > compile time tests for because it won't vary by compilation
>
> I strongly disagree. Consider the dllexport example I had given.
> Supporting that is currently guess-work with __has_attribute because
> we only respond back that the attribute is known, but not a particular
> syntax.


Wouldn't it be documented somewhere? Why would it need to be queried
dynamically (at compile-time)? That would only be necessary if the
attribute was supported with different syntaxes in different compilers. Is
that the case?


> Yet the syntax is specifically required in order to use it
> properly.
>
> FWIW, this is also PR15853.
>

OK, the unparsability problem could be addressed separately, though. I
guess that's why GCC's attribute syntax has the double parens.

But I see from the bug Richard suggested this - I'm just trying to
understand it.


>
> ~Aaron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140111/c3af72fa/attachment.html>