bQUARKz
099857b636
Lock DSC-0066 on Q1-A and Q2-A. Retire AGD-0048 through AGD-0056 into AGD-0069, DEC-0058, and PLN-0137. Published editor diagnostics use the bound frontend language id as source. For PBS that is pbs. The stable compiler code stays in code and is not copied into source. Related locations, phase, and repair payload stay unpublished.
63 lines
2.3 KiB
Markdown
63 lines
2.3 KiB
Markdown
---
|
|
id: AGD-0054
|
|
ticket: pbs-lsp-diagnostics-ux
|
|
title: PBS LSP Diagnostics UX
|
|
status: abandoned
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, diagnostics, ux]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS diagnostics reach VS Code, but the editor experience can still be hard to act on when ranges, related information, severity, and phase context are too generic.
|
|
|
|
## Context
|
|
|
|
The LSP maps compiler diagnostics to LSP diagnostics. Compiler diagnostics include phase/code/message/range in several paths, but not all editor-friendly fields are consistently exposed.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Which diagnostics need better ranges or related information first?
|
|
- [ ] Should diagnostic source include compiler phase, frontend, or both?
|
|
- [ ] What structured diagnostic metadata is needed for future quick fixes without coupling UI to text messages?
|
|
|
|
## Options
|
|
|
|
### Option A - Mapper-only UX improvements
|
|
|
|
- **Approach:** Improve LSP diagnostic mapping using existing diagnostic fields.
|
|
- **Pro:** Quick improvements to source, severity, and display consistency.
|
|
- **Con:** Cannot add missing related spans or repair metadata that compiler diagnostics do not expose.
|
|
- **Maintainability:** Good for presentation-only changes.
|
|
|
|
### Option B - Structured diagnostic contract
|
|
|
|
- **Approach:** Extend compiler diagnostics with editor-facing metadata such as phase, related locations, stable quick-fix hints, and refined ranges.
|
|
- **Pro:** Enables better diagnostics and future code actions without parsing message text.
|
|
- **Con:** Requires compiler/core diagnostic API changes.
|
|
- **Maintainability:** Strong as the foundation for quick fixes and richer UX.
|
|
|
|
## Tradeoffs
|
|
|
|
Some improvements belong in the LSP mapper, but the most valuable changes require structured information at diagnostic creation time.
|
|
|
|
## Recommendation
|
|
|
|
Prefer Option B as the target, with mapper-only cleanup allowed for low-risk display fixes.
|
|
|
|
## Discussion
|
|
|
|
This agenda should inform code actions before quick fixes become broad.
|
|
|
|
## Resolution
|
|
|
|
Aposentada em 2026-09-22. O tema foi consolidado em [AGD-0069](AGD-0069-pbs-lsp-remaining-editor-surface.md) / DSC-0066. Este texto não é normativo.
|
|
|
|
## Next Step
|
|
|
|
Inventory high-frequency diagnostics and identify which need better ranges, related information, or repair hints.
|