[Repo Assist] fix: skip get/set accessor keywords and deduplicate ranges in TextDocumentRename

[github-actions]

🤖 This PR was created by Repo Assist, an automated AI assistant.

Closes #1269

Summary

When a property uses explicit getter/setter syntax:

member this.UnsafeValue
    with get () = someField
    and set v = someField <- v

FCS incorrectly returns the get and set accessor keywords as symbol uses of the property name. It may also return duplicate ranges for the property declaration itself. This caused two bugs:

1. The get and set keywords were incorrectly renamed alongside the property (the reported bug in get () should not be renamed when renaming a property #1269)
2. Overlapping edits when the same range appears twice in the rename list

Root Cause

SymbolUseWorkspace returns all FCS-identified usages of the symbol, but FCS treats get/set as part of the property's accessor chain and includes those keyword positions as rename targets. Additionally, duplicate ranges can be returned for the same position in some cases.

Fix

In TextDocumentRename in AdaptiveFSharpLspServer.fs, after retrieving the rename ranges from SymbolUseWorkspace:

1. Filter out ranges where the source text is "get" or "set" — these are always the accessor keyword, never a valid property name
2. Deduplicate ranges by start position to avoid overlapping edits

Both operations fall back gracefully if the file source can't be read (no filtering/dedup in the error case).

Test

Added regression test "renaming property with explicit get/set does not rename accessor keywords" in RenameTests.fs verifying that renaming a property with explicit with get () = ... / and set v = ... syntax does not rename the accessor keywords.

Trade-offs

• The filter is applied purely to the rename edits, not to the FCS data itself — so PrepareRename is unaffected
• Filtering "get"/"set" is safe because F# does not allow a property to legally be named get or set without backticks, and backtick-quoted \`get``would not match the literal string"get"`

Test Status

• ✅ Build: dotnet build src/FsAutoComplete/FsAutoComplete.fsproj -f net8.0 — 0 errors, 0 warnings
• ✅ Rename script tests: 18/18 passed (including new regression test) with both TransparentCompiler and BackgroundCompiler backends

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@595b7a9c567ba4dce05ca824aec6e74b4dc545b8. View source at https://github.com/githubnext/agentics/tree/595b7a9c567ba4dce05ca824aec6e74b4dc545b8/workflows/repo-assist.md.

[github-actions]

✅ Pull request created: #1453

[Krzysztof-Cieslak]

/pr-fix

[github-actions]

✅ Commit pushed: 0a6d493

[github-actions]

Fix: Fantomas formatting error

The CI "Check format" step was failing because dotnet fantomas --check build.fsx src detected a formatting issue in AdaptiveFSharpLspServer.fs.

Root cause: The let version = ... binding was split across two lines:

let version =
  fileContent |> Option.ofResult |> Option.map (fun f -> f.Version)

But per the .editorconfig setting fsharp_max_value_binding_width=80, Fantomas requires value bindings to stay on a single line when the entire binding is ≤80 characters. The binding let version = fileContent |> Option.ofResult |> Option.map (fun f -> f.Version) is 79 characters, so Fantomas expects it on one line.

Fix: Collapsed the binding to a single line:

let version = fileContent |> Option.ofResult |> Option.map (fun f -> f.Version)

The logic and functionality of the PR remain unchanged.

Generated by PR Fix for issue #1453

To install this workflow, run gh aw add githubnext/agentics/workflows/pr-fix.md@ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5. View source at https://github.com/githubnext/agentics/tree/ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5/workflows/pr-fix.md.

Warning

⚠️ Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• api.nuget.org
• dc.services.visualstudio.com