Skip to content

Conversation

@mvadari
Copy link
Collaborator

@mvadari mvadari commented Dec 10, 2025

High Level Overview of Change

Context of Change

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (non-breaking change that only restructures code)
  • Performance (increase or change in throughput and/or latency)
  • Tests (you added tests for code that already exists, or your new feature included in this PR)
  • Documentation update
  • Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
  • Release

API Impact

  • Public API: New feature (new methods and/or new fields)
  • Public API: Breaking change (in general, breaking changes should only impact the next api_version)
  • libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
  • Peer protocol change (must be backward compatible or bump the peer protocol version)

@codecov
Copy link

codecov bot commented Dec 10, 2025

Codecov Report

❌ Patch coverage is 82.35294% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.6%. Comparing base (843e981) to head (0d7d0de).

Files with missing lines Patch % Lines
src/xrpld/app/wasm/detail/HostFuncImpl.cpp 82.4% 6 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@                      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     
Files with missing lines Coverage Δ
src/xrpld/app/wasm/detail/HostFuncImpl.cpp 99.0% <82.4%> (-1.0%) ⬇️

... and 5 files with indirect coverage changes

Impacted file tree graph

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@pwang200
Copy link
Collaborator

Look good to me, but Olek should take a look.

Copy link

Copilot AI left a 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_VECTOR256 as 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.

Comment on lines +687 to +689
// Locator for STVector256
expectError(
{sfCredentialIDs.fieldCode}, HostFunctionError::NOT_LEAF_FIELD);
Copy link

Copilot AI Jan 5, 2026

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.

Copilot uses AI. Check for mistakes.
Copy link
Collaborator

@oleks-rip oleks-rip left a 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)
Copy link
Collaborator

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

@mvadari mvadari requested a review from oleks-rip January 6, 2026 20:21
@oleks-rip
Copy link
Collaborator

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

testcase("getTxField");
using namespace test::jtx;

static std::string const credIdHex =
Copy link
Collaborator

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not?

Copy link
Collaborator

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

Env env{*this};
OpenView ov{*env.current()};

static std::string const credIdHex =
Copy link
Collaborator

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*>(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return STBaseOrUInt256(&(v->operator))

}

return field;
return std::variant<STBase const*, uint256 const*>(field);
Copy link
Collaborator

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();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

auto const &

@mvadari mvadari requested a review from oleks-rip January 7, 2026 21:49
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.

3 participants