[PATCH] D89785: [clangd] Add basic support for attributes (selection, hover)

Haojian Wu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Oct 23 01:04:43 PDT 2020


hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.


================
Comment at: clang-tools-extra/clangd/unittests/ASTTests.cpp:233
+  };
+  ASSERT_THAT(DeclAttrs("X"), Each(implicitAttr()));
+  ASSERT_THAT(DeclAttrs("Y"), Contains(attrKind(attr::WarnUnusedResult)));
----------------
sammccall wrote:
> hokein wrote:
> > sorry, I'm not familiar with attributes, what is an implicit attr? It is unclear to me why there is an attr for `class X`, the source code doesn't have any attribute label for X (the same question for f and a)
> Right, implicit attributes are when there's nothing written in the source ,but something else modifies the semantics in a way that clang authors decided to model as an attribute (e.g. because semantics match that of an explicit attribute).
> 
> I'm not familiar with many examples either, but a couple:
> - when targeting windows, top-level classes appear to have an implicit "type visibility" attribute that I guess models the difference between default unix/windows symbol visibility.
> - Aaron Ballman gave an example of `[[interrupt(...)]]` which also adds an implicit `[[used]]` attribute.
> 
> The windows example was why I assert there are no explicit attributes, instead of that there are none at all. I've added a comment.
ah, thanks for the explanation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89785



More information about the cfe-commits mailing list