Return structured StatementRangeError from statement_range()

[DavisVaughan]

Branched from #1028
Goes with posit-dev/positron#11907

When there is a parse error in an R file and the user is trying to execute any code after that parse error, we now return a JsonRPC error with code = 1 and a structured data field, where data.line holds the approximate line number of the start of the parse error.

The frontend then picks this up by catching when await this._client.sendRequest(StatementRangeRequest.type, params, token) errors, checking that the caught error has error.code = 1, and then upcasting the error to a structured StatementRangeParseError on the TypeScript side.

The end result is that the frontend can now use this to refuse to execute any code, and instead give a pop up notification telling the user where the problem is.

Screen.Recording.2026-02-13.at.3.28.26.PM.mov

It even works in roxygen2! This required adjusting the "sub document" line to reflect a line in the original document.

Screen.Recording.2026-02-13.at.3.32.38.PM.mov

---

Note that we use an error code of 1.

I believe we are allowed to use any error code not captured by ErrorCodes here:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#responseMessage

I do not think the code number matters much outside of that. Each Request type can have its own set of error codes, and those error codes may overlap with other Request types.

---

I expect that we may have multiple failure modes in the future, so StatementRangeParseError is just the sole enum variant of an overarching StatementRangeError type. This is reflected on the TypeScript side as well.

---

There is very little prior art for returning structured errors from LSP Requests.

There are only two that I know of

• InitializeError

  • This uses an error code of 1, but it doesn't make it all the way into VS Code. It is handled in the middleware.
  • Defined here https://github.com/microsoft/vscode-languageserver-node/blob/51bb6ee4b47bd104d469e6bdeaafaee1ba6129a0/protocol/src/common/protocol.ts#L1605-L1617
  • Used here solely within the middleware https://github.com/microsoft/vscode-languageserver-node/blob/51bb6ee4b47bd104d469e6bdeaafaee1ba6129a0/client/src/common/client.ts#L1533

• Rejection, which is used by the RenameProvider

  • This does not use an error code. Instead it catches the error and expects that data.message is a string with a meaningful reason for rename rejection.
  • Defined here https://github.com/posit-dev/positron/blob/9754ca9e56524315fa6b2d1981fb6cb82ef5cd7b/src/vs/editor/common/languages.ts#L2127-L2138
  • Catching the error here https://github.com/posit-dev/positron/blob/9754ca9e56524315fa6b2d1981fb6cb82ef5cd7b/src/vs/workbench/api/common/extHostLanguageFeatures.ts#L882-L903

The interesting thing about Rejection is that once we have left LSP land on the Typescript side, the error path gets merged into the response path as a return value of RenameLocation & Rejection.

We work similarly, but our return value from all of the Typescript APIs is StatementRange | StatementRangeError, and the way that you know if you have a StatementRange or StatementRangeError is the presence of a result.error string field, which also serves as the discriminator for determining the more precise StatementRangeParseError subtype of StatementRangeError itself.