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.4 KiB
Markdown
63 lines
2.4 KiB
Markdown
---
|
|
id: AGD-0043
|
|
ticket: pbs-lsp-find-references
|
|
title: PBS LSP Find References
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, references]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS users cannot ask where a symbol is used, so changes to functions, services, structs, constants, and stdlib-facing APIs require manual search that confuses overloads and unrelated text matches.
|
|
|
|
## Context
|
|
|
|
Completion and hover already resolve symbols in local editor context, but the LSP does not expose references and the compiler/editorial layer does not yet provide project-wide usage locations keyed by semantic identity.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Which declarations need reference tracking first: local functions, methods, types, constants, imports, stdlib symbols, or all of them?
|
|
- [ ] How should overloads and same-name symbols in different scopes be disambiguated?
|
|
- [ ] Should references include declarations, write/read classification, or only usage sites in the first wave?
|
|
|
|
## Options
|
|
|
|
### Option A - Text search with filters
|
|
|
|
- **Approach:** Search workspace text for the selected identifier and filter obvious false positives by token kind.
|
|
- **Pro:** Simple and fast for early demos.
|
|
- **Con:** Incorrect for overloads, scope, shadowing, fields, methods, imports, and generated/stdlib surfaces.
|
|
- **Maintainability:** Poor; later semantic references would duplicate and replace it.
|
|
|
|
### Option B - Semantic usage index
|
|
|
|
- **Approach:** During semantic analysis, emit definition and usage sites tied to stable symbol identities and expose `textDocument/references`.
|
|
- **Pro:** Correct foundation for rename, call hierarchy, diagnostics UX, and code actions.
|
|
- **Con:** Requires compiler-facing usage modeling and careful invalidation.
|
|
- **Maintainability:** Strong; one source of truth for all symbol usage features.
|
|
|
|
## Tradeoffs
|
|
|
|
Reference accuracy matters more than early breadth. False positives are worse than missing unsupported categories because users will trust rename and references for safe edits.
|
|
|
|
## Recommendation
|
|
|
|
Prefer Option B, but scope the first wave to project-owned declarations whose identity is already resolved reliably.
|
|
|
|
## Discussion
|
|
|
|
References should follow go-to-definition because both need the same identity and location model.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
Define first-wave symbol categories and whether declarations are included in reference results.
|