-
Notifications
You must be signed in to change notification settings - Fork 706
[Clarity-4] Implement contract post-conditions #6516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
9a75478
to
e02ca38
Compare
In implementing this, I'm wondering if it might be better to make a small change to the (with-nft contract-id:principal token-name:(string-ascii 128 identifier:T) I'm wondering if it makes more sense to change that to allow a list of identifiers: (with-nft contract-id:principal token-name:(string-ascii 128 identifier:(list T 128)) This would allow the list to be built within the code and then passed to a single allowance expression for each NFT. |
efeeab5
to
b922ae9
Compare
This just adds the basic support for the syntax and some setup for the full implementation.
663c1e9
to
b450cd1
Compare
That infrastructure is not setup for handling PoX state, and the stacking tracking in the asset maps is not setup yet any way.
Remaining work is to handle the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Mainly I see that you have some unwritten integration test TODOs, but otherwise everything looks really well tested.
clarity/src/vm/analysis/type_checker/v2_1/natives/post_conditions.rs
Outdated
Show resolved
Hide resolved
Thanks @hstove! I actually forgot about those TODOs I had at the bottom. The remaining tests I planned to add were:
Do you see any others that should get added? |
We decided to remove this because it doesn't really make sense.
@hstove TODOs resolved, additional tests added, and merge conflicts resolved. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, just have a few comments
This replaces a `HashSet<String>` which was using the serialized value for quick lookups, but added the extra overhead on setup and use of serializing the values. With this new design, the value is used directly, with no new allocations, and then a linear search is required through the `Vec`, but in the common case, the number of entries will be very low.
This is necessary because the costs-4 contract was updated. I verified that the consensus tests passed if I removed the new functions in that contract.
The consensus tests fail because this branch adds new functions into costs-4.clar, so it should be consensus-breaking. I validated that if I removed those new functions, the chainstate matched. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Implements contract post-conditions as described in #6396 and SIP PR stacksgov/sips#218.