Add a refactoring between fun x -> x.Prop and _.Prop

[xperiandri]

Fixes #16234

Offers Ctrl+. to turn a lambda that only reads a member chain of its parameter (fun x -> x.Name, fun x -> x.M(y), fun x -> x.Items[0]) into the _. shorthand, and a shorthand back into a fun lambda. It is a refactoring rather than a code fix because both forms are correct.

Not offered for lambdas with several or annotated parameters, bodies that do more than read the chain, lambdas applied directly, or inside quotations.

🤖 Generated with Claude Code

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`vsintegration/src`	docs/release-notes/.VisualStudio/18.vNext.md

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Modifies Visual Studio code executed while projects are open.

Generated by PR Tooling Safety Check · gpt56 1.8M · ◷

[T-Gro]

Is there no way to expose this logic from F.C.Service as an API ? (and reuse/parametrize/abstract with existing logic there is inside)

This duplication has potential to drift if compiler's logic changes.

[T-Gro]

Extract, e.g. to a well named AP where the AP will explain what this attempts to check.

[T-Gro]

Maybe in general, could you run e.g. 2-3 rounds of the "code compaction" skill from this repo which will check any shared patterns between added code and code which already exists in the compiler (like various Ops, helpers or other pieces of logic) - the skill covers some common patterns of logic reuse.

[xperiandri]

Covered cases

Converts

• A lambda passed as an argument loses its parentheses: xs |> List.map (fun x -> x.Prop) → xs |> List.map _.Prop, List.map (fun x -> x.A.B) xs → List.map _.A.B xs
• Member chains on the parameter: method call Seq.filter (fun x -> x.M(y)) → Seq.filter _.M(y), indexers x.Xs[0] and x.Xs.[0], generic method x.M<int>(), member of a call result x.M().P
• Spaces inside the parentheses ( fun x -> x.P ) and a backticked parameter fun ``x`` -> ``x``.P both → _.P
• A method argument keeps the call's parentheses: x.M(fun y -> y.P) → x.M(_.P); a bare fun x -> x.P → _.P; a lone (fun x -> x.P) → (_.P)
• Multi-line lambdas: List.map (fun x -> with x.Prop) xs on the next line → List.map _.Prop xs; a binding body fun x -> with x.P on its own line → _.P
• Shorthand to lambda: _.P → fun x -> x.P, _.A.B → fun x -> x.A.B, _.Xs[0] → fun x -> x.Xs[0]
• Shorthand as an argument gets parentheses: List.map _.P xs → List.map (fun x -> x.P) xs; inside method parentheses they are not added: x.M(_.P) → x.M(fun x -> x.P)
• The parameter name avoids names used in the body: xs |> List.map _.M(x) → xs |> List.map (fun x1 -> x1.M(x))
• Nested shorthands convert one at a time: caret on the outer one of _.M(_.P) → fun x -> x.M(_.P), on the inner one → _.M(fun x -> x.P)
• Round trip: List.map (fun x -> x.P) xs converted to shorthand and back gives the original text

Not offered

• Several parameters or a non-plain parameter pattern: fun x y -> x.P, fun (x: T) -> x.P, fun (x) -> x.P
• The body is more than a member chain: fun x -> (x.P), fun x -> f x.P, fun x -> x.M y, fun x -> x.P + 1
• The parameter is used more than once: fun x -> x.M(x), fun x -> x.M(fun x -> x)
• The chain doesn't start at the parameter, or there is no member access: fun x -> y.P, fun x -> x, fun x -> x[0], fun _ -> 1
• A lambda applied directly: (fun x -> x.P) y
• A lambda inside a quotation: <@ fun x -> x.P @>
• Caret on neither a lambda nor a shorthand: 1 + 2