Enhance RenameHandler to handle null capabilities gracefully and add tests for registration options

[mgreenegit]

PR Summary

This was discovered and recommended by Copilot while working on a separate effort. Human review and discretion requested.

Microsoft.PowerShell.EditorServices.Handlers.PrepareRenameHandler.GetRegistrationOptions
(line 23) and RenameHandler.GetRegistrationOptions (line 39)
dereferenced capability.PrepareSupport without null-checking
capability. The OmniSharp framework passes a null RenameCapability
to these methods when the client's initialize request doesn't
advertise anything under textDocument.rename, causing PSES to throw
NullReferenceException during initialize.

This blocks every minimal LSP client that doesn't speak rename — for
example a completion-only client, or any client that opts in only to
the capabilities it actually consumes.

Fix

Two parts, applied identically to both handlers:

1. Make the parameter nullable (RenameCapability?) so the signature
   matches the real OmniSharp runtime contract.
2. Use the null-conditional operator so a null capability is treated
   the same as "PrepareSupport not advertised".

Test

A single parameterized xUnit [Theory],
GetRegistrationOptionsReflectsPrepareSupport, in
test/PowerShellEditorServices.Test/Refactoring/RenameHandlerTests.cs
covers both handlers and both capability states.

Reviewer FAQ

Q: Is this a regression from a previous PSES version?

No — this code has been present since the rename handler shipped
in v4.6.0 (commit d2112c21, PR #2292). The bug is triggered by
client capability shapes that mainstream clients (vscode-powershell,
Pester, Neovim's bundled config) happen to all populate, so it has
gone unnoticed.

Q: Doesn't annotating the override RenameCapability? break the
interface contract / emit CS8767?

No. The OmniSharp interfaces (IRenameHandler /
IPrepareRenameHandler) declare the parameter as non-nullable
RenameCapability. Implementing an interface method with a more
permissive (nullable) parameter is contravariantly safe — the
override accepts a superset of inputs — and the C# compiler allows it
without warning. CS8767 fires only in the opposite direction
(declaring non-nullable where the interface says nullable). Verified:
the project builds with 0 warnings / 0 errors. The annotation now
documents the real OmniSharp runtime contract under nullable analysis,
which is preferable to an [AllowNull] attribute or a warning
suppression.

Q: Assert.Equal(false, opts.PrepareProvider) for the unsupported
case — could PrepareProvider be a nullable bool? left as null?

No. RenameRegistrationOptions.PrepareProvider is a non-nullable
System.Boolean (confirmed by reflection on
OmniSharp.Extensions.LanguageProtocol.dll), so new() defaults it to
false. Asserting strict equality against false is correct and is a
stronger check than == true, which would not distinguish false from
a hypothetical null.

Q: Is there a corresponding upstream OmniSharp issue?

The OmniSharp.Extensions framework's contract is that
GetRegistrationOptions may receive a null capability. PSES (and
other consumers) need to honor that contract. Not an OmniSharp bug.

---

Filed by — see commit history. Co-authored-by Copilot.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR hardens rename/prepare-rename LSP registration against clients that omit textDocument.rename capabilities, preventing null dereferences during server initialization, and adds tests to validate the registration behavior.

Changes:

• Make GetRegistrationOptions null-safe when RenameCapability is omitted by the client.
• Add unit tests covering rename vs prepare-rename handlers’ registration options based on PrepareSupport.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
test/PowerShellEditorServices.Test/Refactoring/RenameHandlerTests.cs	Adds theory-driven coverage for registration options when RenameCapability is null or present.
src/PowerShellEditorServices/Services/TextDocument/Handlers/RenameHandler.cs	Handles null RenameCapability safely via null-conditional checks to avoid initialization crashes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.