Get declaration diagnostics in LSP

[jakebailey]

The server also has to ask for these if enabled.

Arguably, these should just get moved into semantic diagnostics, but...

(Maybe this is too buggy/slow to expose in the editor at the moment?

[Copilot]

Pull Request Overview

This PR refactors how diagnostics are aggregated in the LSP endpoint and adds support for declaration diagnostics when emitDeclarations is enabled.

• Consolidates syntactic, semantic, suggestion, and optional declaration diagnostics into a unified helper.
• Introduces toLSPDiagnostics to flatten multiple diagnostic slices.
• Adds a conditional branch to include declaration diagnostics based on server options.

Comments suppressed due to low confidence (1)

internal/ls/diagnostics.go:22

• New behavior for declaration diagnostics is gated by emitDeclarations. Consider adding or updating tests to cover both enabled and disabled states to ensure correct inclusion/exclusion.

if program.Options().GetEmitDeclarations() {

[weswigham]

Arguably, these should just get moved into semantic diagnostics, but...

Eh, they're calculated in a separate pass (basically by doing the emit), so having them separate can be nice for callers that don't really care about them (or are already doing emit and can just pull the diagnostics from the emit step). There's no error category distinction in the editor really, though, you're right.

[jakebailey]

Do we think declaration diagnostics are stable enough to merge this, or should we wait until more of the module / module specifier code is in?

[andrewbranch]

#1051 pretty much finishes it out

[weswigham]

AFAIK, program no longer has a diagnostic caching layer itself, so GetDeclarationDiagnostics will actually fully recalculate them on every call. Not sure if that needs to be cached somewhere or not.

[jakebailey]

That's true but I think all callers all call once so it might be okay for now. I'll look into doing caching after

[jakebailey]

Sent: #1058