feat: server-side support for incremental diagnostics

[mhuisi]

This PR adds server-side support for incremental diagnostics via a new isIncremental field on PublishDiagnosticsParams that is only used by the language server when clients set incrementalDiagnosticSupport in LeanClientCapabilities.

Context

The goal of this new feature is to avoid quadratic reporting of diagnostics.

LSP has two means of reporting diagnostics; pull diagnostics (where the client decides when to fetch the diagnostics of a project) and push diagnostics (where the server decides when to update the set of diagnostics of a file in the client).
Pull diagnostics have the inherent problem that clients need to heuristically decide when the set of diagnostics should be updated, and that diagnostics can only be incrementally reported per file, so the Lean language server has always stuck with push diagnostics instead.
In principle, push diagnostics were also intended to only be reported once for a full file, but all major language clients also support replacing the old set of diagnostics for a file when a new set of diagnostics is reported for the same version of the file, so we have always reported diagnostics incrementally while the file is being processed in this way.
However, this approach has a major limitation: all notifications must be a full set of diagnostics, which means that we have to report a quadratic amount of diagnostics while processing a file to the end.

Semantics

When LeanClientCapabilities.incrementalDiagnosticSupport is set, the language server will set PublishDiagnosticsParams.isIncremental when it is reporting a set of diagnostics that should simply be appended to the previously reported set of diagnostics instead of replacing it. Specifically, clients implementing this new feature should implement the following behaviour:

• If PublishDiagnosticsParams.isIncremental is false or the field is missing, the current diagnostic report for a specific document should replace the previous diagnostic report for that document instead of appending to it. This is identical to the current behavior before this PR.
• If PublishDiagnosticsParams.isIncremental is true, the current diagnostic report for a specific document should append to the previous diagnostic report for that document instead of replacing it.
• Versions should be ignored when deciding whether to replace or append to a previous set of diagnostics. The language server ensures that the isIncremental flag is set correctly.

Client-side implementation

A client-side implementation for the VS Code extension can be found at vscode-lean4#752.

[mathlib-lean-pr-testing]

Mathlib CI status (docs):

• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 7ef25b8fe3a9b845e976a65032b2edb458e62471 --onto fc0cf68539ad3b481a1802414c22c44506519c9d. You can force Mathlib CI using the force-mathlib-ci label. (2026-04-02 17:12:25)
• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 96d502bd11cc96bd92dcb6b73e1c4002526647ca --onto 0cd6dbaad297021c43b906ec247de446d056056f. You can force Mathlib CI using the force-mathlib-ci label. (2026-04-07 09:53:48)
• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 96d502bd11cc96bd92dcb6b73e1c4002526647ca --onto 4f6bcc5adac8d6234a9e3def3675402cb89823c6. You can force Mathlib CI using the force-mathlib-ci label. (2026-04-07 13:59:27)
• ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the nightly-with-mathlib branch. Try git rebase 96d502bd11cc96bd92dcb6b73e1c4002526647ca --onto d76e5a1886956bb38dc6bd2868260550dc66c309. You can force Mathlib CI using the force-mathlib-ci label. (2026-04-15 10:40:40)

[leanprover-bot]

Reference manual CI status:

• ❗ Reference manual CI will not be attempted unless your PR branches off the nightly-with-manual branch. Try git rebase 7ef25b8fe3a9b845e976a65032b2edb458e62471 --onto 861bc19e0c1c45b5766cc5c9ef0488568368b236. You can force reference manual CI using the force-manual-ci label. (2026-04-02 17:12:26)
• ❗ Reference manual CI will not be attempted unless your PR branches off the nightly-with-manual branch. Try git rebase 96d502bd11cc96bd92dcb6b73e1c4002526647ca --onto 861bc19e0c1c45b5766cc5c9ef0488568368b236. You can force reference manual CI using the force-manual-ci label. (2026-04-07 09:53:50)

[Vtec234]

Looks good; I didn't review the new code in Utils very carefully.

The Lean language server always sets PublishDiagnosticParams.isIncremental = false on the first diagnostic reported for a new version, but in principle, ..

I am confused by the 'in principle' statements in the semantics. Are we saying 'the Lean server does the right thing, but clients should do the in principle part in case the Lean server is buggy'? Could that be deleted, specifying the expected behavior without qualification instead?

[mhuisi]

Are we saying 'the Lean server does the right thing, but clients should do the in principle part in case the Lean server is buggy'? Could that be deleted, specifying the expected behavior without qualification instead?

We are saying "if you want to implement a correct client according to something that resembles a general specification for a general incremental diagnostic feature, you should implement these semantics, but the specific implementation of the Lean language server also fulfills a bunch of invariants". I'll just remove the note about the invariants that we fulfill; clients should ideally just implement the full spec.