build(deps): core/go v0.12.1 — a true no-op bump (34 → 34), plus the layer finding - #30
Conversation
…d on Windows) v0.12.1 carries the two core/go fixes this repo's windows lane has been blocked on, and which no amount of work here could reach: - #21 — io.Local was local.New("/"), and "/" is not an absolute root on Windows, it names the CURRENT DRIVE. An absolute "C:\Users\..." under a D:-rooted medium gave "path escapes from parent"; a relative "testdata/x.json" resolved against the drive root instead of the cwd and gave "The system cannot find the path specified". 30 of the 34 remaining packages report one shape or the other. - #22 — App.Find carried the same three defects go-process v0.16.2 fixed: no %PATHEXT% expansion, a mode&0111 test Windows can never satisfy (os.Stat synthesises 0666/0444, so it rejected every file including git.exe), and a path-vs-name check that missed '/'. 3 packages report `Program.Find: "git": not found in PATH`. Receipts — macOS: GOWORK=off go test -count=1 ./... exit=0, 176 packages ok GOWORK=off go build ./... · go vet ./... clean cli: go test -count=1 ./tui/... ok 6.510s examples: go build ./... · go vet ./... clean Only go/ is bumped. cli/ pins v0.12.0 and examples/ v0.11.0, but both build through the workspace, which already selects the highest version across modules — the skew predates this and is not widened by it. Lane state going in: 34 (main, run 31251799117). The windows number is this lane's own and is posted from the run, not predicted here. Co-Authored-By: Virgil <virgil@lethean.io>
|
Warning Review limit reached
Next review available in: 42 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Measured: 34 → 34
dappco.re/go v0.12.1is in the build (confirmed in the run's module output), and every error count is byte-identical:path escapes from parentcannot find the path specifiedProgram.FindNot one package cleared (run 31253505190).
Why — both fixes are correct and both land on a layer this repo does not call
core/go #21 (
Fs.path) is not what fails here.path escapes from parentis not core/go's message at all — it is Go's ownos.Rooterror.io.Localis built indappco.re/go/io, a separate module:It never touches
core.Fs.os.OpenRootconfines every operation to a directory handle, so on Windowsio.Localis scoped to one drive: a path on another drive escapes, and a relative path resolves against the drive root rather than the cwd. 30 packages.That containment is the design, not a defect — it is the security property
io.Localexists to provide, and drive-scoping on Windows is it working as built. The fix is therefore consumer-side and in this repo: call sites handling unbounded or user-supplied paths belong oncore.Stat/core.ReadFile/core primitives, with the medium kept for genuinely rooted trees. Same pattern the estate applied in go-render #49/#51, documented as estate task #121. Tracked separately from this bump.core/go #22 (
App.Find) is not what this repo calls.Program.Findisprocess.Program.Findindappco.re/go/process, which resolves through a second copy oflookPathinos_exec_link.gothat my ownv0.16.2missed —exec/was fixed, the root package was not. 3 packages. Fixed in go-process#10.What this bump is worth
App.FindandFs.pathwere genuinely broken and are genuinely fixed. They are simply not the code paths go-inference exercises. Keeping the pin current costs nothing and stops drift.Receipts — macOS
CI: linux ✅ macos ✅ · windows unchanged at 34 (experimental lane).
Scope
Only
go/is bumped.cli/pinsv0.12.0andexamples/v0.11.0; both build through the workspace, which already selects the highest version across modules — the skew predates this and is not widened by it.