46Verification
Repair a false implicit-condition contract
Situation
consume has an explicit active predicate, but it also reads and removes an
entry from a bounded FIFOF. Its scheduling attribute claims that called
methods add no implicit conditions. Compilation rejects that claim because an
empty queue cannot provide first or perform deq.
The queue behavior, state updates, interface, and supplied mkTop are trusted.
Only the rule's scheduling contract is editable for this repair.
Read and predict before editing
Read in this order:
- Record the initial values of
active,doneReg, andresultReg. - Find every method called by
consume, including value and action methods. - Separate the explicit
activepredicate from queue readiness. - Trace
mkTopthroughfill,start, andshow.
Before Run, predict compilation first. The source assertion requires active to
be the only condition controlling consume, but queue.first and queue.deq
are unavailable when the queue is empty. That contradiction is detected during
scheduling; it is not a simulation timeout and not evidence that active is
wrong.
Make the minimal change
Allow the compiler to retain the queue methods' actual implicit conditions.
Preserve the explicit predicate, all queue operations, and every register
update. Do not add queue.notEmpty to the rule guard: it can describe equivalent
control, but it is unnecessary scope and would obscure the lesson that method
readiness already participates in the rule condition.
The minimal reasoning is: consume may fire only when active is true and
an entry is available. The rule needs that conjunction rather than an assertion
that readiness is constant.
Observable completion
Run compiles and follows the intended state sequence: fill stores the supplied
byte, start makes the consumer active, and consume later commits that byte to
resultReg while setting doneReg. show observes the same byte only after
done becomes true. If start occurred with an empty queue, consume would
wait instead of reading invalid data; that empty-state behavior is part of
completion.
Progressive hints
Hint 1: partition the conditions
active is visible in the rule header. Readiness inherited from called methods
is a different category even when it does not appear as source syntax there.
Hint 2: find the contradiction
Focus on the annotation immediately before consume. Compare what it promises
with the empty-state contracts of both queue.first and queue.deq.
Hint 3: keep the inferred guard
The correct schedule needs the compiler-generated queue condition. Remove the claim that forbids such conditions rather than changing the explicit rule predicate or queue operations.
Transfer experiment
After completing the repair, temporarily reorder the top-level sequence so
start happens before fill. Predict which rule waits, which implicit
condition changes after enqueue, and why no invalid dequeue occurs. Revert the
sequence before submitting; it is not graded.