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

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D71345#1781141 <https://reviews.llvm.org/D71345#1781141>, @sammccall wrote:

> How do you feel about the approach here?


I agree that having more of the logic centralized (in `SelectionTree`) is preferable to having it directly in a call site like `getDeclAtPosition`.

I also agree that this makes the `SelectionTree` API a bit clunky.

I tested the behaviour in Eclipse CDT, on the following testcase:

  struct Material {
      friend Material operator+(Material, Material);
  };
  
  void foo() {
      Material hydrogen, oxygen;
      hydrogen^+^oxygen;
  }

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.

I can describe how CDT achieves this:

- There is an API that takes a textual selection, and an AST node type, and finds the innermost node of that type that encloses the selection.
- The AST nodes built for the statement are as follows:

  hydrogen+oxygen;
  AAAAAAAABCCCCCC;   // A and C have type Name, B has type ImplicitName



- (If the overloaded operator is commented out, there is no node B.)
- 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 will use the same API, but perhaps with a different node type; for example, the "define out of line" refactoring will look 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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71345