This allows plugins to define an attribute and its associated ParsedAttrInfo, though the attribute won't be able to do anything. Also we end up removing AttrKinds.inc as searching through the registry replaces it.
Details
Diff Detail
Event Timeline
@john.brawn Are you still working on that? We would need this change at Mozilla to improve the way we use attributes.
Thanks
Resurrecting this old patch, with a bunch of changes due to the changes around AttributeCommonInfo. This is the second of four patches to make it possible for clang plugins to define attributes.
clang/include/clang/Sema/ParsedAttr.h | ||
---|---|---|
45 | Please add a full stop to the end of all the comments (here and elsewhere). | |
63 | spelt -> spelled | |
615 | I think this should return a const ParsedAttrInfo& so that callers don't try to mutate it. | |
clang/lib/Basic/Attributes.cpp | ||
101–103 | Range-based for loop? Also, it and ie don't meet the usual naming conventions. One thing I'm not keen on with this is the performance hit. We spent a decent amount of effort making this lookup fast and it's now a linear search through all of the attributes and requires memory allocations and deallocations to perform the search. | |
113 | This seems surprising because it makes it harder to determine whether you have a valid result from this function or not. I think this should return a null unique_ptr. | |
117 | Same concerns in this function as above. |
clang/lib/Basic/Attributes.cpp | ||
---|---|---|
101–103 | Yes, I've done some experiments and in the pathological case (lots of trivial functions with the xray_log_args attribute) the slowdown is noticeable. I've done some tinkering and I think the best way to resolve this is to first use a generated function (i.e. something like the current getAttrKind) to look up the attributes that are compiled into clang, then if that fails look in the registry to find a match. |
clang/lib/Basic/Attributes.cpp | ||
---|---|---|
101–103 | I think that approach makes sense and is something we should probably do up front. It doesn't seem like llvm::Registry has a way for us to mark where the plugin attributes start to allow for quickly searching for plugin attributes in the fallback case. I don't see a particularly good way around the memory allocations, however. Ideally, this could be something that's arena allocated on the ASTContext rather than using unique_ptr, but I think that would be tricky here because of library layering. After switching the lookup functionality, I'd be curious to know if there is a noticeable performance degredation still, or if that falls out into the noise. |
This has been rewritten so that the registry is only used for attributes added by plugins, and everything else continues as before. This also removes the strange dependency I'd previously introduced, where Attributes.cpp (in libclangBasic.so) declared and used the registry but ParsedAttr.cpp (in libclangSema.so) populated it - now the registry is declared and used solely within ParsedAttr.cpp.
I like this approach much better, thank you for working on it! LGTM
clang/include/clang/Basic/AttributeCommonInfo.h | ||
---|---|---|
140 ↗ | (On Diff #246763) | This should probably be getNormalizedFullName() -- the full by itself implies we don't normalize, to me. |
clang/include/clang/Sema/ParsedAttr.h | ||
66 | NormalizedFullName? |
Please add a full stop to the end of all the comments (here and elsewhere).