fix use markup for diagnostics in lsp to codify backtics #1177

[asukaminato0721]

Summary

Fixes #1177

Added detection of markupMessageSupport from client capabilities and emit markdown-formatted diagnostic messages for both textDocument/publishDiagnostics and textDocument/diagnostic when supported.

Threaded the capability through initialization and server construction.

Test Plan

added an LSP interaction test covering markdown diagnostics.

[Copilot]

Pull request overview

Adds LSP 3.18-style markup support for diagnostic messages so clients can render diagnostic text as Markdown (e.g., backticks as code spans), and updates initialization plumbing to propagate this capability through both LSP and TSP entrypoints.

Changes:

• Introduce InitializeInfo to carry InitializeParams plus a supports_diagnostic_markdown flag derived from client capabilities.
• When supported, wrap Diagnostic.message strings into { kind: "markdown", value: ... } for both publishDiagnostics and textDocument/diagnostic responses.
• Add a regression test that opts into markup support and asserts Markdown-shaped diagnostic messages.

Reviewed changes

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

Show a summary per file

File	Description
pyrefly/lib/lsp/non_wasm/server.rs	Detect markup support at initialize time; conditionally rewrite diagnostic JSON to MarkupContent for push/pull diagnostics.
pyrefly/lib/test/lsp/lsp_interaction/diagnostic.rs	Add test verifying Markdown-shaped diagnostics when capability is enabled.
pyrefly/lib/commands/lsp.rs	Thread InitializeInfo through LSP startup instead of bare InitializeParams.
pyrefly/lib/commands/tsp.rs	Thread InitializeInfo through TSP startup and into Server::new.
pyrefly/lib/tsp/server.rs	Update tsp_loop signature to accept the new initialization wrapper.

---

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

[Copilot]

This test hard-codes the request id RequestId::from(1) for the server’s workspace/configuration request and uses expect_any_message() instead of asserting the request type/id. This is brittle if the server sends any other request first (or changes its outgoing request id sequence). Prefer expect_configuration_request(...) / expect_request::<WorkspaceConfiguration>(...) to capture the actual id and respond to the correct request.

Suggested change

	interaction
	.client
	.expect_any_message()
	.expect("Failed to receive configuration request");
	interaction.client.send_response::<WorkspaceConfiguration>(
	RequestId::from(1),
	let request_id = interaction
	.client
	.expect_configuration_request()
	.expect("Failed to receive configuration request");
	interaction.client.send_response::<WorkspaceConfiguration>(
	request_id,

[meta-codesync]

@jvansch1 has imported this pull request. If you are a Meta employee, you can view this in D92713211.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[stroxler]

Review automatically exported from Phabricator review in Meta.

[meta-codesync]

@jvansch1 merged this pull request in 6742340.