[ty] Register file roots for first-party search paths#25522
Conversation
`try_register_static_roots` previously skipped first-party search paths (from `ty.toml` `root`) when registering file roots. ``` No root found for path '/my/proj/rdfdb'. Known roots: [...] ``` This applies the same logic already used for dynamic editable install paths (in `dynamic_resolution_paths`): if a first-party path isn't already covered by an existing root, register it as a `LibrarySearchPath` file root. This resolves the panic without affecting paths already under an existing root. Fixes astral-sh/ty#3594
Typing conformance resultsNo changes detected ✅Current numbersThe percentage of diagnostics emitted that were expected errors held steady at 91.94%. The percentage of expected errors that received a diagnostic held steady at 87.09%. The number of fully passing files held steady at 92/134. |
Memory usage reportMemory usage unchanged ✅ |
|
Merging this PR will not alter performance
Comparing 
|
|
I have to take a closer look but the performance regression suggests that we now misclassify first-party files as third-party files and assign them durability Medium instead of low |
Yeah thanks for review. It is my very first PR to an open-source project, thus may not be so comprehensive and perfect. I'd love to offer further assistance. |
… panic Configuring a `root` in `ty.toml` creates a first-party search path, but `try_register_static_roots` skipped first-party paths — leaving them without a `FileRoot`. This caused `expect_root` to panic with "No root found for path" when those paths were later accessed. Fix by attempting a lazy `try_add_root` in `expect_root` before panicking. This avoids the 36% performance regression seen with the eager approach (registering all first-party roots at init), which inadvertently changed Salsa durability for subdirectories like `.venv`. Fixes astral-sh#3594
|
I just pushed a newer version [ty] Register file roots for first-party search paths. I used to register root eagerly and caused performance degradation. Now the fix is a lazy fallback: if a root lookup fails, try registering one before panicking. My performance test seems OK now. 
|
|
| return root; | ||
| } | ||
|
|
||
| // A configured first-party search path may not have been registered |
There was a problem hiding this comment.
While this fix the symptom, this is not the proper fix. The more likely fix is to narrow down why we fail to register the first party paths, then register them instead. I also identified another performance regression in how we handle file roots. I might take a stab at this later today
There was a problem hiding this comment.
Yes you are right. I debugged again and found it is tougher than I thought. I will write a more detailed root-cause-analysis in this PR later.
|
The two commits are all not so perfect and maybe we need more consideration. The root cause is: When we init a path that isn't in the project folder but written in ty.toml's root like: [environment]
root = [
"/Projects/test_ty", # project folder will be registered as FirstParty
"/tmp/some_dep", # isn't FirstParty
]Here's what happening:
So the key question is what kind should |
Summary
Fixes astral-sh/ty#3594.
try_register_static_rootspreviously skipped first-party search paths(from
ty.tomlroot) when registering file roots.When queries like
list_modules_inlater calledexpect_root()on oneof these paths, ty panicked
No root found for path '/path/in/the/ty/config'.Test Plan
cargo testResultFileRootcount increases by 1. I think it is reasonable, because it reflects the newly registered first-party search path root.Screen Recording
Before:
Screen.Recording.2026-06-01.at.22.10.49.mov
After fix:
Screen.Recording.2026-06-01.at.20.23.32.mov