Added highlighting for variable references using VisitDeclRefExpr.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 34380 Build 34379: arc lint + arc unit
Event Timeline
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
48 | The DeclRefExpr is a very general expression, which can reference a variable, a function, an enum, etc. I think we want to distinguish with them (rather than putting all into Variable type). And we are missing large majority of entities now, I think we could start collecting more entities (class, method, enum, etc). |
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
48 | IMO the way to ensure consistency is to make the highlight a function of the decl, regardless of whether you found it in the decl itself, a declrefexpr, etc. so something like: // (overloaded) addToken(SourceLocation Loc, NamedDecl *D) { if (isa<VarDecl>(D)) return addToken(Loc, HighlightingKind::Variable); // ... etc } bool VisitDeclRefExpr(DeclRefExpr *Ref) { // bail out for operators here (if it's only *usages* you don't want to highlight) addToken(Ref->getLocation(), Ref->getDecl()); } bool VisitNamedDecl(NamedDecl *ND) { addToken(ND->getLocation(), ND); } |
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
38 | I think you might want to bail out (both here and in VisitDeclRefExpr) if the name kind isn't identifier. Reason is you're only coloring the token at location, and most of the other name kinds can span multiple tokens or otherwise need special consideration. | |
61 | note that methods, constructors, and destructors inherit from functiondecl, so if you want to exclude/distinguish those, order matters here |
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
38 | I must have missed the Identifier NameKind because I was first-hand looking for something like that. Are you aware of any testcase I could add for this by the way? | |
61 | I'm aware of that, but thanks for the heads up. Although should I add it in a comment somewhere in the method? Also added an additional testcase for classes and FIXMEs to the skip if statement in VisitNamedDecl. |
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
38 | Such a testcase would ensure you're not coloring any part of struct F { ~F(); } as a method, or operator << etc. | |
61 | I don't think it needs a comment, especially if you're not actually highlighting them (because they have weird DeclarationNames)
I'm not actually sure there's anything to fix here - it's a bit hard to talk about constructor/destructor highlighting as distinct from type name highlighting in C++. If you want them highlighted as classes, then that should just start working when you start handling TypeLocs. |
the implementation looks good, a few comments on the test.
clang-tools-extra/clangd/SemanticHighlighting.cpp | ||
---|---|---|
61 | I think constructor/destructor can be categorized in the function group, like entity.name.function.constructor, entity.name.function.destructor | |
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp | ||
77 | nit: even for the test code, could we make the code style consistent (like follow the LLVM code style) here? | |
84 | now we have 4 test cases, the purpose of each testcase is unclear to me (some of them are testing duplicated things), could we narrow the testcase so the each testcase just test one particular thing (e.g. one test for Variable and its references; one test for Function and its references;)? I think the testcase here is to verify we don't highlighting the constructor/destructor, and operator, just R"cpp( struct Foo { Foo(); ~Foo(); void $Function[[foo]](); } )cpp" |
thanks, looks good.
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp | ||
---|---|---|
70 | nit: I'd add 2-space to the code, like: R"cpp( struct AS {} ... )cpp, |
I think you might want to bail out (both here and in VisitDeclRefExpr) if the name kind isn't identifier.
Reason is you're only coloring the token at location, and most of the other name kinds can span multiple tokens or otherwise need special consideration.