[psteinroe]

Stacked on #913, which changes the same parts of Document and WorkspaceServer.

Editors request code actions on every cursor move, and each request ran the whole analysis of the file: every lint and typecheck rule, over every statement. Right after an edit, the diagnostics had already run the same analysis. On a file with 25,000 statements that took seconds per cursor move.

What changed

• analyse_document returns a DocumentAnalysis struct instead of a tuple. The analysis that the editor asks for (every rule category, no only/skip rule selection) is kept on the Document, through analyse_document_cached. pull_file_diagnostics and the code actions use it, so after the diagnostics of an edit the code actions find it ready. Requests with a rule selection, such as check --only or fix_file (which analyses its own intermediate documents), are not cached.
• The cached analysis is dropped when the content changes (Document::update_content). It is not used when the settings changed, tracked by a version counter that is bumped while the settings are write-locked, or when the database snapshot changed (compared by Arc identity, which also covers a database that becomes reachable).
• The code actions go through the cached diagnostics by reference and only look at those under the cursor. LinterDiagnostic and its advices derive Clone, so that pull_file_diagnostics can convert diagnostics out of the shared analysis. RuleCategories derives PartialEq to recognise the "all categories" request.
• The LSP handler now honours context.only. Kinds are matched hierarchically, so quickfix includes quickfix.pgls.banDropTable, and source.fixAll doesn't get the quick fixes or the Execute Statement command. The filter runs on the final list, so actions added later (refactors, fix-all) go through it without changes here.

EXPLAIN and plpgsql_check diagnostics are not part of the cached analysis and are not affected.

Timings

Release build on a shared, loaded machine, measured with the probe from the release analysis. The "before" row is #892 alone, which stops code actions from walking the whole file to find the statement at the cursor; on main without it, that walk alone took about 0.9 s on the 20,000-line file.

	5,000 lines (6,250 statements)	20,000 lines (25,000 statements)
code actions before (best of 3)	777–955 ms	3,557–4,556 ms
diagnostics after an edit (unchanged)	1,782 ms	7,114 ms
first code action request after the diagnostics	5 ms	13 ms
further code action requests	< 0.1 ms	< 0.1 ms

Tests

• code_actions_reuse_the_analysis: the code actions use the analysis that the diagnostics cached (the same Arc), an edit drops it, and turning a rule off in the settings removes its actions.
• test_lint_fix_code_actions (LSP): with only: [quickfix] only the fix and the suppression come back, and with only: [source.fixAll] nothing does.
• requested_kinds_are_hierarchical: the kind matching, including "", a prefix that isn't a whole segment, and the empty kind of the commands.

Risks

• Memory: each open document keeps its last analysis, i.e. its diagnostics and per-statement facts, until the next edit or until it is closed.
• Anything else the analysis depends on has to bump the settings version or change the snapshot. Today that is the settings (every mutable access goes through workspaces_mut), the database snapshot and the document itself.
• Rebasing feat: code action to expand * into the column list #887: it touches pull_code_actions and the LSP get_actions mapping. This PR changes lint_code_actions' loop and adds a filter at the end of get_actions, so I expect no overlap beyond context lines. (perf(workspace): keep every statement of a document cached and walk once for hover #913 below renames references_at, which feat: code action to expand * into the column list #887 uses; that conflict is with perf(workspace): keep every statement of a document cached and walk once for hover #913, not this PR.)

Follow-ups: The memory of the cached analysis is bounded in #951.

[psteinroe]

This is too messy

[psteinroe]

Should be more encapsulated