Sibling articles under this feature previously restated requirements in inconsistent forms.
Diagnostics parity (CLI and LSP) - FAQ and troubleshooting
Platform spec article
Diagnostics parity (CLI and LSP) - FAQ and troubleshooting
Spec standingStandard
-
This feature hub owns normative MUST/SHOULD contract text for Diagnostics parity (CLI and LSP).
Context
Decision
This feature hub owns normative MUST/SHOULD contract text. Sibling articles must not redefine hub requirements and should link here for authority.
Consequences
Contract changes start on the hub or in linked ADRs, then propagate to articles and implementation anchors.
Verification anchors
site/website/src/content/docs/platform-spec/compiler/build-pipeline/diagnostics-parity/index.mdxarticle bundle under the same feature directory.
-
Platform-spec text supersedes informal crate comments for Diagnostics parity (CLI and LSP).
Context
Implementation crates accumulated informal notes that diverged from published contracts.
Decision
Normative platform-spec prose and ADRs under this feature supersede informal comments in implementation crates until explicitly migrated into spec text.
Consequences
Engineers file spec/ADR updates when behavior changes; crate comments are non-authoritative for conformance arguments.
Verification anchors
compiler/crates/beskid_analysis/
-
This feature hub documents where diagnostics come from in CLI and LSP, and what differences are expected versus consider
Context
This feature hub documents where diagnostics come from in CLI and LSP, and what differences are expected versus considered regressions.
Decision
The reference compiler must implement Diagnostics parity (CLI and LSP) as documented in this feature hub and its article bundle.
Consequences
Changes require hub/ADR updates and verification anchor extensions.
Verification anchors
compiler/crates/beskid_analysis/
- Diagnostics parity (CLI and LSP) - Contracts and edge cases Required parity behavior and accepted differences between diagnostic surfaces.
- Diagnostics parity (CLI and LSP) - Design model Provenance model for parse and semantic diagnostics across compiler surfaces.
- Diagnostics parity (CLI and LSP) - Examples Practical examples comparing CLI and LSP diagnostics for equivalent failures.
- Diagnostics parity (CLI and LSP) - FAQ and troubleshooting Troubleshooting mismatched diagnostics between command-line and editor surfaces.
- Diagnostics parity (CLI and LSP) - Flow and algorithm Diagnostic generation flow for CLI frontend, lowering, and LSP analysis paths.
- Diagnostics parity (CLI and LSP) - Verification and traceability Source anchors and tests used to prevent diagnostic drift between compiler surfaces.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).
Why do line labels differ between CLI and editor?
Section titled “Why do line labels differ between CLI and editor?”Different surfaces intentionally use different source labels; compare rule code, severity, and span semantics.
Why does editor show fewer errors after edits?
Section titled “Why does editor show fewer errors after edits?”Snapshot reuse may be active; trigger a fresh analysis cycle to confirm parity.
Are parse and semantic diagnostics expected to be identical text?
Section titled “Are parse and semantic diagnostics expected to be identical text?”No. Contract requires semantic parity and stable classification, not byte-identical messages.