Intrepid/prometeu-studio
Intrepid/prometeu-studio
4
0
Fork 0
Code Pull Requests Activity
prometeu-studio/discussion/workflow/agendas/AGD-0043-pbs-lsp-find-references.md
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.
Details
Test / Build skipped: 15, passed: 601
Details
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
Details
add LSP agendas
2026-07-15 07:40:45 +01:00

2.4 KiB
Raw Permalink Blame History

id ticket title status created resolved decision tags
AGD-0043 pbs-lsp-find-references PBS LSP Find References open 2026-07-15
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.