[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