[PATCH] D31343: Add an attribute plugin example

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Mar 20 11:23:27 PDT 2020


aaron.ballman added inline comments.


================
Comment at: clang/examples/Attribute/Attribute.cpp:35
+    Spellings.push_back({ParsedAttr::AS_GNU, "example"});
+    Spellings.push_back({ParsedAttr::AS_CXX11, "::example"});
+    Spellings.push_back({ParsedAttr::AS_CXX11, "plugin::example"});
----------------
john.brawn wrote:
> aaron.ballman wrote:
> > This is not a valid spelling for an attribute (we should probably assert that an attribute-scoped-token does not have an empty scope).
> "::example" is actually how an unscoped spelling is specified - normalizeName in Basic/Attributes.cpp adds a "::" to the start if there's no scope, and the tablegen-generated getAttrKind expects it as well.
It's not how an unscoped spelling is specified by either C or C++ -- in both languages, that would be an error. I don't think we want to leak this implementation detail out to the user as it will be confusing to them.


================
Comment at: clang/examples/Attribute/Attribute.cpp:42
+    // This attribute appertains to functions only.
+    if (!D || !isa<FunctionDecl>(D)) {
+      S.Diag(Attr.getLoc(), diag::warn_attribute_wrong_decl_type_str)
----------------
john.brawn wrote:
> aaron.ballman wrote:
> > I don't think `D` can ever be null, can it?
> I don't know, but this is how the auto-generated diagAppertainsToDecl functions do it.
I'll fix that up -- I just verified that `D` can never be null. `Sema::ProcessDeclAttributeList` dereferences `D` unconditionally and has for a long time.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D31343/new/

https://reviews.llvm.org/D31343





More information about the cfe-commits mailing list