Evaluate impact of folding definitions#417
Closed
jcp19 wants to merge 10 commits into
Closed
Conversation
Prevent git from CRLF-normalizing binary files (corrupting PNGs etc.) and preserve CRLF for .bat files. Renormalize doc/make.bat blob.
Python rewriter that inlines the `Bytes` predicate at every call site: - Replaces `sl.Bytes(s, a, b)` / `slices.Bytes(...)` / bare `Bytes(...)` with the predicate body, parenthesised. - Propagates fractions through `acc(Bytes(...), p)`. - Deletes statement-level `fold` / `unfold` lines. - Collapses `unfolding Bytes(...) in e` to `e`. - In .go files, only rewrites inside Gobra annotations (`// @` and `/*@ ... @*/`). - `--specs-only` skips function bodies (used for slices.gobra where the helpers' own bodies must continue to use the predicate).
Run tools/inline_bytes.py over the verified spec surface (router/, pkg/, private/, verification/). The `Bytes` predicate is no longer named in caller specs; each invocation has been replaced by its body, with fractions propagated through enclosing `acc(...)` and statement-level fold/unfold lines removed. The predicate definition itself stays in verification/utils/slices/slices.gobra so the helper functions (SplitByIndex_Bytes, CombineAtIndex_Bytes, Reslice_Bytes, ...) can continue to fold/unfold it internally; only those helpers' specs were rewritten, not their bodies.
jcp19
changed the title
The previous pass only recognised bare `fold` / `unfold` at the start of an annotation line. Lines like `// @ ghost defer fold sl.Bytes(...)` and `// @ defer unfold acc(sl.Bytes(...), R21)` slipped through, leaving behind an inlined forall body where Gobra expected a predicate access (\"Translation of predicateAccess (0<=0&&...) failed\"). The line-deletion detector now skips optional `ghost ` and `defer ` prefixes before looking for `fold` / `unfold`. Reran the rewriter on the six affected files.
The helper existed to provide a `Bytes(nil, 0, 0)` predicate instance.
After inlining, that instance becomes a body containing `cap(nil)` and
`&nil[i]`, which Gobra rejects ("expected an array or slice type, but
got nil"). The inlined assertion at caller sites is vacuously true
(the forall ranges over an empty interval), so the helper is no longer
useful.
Removed:
- func NilAcc_Bytes in verification/utils/slices/slices.gobra
- the 6 `sl.NilAcc_Bytes()` calls in router/dataplane.go
The helpers in verification/utils/slices/slices.gobra (and the test file)
were previously fold/unfolding the `Bytes` predicate internally to
discharge their own postconditions. With the specs now expressing the
predicate body inline, the predicate access isn't held when the body
runs, and Gobra rejected the `unfolding Bytes(...) in s[i]` form in
`GetByte` ("Permission to Bytes(s, start, end) might not suffice").
Reran the rewriter on slices.gobra / slices_test.gobra without
--specs-only to drop those fold/unfold/unfolding statements. The
asserts that establish address equivalences (Reslice_Bytes,
Unslice_Bytes loop, PermsImplyIneq*) are preserved.
Originally, sites like
return unfolding sl.Bytes(raw, ...) in
raw[InfoFieldOffset(currINF, headerOffset)] & 0x1 == 0x1
were rewritten by stripping `unfolding sl.Bytes(...) in ` but keeping the
trailing newline, producing
return
raw[InfoFieldOffset(currINF, headerOffset)] & 0x1 == 0x1
Gobra parsed this as `return; raw[...] & 0x1 == 0x1` — a bare return
followed by an expression statement — and rejected the pure-func body
("property error: ... is not executable" / "expected a single return").
Two-part fix:
- tools/inline_bytes.py now consumes a trailing newline plus the next
line's indentation when collapsing `unfolding ... in `, so the
expression rejoins the same line.
- Joined the orphaned `return` lines in the already-rewritten files:
pkg/slayers/path/infofield_spec.gobra (ConsDir, Peer, BytesToAbsInfoField)
pkg/slayers/scion_spec.gobra (GetAddressOffsetWithinLength,
GetLengthWithinLength, GetPathType, GetNextHdr)
pkg/slayers/path/scion/raw_spec.gobra (RawBytesToMetaHdr)
`acc(P)` is sugar for `acc(P, write)`. When P was `sl.Bytes(...)`, the
rewriter saw an acc(...) wrapper with one argument, didn't recognise it
as the predicate-access form, and fell through to a plain replacement —
producing `acc((forall...))`, which Gobra rejects ("expected expression
with pointer or predicate type, but got assertion").
The fix is symmetric to the 2-arg case: drop the outer `acc(...)`
entirely. The inlined body already grants write permission via
`acc(&s[i])` (no explicit fraction).
Also patched the three sites that the previous pass left broken:
- pkg/experimental/epic/epic_spec.gobra (postInitInvariant body)
- pkg/slayers/path/scion/base.go (deleted the orphaned
`fold/unfold acc((...))` statement-level annotations)
The inlined Bytes body bound its forall index to `i`. When the body was
substituted into an outer `forall i int :: <body>` (e.g., socket.gobra's
ensureBufferInjectivityAgainstList preconditions), the inner `i` shadowed
the outer one. Subsequent references like `msgs[i].GetFstBuffer()` --
intended to track the outer index -- silently rebound to the inner index,
breaking verification ("Permission to m.Mem() might not suffice").
Two-part fix:
- tools/inline_bytes.py now emits `forall iBytes int :: { &s[iBytes] }
... acc(&s[iBytes], ...)` for newly-rewritten sites.
- For the 54 files already rewritten with `i`, applied a targeted rename
that touches only inlined-body scopes (signature `<= cap(...) && forall
i int :: { &`). Within each such scope, only the inner-i positions are
renamed: the binder, the bounds `<= i && i <`, and the trailing `[i]`
in subscripts. Subscripts followed by `.` (outer-i references like
`msgs[i].GetFstBuffer()`) are left alone.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.