This will fix some bugs where navigation doesn't work on cases like
std::cout <^< "hello".
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 38806 Build 38805: arc lint + arc unit
Event Timeline
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
279 | the function name doesn't match what it does now, considering a new name for it, getBeginningOfIdentifierOrOverloadedOperator seems too verbose, maybe just getBeginning? |
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
320–339 | If we use IgnoreWhitespace = false, I think we can simplify to: // Location in the middle of some token. if (BeforeLoc == CurrentLoc) return CurrentLoc; // Whitespace is not interesting. if (CurrentTok.Kind == tok::whitespace) return BeforeTok; if (BeforeTok.Kind == tok::whitespace) return CurrentTok; // The cursor is at token boundary, i.e. `Before^Current`. // Prefer identifiers to other tokens. if (CurrentTok.Kind == tok::raw_identifier) return CurrentLoc; if (BeforeTok.Kind == tok::raw_identifier) return BeforeLoc; // And overloaded operators to other tokens. if (isOperator(CurrentTok.Kind)) return CurrentLoc; if (isOperator(BeforeTok.Kind)) return BeforeLoc; return CurrentLoc; That would have the same semantics, but is arguably simpler. WDYT? |
Upload correct diff.
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
320–339 | Good point, that would simplify the logic. |
Mostly NITs, except the naming of the new TokenKind enum.
I think it's better to pick something that's not clashing with clang::tok::TokenKind, even if the enum is in a different namespace.
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
242 | TokenKind has the same name as tok::TokenKind. Could we use a different name here to avoid possible confusions? | |
258 | NIT: add static for consistency with the rest of the function. | |
261 | NIT: can this just be tok::NUM_TOKENS? same for other kinds in the same function | |
311 | NIT: Could you please duplicate what case 2 is to avoid the need to go back to the comment at the top. | |
326 | could be at the token boundary should be is at the token boundary, right? |
address comments.
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
242 | renamed to TokenFlavor. | |
258 | I think the static is redundant here, as the function is in the anonymous namespace, I removed the static on the function above. | |
326 | yes, you are right. I was thinking of the single token case int ^foo;, which should be counted into the boundary case as we consider whitespace as a token kind. |
clang-tools-extra/clangd/SourceCode.cpp | ||
---|---|---|
279 | getBeginning sounds too generic too me, would definitely avoid that. I think getBeginningOfIdentifier creates less confusion, albeit it definitely creates some. No better alternative comes to mind, though. Maybe keep as is and update the comment to mention it also handles tokens for operators? |
clang-tools-extra/clangd/unittests/SourceCodeTests.cpp | ||
---|---|---|
330 | no, but we have a similar test ++/**/^abc, added it. |
TokenKind has the same name as tok::TokenKind. Could we use a different name here to avoid possible confusions?
E.g. TokenGroup or TokenFlavor.