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-0046
|
|
ticket: pbs-lsp-rename-symbol
|
|
title: PBS LSP Rename Symbol
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [studio, lsp, vscode, compiler-pbs, editor, rename]
|
|
---
|
|
|
|
## Pain
|
|
|
|
Domain owner: `studio/lsp`
|
|
|
|
PBS users cannot safely rename a symbol through the editor, so they must edit text manually and risk missing references or changing unrelated overloads and same-name declarations.
|
|
|
|
## Context
|
|
|
|
Rename requires the same semantic identity and reference machinery needed by definition/references, plus workspace edits and conflict detection. The current LSP does not announce renameProvider.
|
|
|
|
## Open Questions
|
|
|
|
- [ ] Which symbols should be renameable in the first wave, and which should be protected such as stdlib, generated, host, or builtin declarations?
|
|
- [ ] How should rename handle overloads, member methods, imports, and labels with the same text?
|
|
- [ ] What validation should run before returning a WorkspaceEdit?
|
|
|
|
## Options
|
|
|
|
### Option A - Local file rename
|
|
|
|
- **Approach:** Rename only references in the current file using local semantic resolution.
|
|
- **Pro:** Smaller blast radius and easier conflict handling.
|
|
- **Con:** Incomplete for imported symbols and project-wide APIs.
|
|
- **Maintainability:** Acceptable only if explicitly presented as limited.
|
|
|
|
### Option B - Workspace semantic rename
|
|
|
|
- **Approach:** Use a project-wide reference index and return a `WorkspaceEdit` for all usage and declaration sites.
|
|
- **Pro:** Matches user expectations for editor rename.
|
|
- **Con:** Requires reliable references, collision checks, and write-safety across files.
|
|
- **Maintainability:** Strong once references exist.
|
|
|
|
## Tradeoffs
|
|
|
|
Rename is high trust. A partial or text-based rename can corrupt code silently, so scope must be explicit and conservative.
|
|
|
|
## Recommendation
|
|
|
|
Prefer Option B after semantic references are implemented. If delivered earlier, ship only a clearly limited local rename.
|
|
|
|
## Discussion
|
|
|
|
Do not implement rename before definition/references are resolved.
|
|
|
|
## Resolution
|
|
|
|
Ainda em aberto.
|
|
|
|
## Next Step
|
|
|
|
Decide whether rename waits for workspace references or ships a limited local-only wave.
|