[PATCH] D71345: [clangd] Fall back to selecting token-before-cursor if token-after-cursor fails.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D71345#1782647 <https://reviews.llvm.org/D71345#1782647>, @nridge wrote:

> Here, both navigations target the overloaded operator, but if you comment out the overloaded operator, they target the respective local variable declarations. I think this is pretty good do-what-I-mean behaviour, arguably better than a categorical preference for the right side over the left side.


That's reasonable in eclipse (though personally I'd find it frustrating to have no way to target `b` in `a+b+c`).
It seems broken for editors where the cursor is on a character rather than between characters, though.

> - For the purpose of determining "encloses", the cursor being at either boundary of a node counts as a match (so A and B are both considered to enclose the first cursor, and B and C are both considered to enclose the second cursor).
> - The algorithm for go-to-definition is: first look for an enclosing `ImplicitName` node; if one is found, go to its target. Otherwise, look for an enclosing `Name` node and go to its target.
> 
>   Other features use the same API, but perhaps with a different node type; for example, the "define out of line" refactoring looks for an enclosing `FunctionDeclarator` node.
> 
>   Perhaps we could have a simpler `SelectionTree` API along these lines, where the type of desired node informs the selection at each call site?

Thanks for the details on CDT. This diverges quite a lot from what we currently have:

- we have abstractions at the preprocessor level (tokens) and at the semantic level (clang AST), but nothing modeling the concept of e.g. "name" that we would need here.
- our refactorings (tweak) relies on computing the selection by traversing the AST first and then querying it for each operation, which doesn't work if the query affects the traversal and the traversal is expensive

Syntax trees would address this by providing a tree with the relevant syntactic constructs that's cheap to traverse, and would certainly end up replacing SelectionTree altogether.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71345