Skip to content

parser: a forall no longer takes its checkable neighbours with it (Refs #2161) - #2740

Merged
gHashTag merged 2 commits into
masterfrom
w699-partial
Aug 27, 2026
Merged

parser: a forall no longer takes its checkable neighbours with it (Refs #2161)#2740
gHashTag merged 2 commits into
masterfrom
w699-partial

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

An invariant reading

assert g(1) == 111
forall x: i32 . g(x) == x
assert g(2) == 222

lost both asserts. Skipping an unbounded forall is a defensible language decision — the compiler says so in its own comment — but taking the clauses around it is a second loss on top of the defensible one, and nothing recorded that it happened.

Clauses lowered before the unmodellable one are now kept, and the block is marked.

The mark matters as much as the keeping: the emitter's NOT CHECKED notice keys on children.is_empty(), so a partial block without it would report as fully verified — the exact claim W635 exists to stop. Now it carries its assertions and its notice.

Clauses after the forall are still skipped: the parser jumps to the next top-level from there, and reaching them is a different change.

Measured over 746 tracked specs

before after
assertions in generated Zig 11,704 11,712 (+8)
NOT CHECKED markers 1,068 1,068
specs that lost an assertion 0
specs that parse 620 620
t27c tests 1629 / 6 1629 / 6
RATCHET CLEAN

Eight is the honest number. The census that motivated this estimated ~9,400 recoverable tokens, but that counterfactual rewrote the source, while this keeps what the existing parser already lowered. The eight were silently dropped before and are checked now — and the mechanism is what stops the next forall from doing it again.

Found with the compiler's own instrument: T27_BDD_DEBUG named the fallback site on the first try, after I had guessed the wrong one, edited it, and watched the probe not move.

Refs #2161

…Refs #2161)

An invariant reading

    assert g(1) == 111
    forall x: i32 . g(x) == x
    assert g(2) == 222

lost BOTH asserts. Skipping an unbounded `forall` is a defensible
language decision -- the compiler says so in its own comment -- but
taking the clauses around it is a second loss on top of the defensible
one, and nothing recorded that it happened.

Clauses lowered BEFORE the unmodellable one are now kept, and the block
is MARKED. The mark matters as much as the keeping: the emitter's
"NOT CHECKED" notice keys on `children.is_empty()`, so a partial block
without it would report as fully verified -- the exact claim W635 exists
to stop. Now it carries its assertions AND its notice.

Clauses AFTER the `forall` are still skipped: the parser jumps to the
next top-level from there, and reaching them is a different change.

Measured over 746 tracked specs, before binary vs after:

    assertions in generated Zig   11,704 -> 11,712   (+8)
    NOT CHECKED markers            1,068 -> 1,068
    specs that LOST an assertion                 0
    specs that parse                     620 -> 620
    t27c tests                        1629/6 -> 1629/6
    RATCHET                                     CLEAN

Eight is the honest number. The census that motivated this estimated
~9,400 recoverable tokens, but that counterfactual assumed a different
mechanism -- it rewrote the SOURCE, while this keeps what the existing
parser already lowered. The eight were silently dropped before and are
checked now, and the mechanism is what stops the next `forall` from
doing it again.

Found with the compiler's own instrument: T27_BDD_DEBUG named the
fallback site on the first try, after I had guessed the wrong one and
edited it to no effect.

FROZEN_HASH resealed in the same commit (M5).
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-27 20:33:36 UTC

Summary

Status Count
Total Open PRs 9
PRs with Failing Checks 8
PRs with All Checks Green 1
READY 0
FAILING 8
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=f9074870f5f3 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit f849308 into master Aug 27, 2026
33 of 34 checks passed
@gHashTag
gHashTag deleted the w699-partial branch August 27, 2026 20:45
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