On 10/13/18, Martin Sebor <mse...@gmail.com> wrote: > Attached is an updated/enhanced patch with many more tests > and the suggested documentation tweak. It also restores > the handling of empty attributes that the first revision > inadvertently removed from the C parser. > > The tests are much more comprehensive now but still not > exhaustive. I have added warning for the mode attribute > that cannot be supported. Enumerator attributes aren't > detected in C because they are folded to constants before > they reach the built-in, and label attributes aren't handled > yet either in C or in C++. Supporting those will take a minor > enhancement. I haven only added handful of test cases for > x86_64 target attributes, The built-in is not exercised > for any other target yet. I don't expect any surprises > there. Either it will work or (where the attributes aren't > hanging off a node) it will return false. Supporting those > will have to wait until the later (I think the best way is > to add a callback to struct attribute_spec to let each back > end query a node for the properties unique to such attributes > analogously to attribute vector_size). > > I haven't done any work on supporting templates. I would > like to but I don't expect to be able to get it done before > stage 1 is over (I have another feature I need to finish, > the one that prompted this work to begin with). I think > the new built-in is quite useful even without template > support. > > I've kept the name __builtin_has_attribute: it is close to > the __has_attribute macro, and I think that's fine because > the built-in's purpose is very close to that of the macro.
If you're going to keep the name, could you at least explain the difference between the two in the documentation? > > Martin > > On 10/11/2018 08:54 AM, Martin Sebor wrote: >> On 10/11/2018 06:04 AM, Joseph Myers wrote: >>> On Thu, 11 Oct 2018, Martin Sebor wrote: >>> >>>> The attached patch introduces a built-in function called >>>> __builtin_has_attribute that makes some of this possible. >>>> See the documentation and tests for details. >>> >>> I see nothing in the documentation about handling of equivalent forms of >>> an attribute - for example, specifying __aligned__ in the attribute but >>> aligned in __builtin_has_attribute, or vice versa. I'd expect that to >>> be >>> documented to work (both of those should return true), with associated >>> tests. (And likewise the semantics should allow for a format attribute >>> using printf in one place and __printf__ in the other, for example, or >>> the >>> same constant argument represented with different expressions.) >> >> Yes, it occurred to me belatedly that I should add a test for those >> as well. I can also mention it in the documentation, although I'd >> have thought it would be implicit in how attributes work in general. >> (Or are there some differences between the underscored forms and >> the one without it)? >> >>> >>> What are the semantics of __builtin_has_attribute for attributes that >>> can't be tested for? (E.g. the mode attribute, which ends up >>> resulting in >>> some existing type with the required mode being used, so there's nothing >>> to indicate the attribute was originally used to declare things.) >> >> With a few exceptions (like aligned) the built-in returns false >> for attributes that aren't attached to a node. I haven't exercised >> nearly all the attributes yet, and this one could very well be among >> those that aren't and perhaps can't be handled. I suspect some >> target attributes might be in the same group. If there's no way >> to tell it should probably be documented as a limitation of >> the function, maybe also under the attribute itself that can't >> be detected. Alternatively, the built-in return type could be >> changed to a tri-state: "don't know," false, true. Can you >> think of a better solution? >> >> Martin > >
