-
Notifications
You must be signed in to change notification settings - Fork 7
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix improper handling of post with a reference to storage
This commit fixes a bug where storage variables were dereferenced with respect to the state of the `ConstraintsState` `Storage` mapping *after* the function being spec-ed had been processed, and in particular, taking into account any `.write()` calls within the function body. The expected behavior is that references to storage variables within postconditions refer to the state of the storage variable immediately prior to the call of the function being specified. In simple terms, the value of a storage variable in an annotation is always the value *before* any storage writes in the current function. The 'exception' is the LHS of `@storage_update` annotations themselves, but this is more of an assignment than a reference. * Remove unnecessary checks for accessing storage in plain specs. Basically, before, it looks as though we didn't allow storage reads within plain specs, which is wrong. After all, a plain spec is more-or-less defined to be a spec for a function without a 'write'. * Change readStorage to allow for manual override of the point in time in which one reads from a storage variable. Implementation-wise, we allow you to pass a value of type `Storage` to read with respect to. * Use the new `readStorage` in mkCallConstraints` to make sure that when you refer to a storage variable in a postcondition, you are referring to its state prior to the function being called. Other minor changes: * Add docstrings for: - `encodeRichSpec` - `encodePlainSpec` - `storageRemoval'` - `mkInstructionConstraints` * Add a test for the above bug: `post_with_svar.cairo` * Format sources with `fourmolu`
- Loading branch information
Showing
4 changed files
with
101 additions
and
15 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
%lang starknet | ||
from starkware.cairo.common.cairo_builtins import HashBuiltin | ||
|
||
// This example tests that when we reference a storage variable in a | ||
// postcondition, as we do in the `@post` for both `frob1()` and `frobenius()` | ||
// below, the state we are referencing is the state of the storage variable | ||
// immediately prior to the function call. In particular, this is the state | ||
// before any storage variable `.write()`s contained in the function whose | ||
// specification we're writing 'take effect'. | ||
|
||
@storage_var | ||
func state() -> (res: felt) { | ||
} | ||
|
||
// @storage_update state() := state() + x | ||
// @post $Return.res == state() + x | ||
func frob1{ | ||
syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr | ||
}(x: felt) -> (res: felt) { | ||
let (old) = state.read(); | ||
let res = old + x; | ||
state.write(res); | ||
return (res=res,); | ||
} | ||
|
||
// @storage_update state() := state() + y | ||
// @post $Return.r == state() + y | ||
func frobenius{ | ||
syscall_ptr: felt*, pedersen_ptr: HashBuiltin*, range_check_ptr | ||
}(y: felt) -> (r: felt) { | ||
let (temp) = frob1(y); | ||
return (r=temp,); | ||
} |
This file contains 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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
frob1 | ||
Verified | ||
|
||
frobenius | ||
Verified |