builder: fix infinite loop in find_module_path for projects at a Windows drive root - #27473
Conversation
…ows drive root
When a V project is located directly under a drive root (e.g. `S:\proj`),
`find_module_path`'s "anchor to the outermost enclosing v.mod" loop never
terminated, so building the project (including `make`/`makev.bat`) hung
forever at 100% CPU.
`os.dir("S:\proj")` returns the bare drive `"S:"`, and inside
`get_by_folder` `os.real_path("S:")` resolves a bare drive letter to that
drive's *current directory* (back into the project), so the walked folder
never moved up while the loop's guard compared the unresolved `"S:"` against
the full path and never broke.
Only climb when the resolved parent v.mod is a strict ancestor of the current
folder. This handles both the fixpoint case (project at a drive root) and the
multi-step oscillation case (a project nested under such a drive-root project).
Fixes vlang#27472
Co-Authored-By: WOZCODE <contact@withwoz.com>
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
Bouncing to pick up changes in master... |
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8141a0de94
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
On Windows, os.dir('C:\project') returns 'C:' (bare drive letter with no
trailing slash). os.dir('C:') returns '.' and os.dir('.') returns '.' —
a fixed point that the existing '/' stop condition in traverse never
catches, causing the upward vmod search to burn 255 iterations instead
of stopping cleanly. Any caller of get_by_folder/get_by_file was exposed
(checker, util, vdoc, vpm), not just builder.
Fix traverse (vmod.v) to break as soon as os.dir stops making progress
(next == cfolder). This is the correct general stop condition and
subsumes the Windows drive-root, Unix root, and '.' cases in one check.
Add is_strict_ancestor in builder.find_module_path as a belt-and-
suspenders guard: stop climbing the outermost-vmod chain whenever the
cache returns a candidate that is not a strict path ancestor of the
current folder. Implemented by delegating to the existing
comparable_real_path + path_is_at_or_inside helpers already in the file.
Co-Authored-By: WOZCODE <contact@withwoz.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep it up! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
Merge master in for a final run of the CI with all the latest changes. Some, if not all, of the failures have been fixed in master... and whatever is left probably isn't related to your changes... but it's hard to tell with so many lines of output... |
Co-Authored-By: WOZCODE <contact@withwoz.com>
|
CI failures are unrelated to this PR |
|
Agreed |
3 participants
What
Fixes an infinite loop (100% CPU, no output, never completes) when building a V
project located directly under a drive root on Windows (e.g.
S:\proj).This also makes
make/makev.bathang at theCompiling "./v_stage.exe" with "./v_win_bootstrap.exe"step for drive-rootcheckouts.
Fixes #27472
Root cause
In
find_module_path()(vlib/v/builder/builder.v), the loop that anchors animporter to the outermost enclosing
v.modnever terminated for a drive-rootproject:
os.dir("S:\proj")returns the bare drive"S:".get_by_folder("S:"),os.real_path("S:")resolves a bare driveletter to that drive's current directory (
"S:\proj"), i.e. back into theproject.
So
importer_vmod_foldernever moved up, while the loop's guard compared theunresolved
"S:"against the full"S:\proj"and never broke. At a nested path(
S:\repo\proj) the parent has nov.mod, so the loop exited normally — whichis why moving the checkout one level deeper avoided the hang.
Fix
Only climb when the resolved parent
v.modis a strict ancestor of thecurrent folder. This terminates both:
where the bare-drive
real_pathjump can bounce between an outer and innerv.mod).The vendored-
modules/anchoring this loop was originally added for ispreserved, since a real outer
v.modis always a strict ancestor.Testing
cmd/vfrom a drive-root checkout never completes;from a nested path it takes ~6s.
cmd/vfrom a drive-root checkout completes normally, and theresulting compiler self-rebuilds at the drive root in ~7s.
v -silent vlib/v/builder/base_url_test.v(coversfind_module_path) passes.Note
make/makev.batbootstrap their first stage from the pre-generatedvc/v_win.c, so the bootstrap step will keep hanging at a drive-root checkoutuntil
vlang/vcis regenerated with this fix.🧙 Built with WOZCODE