-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add Vector256 support to the locator
#6131
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: ripple/wasmi-host-functions
Are you sure you want to change the base?
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## ripple/wasmi-host-functions #6131 +/- ##
=============================================================
- Coverage 79.6% 79.6% -0.0%
=============================================================
Files 845 845
Lines 73317 73323 +6
Branches 8354 8360 +6
=============================================================
- Hits 58379 58373 -6
- Misses 14938 14950 +12
🚀 New features to boost your workflow:
|
|
Look good to me, but Olek should take a look. |
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.
Pull request overview
This PR extends the locator functionality in the WASM host functions to support STI_VECTOR256 type fields, enabling WASM smart contracts to access and navigate Vector256 fields (such as CredentialIDs) in transactions and ledger objects.
Key changes:
- Added
STI_VECTOR256as a non-leaf field type that can be indexed like arrays - Implemented Vector256 element access through the locator with proper index bounds checking
- Extended array length functions to support Vector256 fields
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/xrpld/app/wasm/detail/HostFuncImpl.cpp | Adds Vector256 support to getAnyFieldData, locateField, and array length functions; implements indexing into Vector256 fields using a thread_local temporary STUInt256 wrapper |
| src/test/app/HostFuncImpl_test.cpp | Adds comprehensive tests for Vector256 field access, including tests for retrieving Vector256 elements via locator, bounds checking, and error handling for non-leaf field access |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Locator for STVector256 | ||
| expectError( | ||
| {sfCredentialIDs.fieldCode}, HostFunctionError::NOT_LEAF_FIELD); |
Copilot
AI
Jan 5, 2026
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.
Consider adding a test case for attempting to nest further into a Vector256 element, similar to the test at lines 691-696 for nesting into non-array/object fields. For example, test a locator like {sfCredentialIDs.fieldCode, 0, sfAccount.fieldCode} which should return LOCATOR_MALFORMED since uint256 values (the elements of Vector256) are leaf nodes and cannot be nested into. This would verify that the Vector256 indexing correctly returns a leaf type that cannot be further navigated.
oleks-rip
left a comment
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.
Please put 319-324 into helper function, and use it in other places
| if (field->getSType() != STI_ARRAY) | ||
| return Unexpected(HostFunctionError::NO_ARRAY); // LCOV_EXCL_LINE | ||
| int32_t const sz = static_cast<STArray const*>(field)->size(); | ||
| if (field->getSType() == STI_VECTOR256) |
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.
Please put 319-324 into helper function, and use it in other places
|
I have concern about static variable, if someone later will call that function 2 times it will overwrite the value without any notice. Try this variants.patch patch with variants instead |
src/test/app/HostFuncImpl_test.cpp
Outdated
| testcase("getTxField"); | ||
| using namespace test::jtx; | ||
|
|
||
| static std::string const credIdHex = |
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.
You don't need static here and below
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.
Why not?
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.
I don't see a reason why you need it. All the functions that require it are in the same scope and in the same thread, so credIdHex doesn't need life prolongation, like other variables
src/test/app/HostFuncImpl_test.cpp
Outdated
| Env env{*this}; | ||
| OpenView ov{*env.current()}; | ||
|
|
||
| static std::string const credIdHex = |
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.
You don't need static here
| static thread_local STUInt256 tempUInt256; | ||
| tempUInt256 = STUInt256(v->operator[](sfieldCode)); | ||
| field = &tempUInt256; | ||
| return std::variant<STBase const*, uint256 const*>( |
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.
| } | ||
|
|
||
| return field; | ||
| return std::variant<STBase const*, uint256 const*>(field); |
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.
return STBaseOrUInt256(field)
| return Unexpected(r.error()); | ||
|
|
||
| auto const* field = r.value(); | ||
| auto const field = r.value(); |
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.
auto const &
High Level Overview of Change
Context of Change
Type of Change
.gitignore, formatting, dropping support for older tooling)API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)