fix(vendor): derive Windows supplied-home scan paths - #61
Merged
Conversation
Explicit-home scans already stopped consulting process APPDATA and LOCALAPPDATA, but config clients still fell back to <home>/.config/tokscale and Zed had no supplied AppData/Local path. An isolated Windows --home scan therefore could not discover the canonical profile layout. Derive config and Zed paths from the supplied home when environment roots are disabled, while preserving process known-folder discovery for default scans. Add a direct Zed regression and move scanner-settings fixtures off the new canonical default path so they still prove the independent extra-path seam. No parser output, cache layout, FFI, or public API changes; cache schema remains 29.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
<home>/AppData/Roaming/tokscale<home>/AppData/Local/Zed/threads/threads.dbwhen environment roots are disabledAPPDATA/LOCALAPPDATAdiscovery unchanged and preserve independent scanner-settings extra-path coverageRoot cause
PR #59 isolated explicit-home scans from the process profile, but the positive supplied-profile layout was incomplete:
PathRoot::Configstill fell back to<home>/.config/tokscale, and Zed had no suppliedAppData/Localcandidate. The scan therefore avoided the wrong profile without finding the canonical Windows paths under the requested home.The Zed extra-path fixtures also used the same path that is now canonical. They moved to
custom-zed/threadsso a passing test still proves the settings seam rather than succeeding through default discovery.Regression evidence
Before the production change, the direct supplied-home Zed fixture failed hermetically:
After the change, the positive supplied-home fixture, the independent Zed extra-path scanner fixture, and the materialized
parse_local_clientsextra-path fixture all pass.Verification
cargo test— 230 FFI tests and 1,059 core tests passed; one core test ignored; integration binaries passedcargo clippy --workspace --all-targets— passed with existing warningsmake buildswift run TokenBar --selftestswift run TokenBar --smokemake check-docsgit diff --checkRepository-wide
cargo fmt --all -- --checkstill reports pre-existing formatting drift outside this change. Rustfmt emits no diff at the modified hunks.Platform boundary
The Zed supplied-home path is exercised by a platform-neutral hermetic fixture on macOS. The config branch remains
#[cfg(target_os = "windows")]; the conditional unit assertion pins its Windows path but was not executed on a Windows runner in this repository. This is not a Windows runtime verification claim.No parser output, cache layout, cache schema, FFI, C ABI, Swift contract, tag, or release changes are included.