bQUARKz
6e594c15d7
All checks were successful
JaCoCo Coverage #### Project Overview
No changes detected, that affect the code coverage.
* Line Coverage: 61.37% (17351/28272)
* Branch Coverage: 52.31% (6722/12850)
* Lines of Code: 28272
* Cyclomatic Complexity: 11325
#### Quality Gates Summary
Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
63 lines
2.0 KiB
Markdown
63 lines
2.0 KiB
Markdown
---
|
|
id: AGD-0047
|
|
ticket: pbs-lsp-code-actions
|
|
title: PBS LSP Code Actions and Quick Fixes
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, code-actions, quick-fix]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS diagnostics are visible, but users do not get actionable quick fixes for common compiler/editor problems, making simple repairs slower than necessary.
|
|
|
|
## Context
|
|
|
|
The LSP maps diagnostics but does not announce codeActionProvider. Compiler diagnostics already carry codes and ranges, but not every diagnostic has enough structured repair data to generate safe edits.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Which diagnostics should receive quick fixes first?
|
|
- [ ] Should code actions be produced from diagnostic codes only, or from structured compiler repair hints?
|
|
- [ ] How should imports, reserved attributes, missing methods, and invalid Doc shapes be prioritized?
|
|
|
|
## Options
|
|
|
|
### Option A - Diagnostic-code quick fixes
|
|
|
|
- **Approach:** Map known diagnostic codes to simple edits in the LSP layer.
|
|
- **Pro:** Fast for a small set of obvious repairs.
|
|
- **Con:** Couples fixes to diagnostic text/ranges and can become brittle.
|
|
- **Maintainability:** Moderate if limited to trivial edits.
|
|
|
|
### Option B - Compiler repair hints
|
|
|
|
- **Approach:** Extend diagnostics with structured repair metadata and let the LSP map hints to code actions.
|
|
- **Pro:** Keeps product logic close to compiler knowledge.
|
|
- **Con:** Requires a new diagnostic/repair contract.
|
|
- **Maintainability:** Strong for non-trivial fixes and future frontends.
|
|
|
|
## Tradeoffs
|
|
|
|
Quick fixes are only useful if safe. Simple code-based fixes can ship first, but imports and generated stubs need stronger compiler context.
|
|
|
|
## Recommendation
|
|
|
|
Prefer Option B as the target design, with Option A allowed only for a small bootstrap set of unambiguous repairs.
|
|
|
|
## Discussion
|
|
|
|
This should follow diagnostics UX and import assistance for the first high-value fixes.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
Pick the first three diagnostic codes eligible for safe quick fixes.
|