On 10/10/18, Martin Sebor <mse...@gmail.com> wrote: > While writing tests for fixes and enhancements for attribute > handling I keep finding myself coming up with the same boiler- > plate code to verify whether an attribute has or has not been > successfully applied. It's often error-prone because it > depends on the subtle and unique effects each attribute has > on optimizers or code generation in general. > > Implementing an API just for testing might perhaps be excessive > but I suspect that users would find use for such a feature too. > I can even envision wanting to selectively apply attributes to > one's own symbols depending on their presence or absence on > other symbols (as an extension to the patch I posted for pr81824 > that introduces the copy attribute to copy attributes from one > symbol to another). > > 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.
__builtin_has_attribute sounds confusingly close to the __has_attribute macro, and yet from this description it sounds like it does something different. Maybe clear that up? > > The C++ implementation is only tested using the C tests and > I'm pretty sure it doesn't do the right thing for templates > but I think it can be extended to do that in a followup patch > or an update to this one. > > The C tests don't exhaustively exercise all attributes so it's > quite possible there are gaps/bugs where the built-in doesn't > return the right value due to missing special handling. > Attribute format validation is nearly non-existent. I view > these shortcomings as minor and they too can be plugged in > a followup patch. > > Ultimately, if this is viewed as useful as I'm hoping it will > be, I'd like to move the special handling from has_attribute > and to a callback function pointed from attribute_spec. That > way each attribute, front-end and back-end alike, could, in > addition the attribute handler, implement its own special > query routine without the details leaking into the rest of > the compiler. > > Martin >
