ca331d2dba
Upstream rewrote the wasm VM and host-function system (Rust `crates/` bridged via cxx), collapsed `transactions.macro` onto `TxSettings`, and moved invariant running from `ApplyContext` to `Transactor`. This merge resolves those conflicts and the breaks that carried no conflict marker. Conflict resolutions of note: - transactions.macro: took upstream's 5-argument `TxSettings` form and re-expressed our `emitable` column as `TxSettings::emittance`, a new scoped `Emittance` enum in TxSettings.h. `Emitable.cpp` and the transaction code generator read the new member. - sfields.macro: upstream claimed UINT32 75-80, so `sfParameterFlag` moves from 80 to 86. The amendment is not live, so no wire break. - HostFunc.h: took upstream's version, which drops `floatRoot`, and re-added the 15 contract virtuals. `setDataNestedObjectField`'s parameters are renamed to `(account, key, nestedKey, value)` to match the implementation; the wire order is unchanged. - WasmCommon.h: `SubmitTxnFailure` (-21) and `InvalidState` (-22) join upstream's enum and the Rust `host_errors!` table. `Success` is gone; the helpers that compared against it now return `expected<void, ...>`. - Transactor.cpp: kept the emitted-transaction pass, now using `checkInvariants(result, fee, InvariantScope::ProtocolOnly)`. Breaks with no conflict marker: - `Emitable.cpp` used the 8-argument TRANSACTION macro. - `STTx::getSeqValue` is gone; use `getSeqProxy().value()`. - `NetworkOPsImp::subLock_` is now `streamLock_`, held with `scoped_lock`. - The `LedgerEntryHelpers` namespace is now `ledger_entry_helpers`. - `keylet::vault` takes a `SeqProxy`. The three contract `ledger_entry` parsers were copy-pasted from the vault one and returned vault keylets; they now build contract, contract source and contract data keylets from their own fields. `contract_hash` is added to jss. The 15 contract host functions still register through the deleted C++ wrapper layer, so contract bytecode does not run yet. Porting them to the Rust-declared ABI is the next commit.
Protocol Autogen
This directory contains auto-generated C++ wrapper classes for XRP Ledger protocol types.
Generated Files
The files in this directory are generated from macro definition files:
- Transaction classes (in
transactions/): Generated frominclude/xrpl/protocol/detail/transactions.macrobycmake/scripts/codegen/generate_tx_classes.py - Ledger entry classes (in
ledger_entries/): Generated frominclude/xrpl/protocol/detail/ledger_entries.macrobycmake/scripts/codegen/generate_ledger_classes.py
Generation Process
Generation requires a one-time setup step to create a virtual environment and install Python dependencies, followed by running the generation target:
cmake --build . --target setup_code_gen # create venv and install dependencies (once)
cmake --build . --target code_gen # generate code
By default, CODEGEN_VENV_DIR points to .venv in the project root. The
setup_code_gen target creates a venv there and installs the required packages.
The code_gen target then uses the venv's Python interpreter to run generation.
Generation is pure Python, so the same targets are also available as a standalone project that needs neither the dependencies nor a compiler. This is what CI uses, and it is handy if you only want to regenerate these files:
cmake -S cmake/codegen -B build/codegen
cmake --build build/codegen --target setup_code_gen
cmake --build build/codegen --target code_gen
Python Dependencies
The code generation requires the following Python packages (installed by setup_code_gen):
pcpp- C preprocessor for Pythonpyparsing- Parser combinator libraryMako- Template engine
Version Control
The generated .h files are checked into version control. This means:
- Developers without Python 3 can still build the project using the committed files
- CI/CD systems don't need to run code generation if files are up to date
- Changes to generated files are visible in code review
Modifying Generated Code
Do not manually edit generated files. Any changes will be overwritten the next time code_gen is run.
To modify the generated classes:
- Edit the macro files in
include/xrpl/protocol/detail/ - Edit the Mako templates in
cmake/scripts/codegen/templates/ - Edit the generation scripts in
cmake/scripts/codegen/ - Update Python dependencies in
cmake/scripts/codegen/requirements.txt - Run
cmake --build . --target code_gento regenerate
Adding Common Fields
If you add a new common field to TxFormats.cpp or LedgerFormats.cpp, you should also update the corresponding base classes and templates manually:
Base classes:
TransactionBase.h- Add getters for new common transaction fieldsTransactionBuilderBase.h- Add setters, and if the field is required, add it to the constructor parametersLedgerEntryBase.h- Add getters for new common ledger entry fieldsLedgerEntryBuilderBase.h- Add setters, and if the field is required, add it to the constructor parameters
Templates (update to pass required common fields to base class constructors):
cmake/scripts/codegen/templates/Transaction.h.makocmake/scripts/codegen/templates/LedgerEntry.h.mako
These files are not auto-generated and must be updated by hand.