Repository navigation
Fix workspace/symbol crash on an inferred project without a program - #64642
Conversation
Sorry, something went wrong.
… project is up to date
|
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
Sorry, something went wrong.
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The targeted fix and regression coverage address the initialization gap, with no unresolved review findings.
Review effort: Balanced
Findings: None
Fixes a language-server workspace/symbol crash when a newly created inferred project has no program.
Changes:
- Updates the inferred project's program even when the default project is unchanged.
- Adds a regression test covering an orphaned file and a subsequent workspace-symbol request.
| File | Description |
|---|---|
| tsc/internal/project/projectcollectionbuilder.go | Moves inferred-program updates outside the default-project change check. |
| tsc/internal/fourslash/tests/workspaceSymbolNewInferredProject_test.go | Tests the project transition that previously caused the crash. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| } | ||
| // Opening this file may have created the inferred project or changed its roots, | ||
| // even if the default project didn't change | ||
| if b.inferredProject.Value() != nil { | ||
| b.updateProgram(b.inferredProject, logger) | ||
| } |
There was a problem hiding this comment.
Andrew Branch (@andrewbranch) Is there a potential perf hit with this? Touching one file causing rebuilds of an unrelated project?
Sorry, something went wrong.
|
Is this not just a problem with WithSnapshotLoadingProjectTree or the handler that calls it? That method doesn't update the inferred project at all, and yet the workspace symbol handler then calls LanguageServiceProjects() which includes it. |
Sorry, something went wrong.
fixes the issue reported here: #64623 (comment)