Feature Request: better expression delimiting for extract variable

[Ryan1729]

Problem description

In Rust if I want to extract a sub-expression into a variable, then I need to wrap it in parens first.

In Java though, selecting a sub-expression works as expected.

Steps to reproduce

In the GIFs I'm pressing Ctrl-alt-v to activate the Extract Variable refactoring after selecting the subexpression.

[Kobzol]

@ortem I looked at it and it seems to be caused by the way the expression is parsed (due to associativity I presume).

1 * <selection>2 * 3</selection> is parsed as BinaryExpr(1*2, 3), so the selection hits "in the middle" and it fails.

1 + <selection>2 * 3</selection> is parsed as BinaryExpr(1, 2 * 3), so the selection finds an expression and the extraction works fine.

Maybe we could duplicate the expression, add fake parentheses, parse it again and then try to extract the expression again?

[Kobzol]

I looked at other languages and it depends on how the PSI is represented. Kotlin also uses BinaryExpr representation, so it has the same problem as the Rust plugin and it cannot extract 1 + <selection>2 * 3</selection>. In Java, a PsiPolyadicExpression is used, which represents an expression with N operands (where N can be more than two), therefore the extraction works, as you have demonstrated.

This seems like a fundamental consequence of the PSI design and it would be very difficult to change this in the Rust plugin. I tried to do some shenanigans like extracting the selection from the expression (1 + <selection>2 * 3</selection> -> 2*3), re-parsing it and creating a new RsExpr out of it and then replacing the original text range, i.e. do not work with it as PSI, but as text. But that seems pretty hacky. @Undin what do you think about this, is it solvable with the current design?