[PATCH] D71345: [clangd] Fall back to selecting token-before-cursor if token-after-cursor fails.
Nathan Ridge via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Dec 12 15:22:06 PST 2019
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
More information about the cfe-commits
mailing list