This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Added an early return from VisitMemberExpr in SemanticHighlighting if the MemberLoc is invalid.
ClosedPublic

Authored by jvikstrom on Aug 8 2019, 1:31 AM.

Details

Summary

Conversion operators contain invalid MemberLocs which causes SemanticHighlighting to emit a lot of error logs in large files as they can occur fairly often (for example converting StringRef to std string).
As the only thing happening was a lot of error logs being emited there doesn't really seem to be any way to test this (no erroneous tokens are added). But emiting as many logs as were being emited is not wanted.

Can't really be patched elsewhere. RecursiveASTVisitor should still traverse the expr as it can contain other "non-implicit" decls/exprs that must be visited (for example DeclRefs). A potential fix could be to special case the TraverseMemberExpr function to not Walk* the Expr if it has an invalid MemberLoc. But that would change the behaviour of RecursiveASTVisitor to be unexpected. (and to change the behaviour to be this for all exprs would change the contract of RecursiveASTVisitor to much)

Diff Detail

Repository
rL LLVM

Event Timeline

jvikstrom created this revision.Aug 8 2019, 1:31 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 8 2019, 1:31 AM
hokein added inline comments.Aug 8 2019, 2:21 AM
clang-tools-extra/clangd/SemanticHighlighting.cpp
56 ↗(On Diff #214083)

I think we only want to ignore the conversion operator, we could do an early return when MD is a cxx conversion decl, e.g. isa<CXXConversionDecl>(MD)?

jvikstrom updated this revision to Diff 214110.Aug 8 2019, 4:16 AM
jvikstrom marked an inline comment as done.

Changed to do an isa<CXXConversion> check instead of checking if MemberLoc is invalid.

hokein added inline comments.Aug 8 2019, 4:37 AM
clang-tools-extra/clangd/SemanticHighlighting.cpp
56 ↗(On Diff #214110)

Maybe just The MemberLoc is invalid for C++ conversion operato , we don't attempt to add a token for an invalid location?

Does the location is always invalid? or just for builtin types? e.g.

class Foo {};
struct Bar {
  explicit operator Foo*() const; // 1
  explicit operator int() const; // 2
};
jvikstrom updated this revision to Diff 214117.Aug 8 2019, 4:56 AM
jvikstrom marked an inline comment as done.

Added test for conversion operators. Also changed comment.

jvikstrom marked an inline comment as done.Aug 8 2019, 4:56 AM
jvikstrom added inline comments.
clang-tools-extra/clangd/SemanticHighlighting.cpp
56 ↗(On Diff #214110)

Builtin types has nothing to do with it. It's invalid for every conversion operator. Will actually add a test just to make sure that everything else is still highlighted correctly.

hokein accepted this revision.Aug 8 2019, 5:05 AM
hokein added inline comments.
clang-tools-extra/clangd/SemanticHighlighting.cpp
56 ↗(On Diff #214110)

ah, I thought it is the operator declaration, but here we mean expression.

clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
268 ↗(On Diff #214117)

nit: could you add a comment describing the purpose of this test?

This revision is now accepted and ready to land.Aug 8 2019, 5:05 AM
hokein added a comment.Aug 8 2019, 5:06 AM

please update the patch description.

This revision was automatically updated to reflect the committed changes.
jvikstrom marked 2 inline comments as done.
Herald added a project: Restricted Project. · View Herald TranscriptAug 8 2019, 5:43 AM