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.1 KiB
Markdown
63 lines
2.1 KiB
Markdown
---
|
|
id: AGD-0050
|
|
ticket: pbs-lsp-semantic-tokens-semantic-classification
|
|
title: PBS LSP Semantic Token Classification
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, semantic-tokens]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS semantic highlighting exists, but parts of the token classification can remain lexical or superficial, which limits visual accuracy for same-looking identifiers with different semantic roles.
|
|
|
|
## Context
|
|
|
|
The current LSP announces full semantic tokens and maps frontend semantic presentation to VS Code. The compiler has semantic read surfaces that can classify symbols more accurately than raw tokenization.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Which token categories must become semantic identity-based first?
|
|
- [ ] Should semantic tokens be produced from compiler semantic surfaces, parser AST, lexer tokens, or layered output?
|
|
- [ ] How should tokens behave in files with syntax or semantic errors during active editing?
|
|
|
|
## Options
|
|
|
|
### Option A - Lexical tokens with semantic overlays
|
|
|
|
- **Approach:** Keep lexer-based tokenization as baseline and overlay semantic categories where resolution succeeds.
|
|
- **Pro:** Stable during broken edits and incremental to improve.
|
|
- **Con:** Some unresolved identifiers remain visually generic.
|
|
- **Maintainability:** Strong because fallback behavior is explicit.
|
|
|
|
### Option B - Fully semantic token stream
|
|
|
|
- **Approach:** Generate all semantic tokens from compiler semantic surfaces.
|
|
- **Pro:** Maximum accuracy when analysis succeeds.
|
|
- **Con:** Highlighting may disappear or degrade sharply on incomplete code.
|
|
- **Maintainability:** Risky unless snapshot/error recovery is excellent.
|
|
|
|
## Tradeoffs
|
|
|
|
Highlighting must be resilient while the user is typing. A perfect semantic pass that fails on partial code is worse than a layered model.
|
|
|
|
## Recommendation
|
|
|
|
Prefer Option A: lexical baseline plus semantic overlays from resolved symbols.
|
|
|
|
## Discussion
|
|
|
|
This can proceed independently but benefits from LSP snapshot/cache work.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
Choose semantic overlay categories for the first pass.
|