[PATCH] D65139: [clangd] Support extraction of binary "subexpressions" like a + [[b + c]].

[Sam McCall via Phabricator via cfe-commits]

sammccall marked an inline comment as done.
sammccall added inline comments.


================
Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:305
+  const SelectionTree::Node *Start = Op.SelectedOperands.front(); // LHS
+  const SelectionTree::Node *End = Op.SelectedOperands.back();    // RHS
+  // End is already correct, Start needs to be pushed down to the right spot.
----------------
SureYeaah wrote:
> sammccall wrote:
> > SureYeaah wrote:
> > > For 1 + [[2 + 3 * 4]] + 5, we probably don't get an invalid range from this function. If so, we might want to add one more check where we parse End and compare it's operator.
> > > 
> > > 
> > I'm not quite sure what you mean here.
> > 
> > Annotating the operators, for `1 +a [[2 +b 3 *c 4]] +d 5`:
> >  - N is `*c`
> >  - RHS is `4`
> >  - LHS is `1 +a 2 +b 3 *c 4`.
> > 
> > The point is that RHS can never be an operator of the same type, because if we replaced RHS with `x +e y` then N would be that `+e` instead (since `+` is left-associative).
> > 
> But isn't the tree something like
> 
>                     +
>                  /    \ 
>                 +     5
>              /     \
>          +           *
>        /  \       /   \
>        1    2    3    4
Whoops, somehow I transcribed that without noticing c was a * instead of a +.

>From offline discussion: the code is apparently correct here: RHS can't be a matching operator, because it violates associativity: the parse tree would be rotated in that case. We don't care to distinguish between mismatching operator vs some other node entirely.
- Expanded a comment to cover this more explicitly
- adjusted a testcase to ensure that we expand a `+`-selection across a `*` on the RHS as well as the LHS.

There's also the idea that it would be nice to verify that we don't bail out of this function just because the selection covers some mismatched operator. The idea of a test that we keep digging right if left mismatches and vice versa is appealing, but as described we never need to to dig right, so such a case doesn't exist. I've settled for ensuring that 0 + 1 * [2 + 3] * 4 + 5 expands to cover 1 and 4, but not 0 or 5.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65139