Skip to content
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

Move fixedpointmath macro logic to utils #164

Merged
merged 3 commits into from
Jul 6, 2024
Merged

Conversation

ryangoree
Copy link
Member

@ryangoree ryangoree commented Jul 6, 2024

Description

This moves the logic of parsing strings into u256 and i256 types into util functions so that they can be re-used with normal strings. This will be useful when wrapping in WASM.

Review Checklists

Please check each item before approving the pull request. While going
through the checklist, it is recommended to leave comments on items that are
referenced in the checklist to make sure that they are reviewed.

  • Testing
    • Are there new or updated unit or integration tests?
    • Do the tests cover the happy paths?
    • Do the tests cover the unhappy paths?
    • Are there an adequate number of fuzz tests to ensure that we are
      covering the full input space?
    • If matching Solidity behavior, are there differential fuzz tests that
      ensure that Rust matches Solidity?

@ryangoree ryangoree enabled auto-merge (squash) July 6, 2024 02:34
@ryangoree ryangoree merged commit 6e1f10a into main Jul 6, 2024
8 checks passed
@ryangoree ryangoree deleted the ryan-fixed-point-utils branch July 6, 2024 02:48
ryangoree added a commit that referenced this pull request Jul 6, 2024
# Description

Patches the version to publish the change from #164 and adds concurrency
config to more workflows.

# Review Checklists

Please check each item **before approving** the pull request. While
going
through the checklist, it is recommended to leave comments on items that
are
referenced in the checklist to make sure that they are reviewed.

- [ ] **Testing**
    - [ ] Are there new or updated unit or integration tests?
    - [ ] Do the tests cover the happy paths?
    - [ ] Do the tests cover the unhappy paths?
- [ ] Are there an adequate number of fuzz tests to ensure that we are
          covering the full input space?
- [ ] If matching Solidity behavior, are there differential fuzz tests
that
          ensure that Rust matches Solidity?
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.

2 participants