Skip to content

build(deps): core/go v0.12.1 — a true no-op bump (34 → 34), plus the layer finding - #30

Merged
Snider merged 1 commit into
mainfrom
lane/corego-v0121
Aug 8, 2026
Merged

build(deps): core/go v0.12.1 — a true no-op bump (34 → 34), plus the layer finding#30
Snider merged 1 commit into
mainfrom
lane/corego-v0121

Conversation

@Snider

@Snider Snider commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

This is a no-op bump. It clears zero windows-lane packages. The original body claimed it would clear 33; the run says otherwise, and the layer analysis below is the actual finding. Landing it anyway because the pin should not drift and the fixes it carries are real.

Measured: 34 → 34

dappco.re/go v0.12.1 is in the build (confirmed in the run's module output), and every error count is byte-identical:

error shape before after
path escapes from parent 399 399
cannot find the path specified 19 19
Program.Find 41 41

Not 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 parent is not core/go's message at all — it is Go's own os.Root error. io.Local is built in dappco.re/go/io, a separate module:

io.go:143            Local, err = local.New("/")
local/medium.go:60   rootHandle, err := os.OpenRoot(absoluteRoot)

It never touches core.Fs. os.OpenRoot confines every operation to a directory handle, so on Windows io.Local is 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.Local exists 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 on core.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.Find is process.Program.Find in dappco.re/go/process, which resolves through a second copy of lookPath in os_exec_link.go that my own v0.16.2 missed — exec/ was fixed, the root package was not. 3 packages. Fixed in go-process#10.

What this bump is worth

App.Find and Fs.path were 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

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

CI: linux ✅ macos ✅ · windows unchanged at 34 (experimental lane).

Scope

Only go/ is bumped. cli/ pins v0.12.0 and examples/ 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.

…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>
@coderabbitai

coderabbitai Bot commented Aug 8, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@Snider, you've reached your PR review limit, so we couldn't start this review.

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ca2178fb-cc1d-4212-8f98-0a5088e8541e

📥 Commits

Reviewing files that changed from the base of the PR and between 05af590 and 04f09c9.

⛔ Files ignored due to path filters (1)
  • go/go.sum is excluded by !**/*.sum
📒 Files selected for processing (1)
  • go/go.mod

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Snider Snider changed the title build(deps): core/go v0.12.1 — io.Local root (#21) + App.Find on Windows (#22) build(deps): core/go v0.12.1 — a true no-op bump (34 → 34), plus the layer finding Aug 8, 2026
@Snider
Snider merged commit 23f265e into main Aug 8, 2026
3 of 4 checks passed
@Snider
Snider deleted the lane/corego-v0121 branch August 8, 2026 11:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant