Repository navigation
Conversation
Every job here checks out vlang/v master and builds it. V master broke its own bootstrap on 2026-10-02 in 233f259a7a, which added C.S_IFMT to vlib/os/os_stat_windows.c.v - a constant the bundled tcc does not define on Windows. The result was that all four jobs went red and stayed red for ten days, with no change on this side: mknod, un-ignore-windows-ports, stdbuf and stty all failed identically, each one during the V bootstrap before any code of ours compiled. There is an open V branch named os-stat-include fixing exactly that file, and it has not landed. So this is an isolation measure rather than a freshness one: it stops an upstream regression being read as a failure of this repo. 532f63b6d2 is the parent of that commit and builds. A pin alone trades one problem for another, because it goes stale, and a stale pin means these tools quietly stop building against current V. bump-v.yml closes that: it builds the tree against current V master, and only if both the compile and the test suite pass does it open a PR moving the pin. While V master is broken it stays quiet, which is right - it is reporting an upstream problem, not one of ours. Split out from the multicall branch, where it had travelled alongside unrelated work and would have been easy for a reviewer of that PR to miss.
Every job here checks out vlang/v master and builds it. V master broke its own bootstrap on 2026-10-02 in 233f259a7a, which added C.S_IFMT to vlib/os/os_stat_windows.c.v - a constant the bundled tcc does not define on Windows. All four jobs went red and stayed red for ten days with no change on this side: mknod, un-ignore-windows-ports, stdbuf and stty all failed identically, each during the V bootstrap before any code of ours compiled. The first version of this pinned 532f63b6d2, the parent of that commit. It failed too, for a second reason found by a run rather than by reading: its own vc/v.c bootstrap cannot parse vlib/math/bits/bits.v, because the bootstrap compiler rejects the if-expression assigned to abs_x at line 621. A pin that does not bootstrap is no better than no pin. So the pin is an official weekly tag instead, weekly.2026.41, which avoids both: the S_IFMT commit is not an ancestor of it, verified with merge-base --is-ancestor, and its bits.v assigns from an if expression rather than starting a condition with one. The reasons are recorded at the V_REF line so the next person does not have to rediscover either of them. bump-v.yml keeps it from going stale: it builds against current V master and only opens a PR moving the pin when both the compile and the test suite are green. While V master is broken it stays quiet, which is right, because it is reporting an upstream problem rather than one of ours. Split out from the multicall branch, where it had travelled alongside unrelated work.
|
I need to walk back the reasoning in this PR's description, because it was wrong. What I claimed, and why it was wrongI wrote that V master broke its own bootstrap on 2026-10-02 in
What the evidence actually showsThree V revisions tried, three different failures, all inside V's own bootstrap before any coreutils code is reached:
That pattern is not a regression I can pick a good revision around. V is currently in a state where recent revisions do not build at all. Every CI job in this repository has been red for that reason, and pinning cannot fix it. Where that leaves this PRThe mechanism is still worth having — But I no longer claim this makes CI green, and I would not merge it expecting that. What it should do is stop the bleeding: with master tracked by name, an upstream breakage shows up here as "this PR is broken", which is how 21 PRs of mine arrived looking red when none of them touch the V bootstrap. What I'd rather doThe honest ask to upstream is "V revisions from Feb 2024 onward fail Given that, I'm happy for this PR to be closed as-is. If you'd prefer it stay open purely as the master-tracking cleanup, say so and I'll retitle it to say that, and nothing more. |
1 participant
I need to walk back the reasoning in this PR's description, because it was wrong.
What I claimed, and why it was wrong
I wrote that V master broke its own bootstrap on 2026-10-02 in
233f259a7a, which addedC.S_IFMT. I "verified" that the parent commit was safe. Both claims were wrong, and the check that produced them was the problem:C.S_IFMThas been in V since February 2024, in every revision including the tag this PR pins. Mymerge-base --is-ancestorcheck returned "not an ancestor" only because V master had been force-pushed, so that commit hash was gone. I read "this hash isn't there" as "this code isn't there" — a cosmetic fact as a causal one.What the evidence actually shows
Three V revisions tried, three different failures, all inside V's own bootstrap before any coreutils code is reached:
vlib/os/os_stat_windows.c.v:112: 'S_IFMT' undeclared532f63b6d2vlib/math/bits/bits.v:621— bootstrap can't parse theif-expressionweekly.2026.41(this PR)src.c:13373: conflicting types for 'v_os_exec_capture_start'That pattern is not a regression I can pick a good revision around. V is currently in a state where recent revisions do not build at all. Every CI job in this repository has been red for that reason, and pinning cannot fix it.
Where that leaves this PR
The mechanism is still worth having —
ci.ymlcurrently tracks V master by name, so this repo's entire CI is a function of whatever upstream happens to be doing that hour. Both the pin andbump-v.yml(which only moves the pin when a build and test run are both green) address that, and they're correct independently of which revision wins.But I no longer claim this makes CI green, and I would not merge it expecting that. What it should do is stop the bleeding: with master tracked by name, an upstream breakage shows up here as "this PR is broken", which is how 21 PRs of mine arrived looking red when none of them touch the V bootstrap.
What I'd rather do
The honest ask to upstream is "V revisions from Feb 2024 onward fail
winos-test's bootstrap" — that is a V bug, not a coreutils one, and it deserves its own issue against vlang/v rather than being worked around here.Given that, I'm happy for this PR to be closed as-is. If you'd prefer it stay open purely as the master-tracking cleanup, say so and I'll retitle it to say that, and nothing more.