Compare commits

...

220 Commits

Author SHA1 Message Date
Denis Angell
38850e1180 add skills 2026-02-27 23:42:16 +01:00
Denis Angell
b418b416b0 add claude 2026-02-06 19:31:07 +01:00
Ayaz Salikhov
2305bc98a4 chore: Remove CODEOWNERS (#6337) 2026-02-06 11:39:23 -05:00
Bart
677758b1cc perf: Remove unnecessary caches (#5439)
This change removes the cache in `DatabaseNodeImp` and simplifies the caching logic in `SHAMapStoreImp`. As NuDB and RocksDB internally already use caches, additional caches in the code are not very valuable or may even be unnecessary, as also confirmed during preliminary performance analyses.
2026-02-06 09:42:35 -05:00
Bart
25d7c2c4ec chore: Restore unity builds (#6328)
In certain cases, such as when modifying headers used by many compilation units, performing a unity build is slower than when performing a regular build with `ccache` enabled. There is also a benefit to a unity build in that it can detect things such as macro redefinitions within the group of files that are compiled together as a unit. This change therefore restores the ability to perform unity builds. However, instead of running every configuration with and without unity enabled, it is now only enabled for a single configuration to maintain lower computational use.

As part of restoring the code, it became clear that currently two configurations have coverage enabled, since the check doesn't focus specifically on Debian Bookworm so it also applies to Debian Trixie. This has been fixed too in this change.
2026-02-06 14:12:45 +00:00
Bart
0a626d95f4 refactor: Update secp256k1 to 0.7.1 (#6331)
The latest secp256k1 release, 0.7.1, contains bug fixes that we may benefit from, see https://github.com/bitcoin-core/secp256k1/blob/master/CHANGELOG.md.
2026-02-05 16:45:57 +00:00
Niq Dudfield
6006c281e2 fix: Increment sequence when accepting new manifests (#6059)
The `ManifestCache::applyManifest` function was returning early without incrementing `seq_`. `OverlayImpl `uses this sequence to identify/invalidate a cached `TMManifests` message, which is exchanged with peers on connection. Depending on network size, startup sequencing, and topology, this can cause syncing issues. This change therefore increments `seq_` when a new manifest is accepted.
2026-02-05 10:40:27 -05:00
Vito Tumas
e79673cf40 fix typo in LendingHelpers unit-test (#6215) 2026-02-05 10:23:44 +00:00
Ayaz Salikhov
7f41012e59 chore: Update secp256k1 and openssl (#6327) 2026-02-04 18:27:10 +00:00
Bart
b449a6ee84 chore: Remove unnecessary script (#6326) 2026-02-04 11:30:16 -05:00
Bart
34ef577604 refactor: Replace include guards by '#pragma once' (#6322)
This change replaces all include guards in the `src/` and `include/` directories by `#pragma once`.
2026-02-04 09:50:21 -05:00
Bart
3a172301ce chore: Remove unity builds (#6300)
Unity builds were intended to speed up builds, by bundling multiple files into compilation units. However, now that ccache is available on all platforms, there is no need for unity builds anymore, as ccache stores compiled individual build objects for reuse. This change therefore removes the ability to make unity builds.
2026-02-03 22:55:22 +00:00
Jingchen
6c1a92fe93 refactor: Add ServiceRegistry to help modularization (#6222)
Currently we're passing the `Application` object around, whereby the `Application` class acts more like a service registry that gives other classes access to other services. In order to allow modularization, we should replace `Application` with a service registry class so that modules depending on `Application` for other services can be moved easily. This change adds the `ServiceRegistry` class.
2026-02-03 19:08:27 +00:00
Copilot
7813683091 fix: Deletes expired NFToken offers from ledger (#5707)
This change introduces the `fixExpiredNFTokenOfferRemoval` amendment that allows expired offers to pass through `preclaim()` and be deleted in `doApply()`, following the same pattern used for expired credentials.
2026-02-03 16:37:24 +00:00
Vito Tumas
b814a09a08 chore: Add .zed editor config directory to .gitignore (#6317)
This change adds the project configuration directory to `.gitignore` for the `zed` editor. 

As per the [documentation](https://zed.dev/docs/remote-development?highlight=.zed#zed-settings), the project configuration files are stored in the `.zed` directory at the project root dir.
2026-02-03 10:13:10 -05:00
Mayukha Vadari
6d369e0f02 docs: Update API changelog, add APIv2+APIv3 version documentation (#6308)
This change cleans up the `API-CHANGELOG.md` file. It moves the version-specific documentation to other files and fleshes out the changelog with all the API-related changes in each version.
2026-02-03 02:12:26 +00:00
Bart
b182430178 fix: Restore config changes that broke standalone mode (#6301)
When support was added for `xrpld.cfg` in addition to `rippled.cfg` in https://github.com/XRPLF/rippled/pull/6098, as part of an effort to rename occurrences of ripple(d) to xrpl(d), the clearing and creation of the data directory were modified for what, at the time, seemed to result in an equivalent code flow. This has turned out to not be true, which is why this change restores two modifications to `Config.cpp` that currently break running the binary in standalone mode.
2026-02-03 01:15:56 +00:00
Ed Hennis
fe31cdc9f6 chore: Add upper-case match for ARM64 in CompilationEnv (#6315) 2026-02-02 23:57:10 +00:00
Ayaz Salikhov
ff4520cc45 ci: Update hashes of XRPLF/actions (#6316)
This updates the hashes of all XRPLF/actions to their latest versions.
2026-02-02 19:37:06 +00:00
Ayaz Salikhov
fe9c8d568f chore: Format all cmake files without comments (#6294) 2026-01-29 18:19:32 +00:00
Ayaz Salikhov
a0e09187b9 chore: Add cmake-format pre-commit hook (#6279)
This change adds `cmake-format` as. a pre-commit hook. The style file closely matches that in Clio, and they will be made to be equivalent over time. For now, some files have been excluded, as those need some manual adjustments, which will be done in future changes.
2026-01-29 13:33:24 +00:00
Ayaz Salikhov
f3627fb5d5 chore: Remove unnecessary boost::system requirement from conanfile (#6290) 2026-01-28 19:14:31 +00:00
Ayaz Salikhov
5f638f5553 chore: Set ColumnLimit to 120 in clang-format (#6288)
This change updates the ColumnLimit from 80 to 120, and applies clang-format to reformat the code.
2026-01-28 18:09:50 +00:00
Jingchen
92046785d1 test: Fix the xrpl.net unit test using async read (#6241)
This change makes the `read` function call in `handleConnection` async, adds a new class `TestSink` to help debugging, and adds a new target `xrpl.tests.helpers` to put the helper class in.
2026-01-28 15:14:35 +00:00
Bart
b90a843ddd ci: Upload Conan recipes for develop, release candidates, and releases (#6286)
To allow developers to consume the latest unstable and (near-)stable versions of our `xrpl` Conan recipe, we should export and upload it whenever a push occurs to the corresponding branch or a release tag has been created. This way, developers do not have to figure out themselves what the most recent shortened commit hash was to determine the latest unstable recipe version (e.g. `3.2.0-b0+a1b2c3d`) or what the most recent release (candidate) was to determine the latest (near-)stable recipe version (e.g. `3.1.0-rc2`).

Now, pushes to the `develop` branch will produce the `develop` recipe version, pushes to the `release` branch will produce the `rc` recipe version, and creation of versioned tags will produce the `release` recipe version.
2026-01-28 10:02:34 +00:00
Jingchen
bb529d0317 fix: Stop embedded tests from hanging on ARM by using atomic_flag (#6248)
This change replaces the mutex `stoppingMutex_`, the `atomic_bool` variable `isTimeToStop`, and the conditional variable `stoppingCondition_` with an `atomic_flag` variable.

When `xrpld` is running the embedded tests as a child process, it has a control thread (the app bundle thread) that starts the application, and an application thread (the thread that executes `app_->run()`). Due to the relaxed memory ordering on ARM, it's not guaranteed that the application thread can see the change of the value resulting from the `isTimeToStop.exchange(true)` call before it is notified by `stoppingCondition_.notify_all()`, even though they do happen in the right order in the app bundle thread in `ApplicationImp::signalStop`. We therefore often get into the situation where `isTimeToStop` is `true`, but the application thread is waiting for `stoppingCondition_` to notify, because the app bundle thread may have already notified before the application thread actually starts waiting.

Switching to a single `atomic_flag` variable makes sure that there's only one synchronisation object and then the memory order guarantee provided by c++ can make sure that `notify_all` gets synchronised after `test_and_set` does.

Fixing this issue will stop the unit tests hanging forever and then we should see less (or hopefully no) time out errors in daily github action runs
2026-01-26 21:39:28 +00:00
Ed Hennis
a2f1973574 fix: Remove DEFAULT fields that change to the default in associateAsset (#6259) (#6273)
- Add Vault creation tests for showing valid range for AssetsMaximum
2026-01-26 19:58:12 +00:00
Bart
847e875635 refactor: Update Boost to 1.90 (#6280)
Upcoming feature work requires functionality present in a newer Boost version. These newer versions also have improvements for sanitizers.
2026-01-26 18:54:43 +00:00
Mayukha Vadari
778da954b4 refactor: clean up uses of std::source_location (#6272)
Since the minimum Clang version we support is 16, the checks for version < 15 are no longer necessary. This change therefore removes the macros checking if the clang version is < 15 and simplifies uses of `std::source_location`.
2026-01-23 14:09:00 -05:00
Bart
0586b5678e ci: Pass missing sanitizers input to actions (#6266)
The `upload-conan-deps` workflow that's triggered on push is supposed to upload the Conan dependencies to our remote, so future PR commits can pull those dependencies from the remote. However, as the `sanitize` argument is missing, it was building different dependencies than what the PRs are building for the asan/tsan/ubsan job, so the latter would not find anything in the remote that they could use. This change sets the missing `sanitizers` input variable when running the `build-deps` action. 

Separately, the `setup-conan` action showed the default profile, while we are using the `ci` profile. To ensure the profile is correctly printed when sanitizers are enabled, the environment variable the profile uses is set before calling the action.
2026-01-23 06:40:55 -05:00
Bart
66158d786f ci: Properly propagate Conan credentials (#6265)
The export and upload steps were initially in a separate action, where GitHub Actions does not support the `secrets` keyword, but only `inputs` for the credentials. After they were moved to a reusable workflow, only part of the references to the credentials were updated. This change correctly references to the Conan credentials via `secrets` instead of `inputs`.
2026-01-22 16:05:15 -05:00
Bart
c57ffdbcb8 ci: Explicitly set version when exporting the Conan recipe (#6264)
By default the Conan recipe extracts the version from `BuildInfo.cpp`, but in some of the cases we want to upload a recipe with a suffix derived from the commit hash. This currently then results in the uploading to fail, since there is a version mismatch.

Here we explicitly set the version, and then simplify the steps in the upload workflow since we now need the recipe name (embedded within the conanfile.py but also needed when uploading), the recipe version, and the recipe ref (name/version).
2026-01-22 19:05:59 +00:00
Bart
4e3f953fc4 ci: Use plus instead of hyphen for Conan recipe version suffix (#6261)
Conan recipes use semantic versioning, and since our version already contains a hyphen the second hyphen causes Conan to ignore it. The plus sign is a valid separator we can use instead, so this change uses a `+` to separate a version suffix (commit hash) instead of a `-`.
2026-01-22 16:42:53 +00:00
Pratik Mankawde
a4f8aa623f chore: Detect uninitialized variables in CMake files (#6247)
There were a few uninitialized variables in CMake files. This change will make sure we always check if a variable has been initialized before using them, or in come cases initialize them by default. This change will raise an error on CI if a developer introduced an uninitialized variable in CMake files.
2026-01-22 11:16:18 -05:00
Bart
8695313565 ci: Run on-trigger and on-pr when generate-version is modified (#6257)
This change ensures that the `on-pr` and `on-trigger` workflows run when the generate-version action is modified.
2026-01-22 13:48:50 +00:00
Valentin Balaschenko
68c9d5ca0f refactor: Enforce 15-char limit and simplify labels for thread naming (#6212)
This change continues the thread naming work from #5691 and #5758, which enables more useful lock contention profiling by ensuring threads/jobs have short, stable, human-readable names (rather than being truncated/failing due to OS limits). This changes diagnostic naming only (thread names and job/load-event labels), not behavior.

Specific modifications are:
* Shortens all thread/job names used with `beast::setCurrentThreadName`, so the effective Linux thread name stays within the 15-character limit.
* Removes per-ledger sequence numbers from job/thread names to avoid long labels. This improves aggregation in lock contention profiling for short-lived job executions.
2026-01-22 08:19:29 -05:00
David Fuelling
211054baff docs: Update Ripple Bug Bounty public key (#6258)
The Ripple Bug Bounty program recently changed the public keys that security researchers can use to encrypt vulnerabilities and messages for submission to the program. This information was updated on https://ripple.com/legal/bug-bounty/ and this PR updates the `SECURITY.md` to align.
2026-01-21 19:55:56 -05:00
Bart
4fd4e93b3e ci: Add missing commit hash to Conan recipe version (#6256)
During several iterations of development of https://github.com/XRPLF/rippled/pull/6235, the commit hash was supposed to be moved into the `run:` statement, but it slipped through the cracks and did not get added. This change adds the commit hash as suffix to the Conan recipe version.
2026-01-21 19:17:05 -05:00
Ayaz Salikhov
4cd6cc3e01 fix: Include <functional> header in Number.h (#6254)
The `Number.h` header file now has `std::reference_wrapper` from `<functional>`, but the include is missing, causing downstream build problems. This change adds the header.
2026-01-21 18:52:22 -05:00
Bart
a37c556079 ci: Upload Conan recipe for merges into develop and commits to release (#6235)
This change uploads the `libxrpl` library as a Conan recipe to our remote when (i) merging into the `develop` branch, (ii) committing to a PR that targets a `release*` branch, and (iii) a versioned tag is applied. Clio is only notified in the second case. The user and channel are no longer used when uploading the recipe.

Specific changes are:
* A `generate-version` action is added, which extracts the build version from `BuildInfo.cpp` and appends the short 7-character commit hash to it for merges into the `develop` branch and for commits to a PR that targets a `release*` branch. When a tag is applied, however, the tag itself is used as the version. This functionality has been turned into a separate action as we will use the same versioning logic for creating .rpm and .deb packages, as well as Docker images.
* An `upload-recipe` action is added, which calls the `generate-version` action and further handles the uploading of the recipe to Conan.
* This action is called by both the `on-pr` and `on-trigger` workflows, and a new `on-tag` workflow.

The reason for this change is that we have downstream uses for the `libxrpl` library, but currently only upload the recipe to check for compatibility with Clio when making commits to a PR that targets the release branch.
2026-01-21 17:31:44 -05:00
Pratik Mankawde
5e808794d8 Limit reply size on TMGetObjectByHash queries (#6110)
`PeerImp` processes `TMGetObjectByHash` queries with an unbounded per-request loop, which performs a `NodeStore` fetch and then appends retrieved data to the reply for each queried object without a local count cap or reply-byte budget. However, the `Nodestore` fetches are expensive when high in numbers, which might slow down the process overall. Hence this code change adds an upper cap on the response size.
2026-01-21 09:19:53 -05:00
Bart
12c0d67ff6 ci: remove 'master' branch as a trigger (#6234)
This change removes the `master` branch as a trigger for the CI pipelines, and updates comments accordingly. It also fixes the pre-commit workflow, so it will run on all release branches.
2026-01-16 15:01:53 -05:00
Ed Hennis
00d3cee6cc Improve ledger_entry lookups for fee, amendments, NUNL, and hashes (#5644)
These "fixed location" objects can be found in multiple ways:

1. The lookup parameters use the same format as other ledger objects, but the only valid value is true or the valid index of the object: 
  - Amendments: "amendments" : true
  - FeeSettings: "fee" : true
  - NegativeUNL: "nunl" : true
  - LedgerHashes: "hashes" : true (For the "short" list. See below.)

2. With RPC API >= 3, using special case values to "index", such as "index" : "amendments". Uses the same names as above. Note that for "hashes", this option will only return the recent ledger hashes / "short" skip list.

3. LedgerHashes has two types: "short", which stores recent ledger hashes, and "long", which stores the flag ledger hashes for a particular ledger range.
  - To find a "long" LedgerHashes object, request '"hashes" : <ledger sequence>'. <ledger sequence> must be a number that evaluates to an unsigned integer.
  - To find the "short" LedgerHashes object, request "hashes": true as with the other fixed objects.

The following queries are all functionally equivalent:

  - "amendments" : true
  - "index" : "amendments" (API >=3 only)
  - "amendments" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4"
  - "index" : "7DB0788C020F02780A673DC74757F23823FA3014C1866E72CC4CD8B226CD6EF4"

Finally, whether the object is found or not, if a valid index is computed, that index will be returned. This can be used to confirm the query was valid, or to save the index for future use.
2026-01-16 12:26:30 -05:00
Pratik Mankawde
96d17b7f66 ci: Add sanitizers to CI builds (#5996)
This change adds support for sanitizer build options in CI builds workflow. Currently `asan+ubsan` is enabled, while `tsan+ubsan` is left disabled as more changes are required.
2026-01-15 16:18:14 +00:00
Ayaz Salikhov
ec44347ffc test: Use gtest instead of doctest (#6216)
This change switches over the doctest framework to the gtest framework.
2026-01-15 08:36:13 -05:00
Ed Hennis
c9458b72ca test: Suppress "parse failed" message in Batch tests (#6207) 2026-01-14 23:45:00 +00:00
Mayukha Vadari
ebcfd6645d test: Replace failed string in Vault test case (#6214)
The word `failed` in the test case makes it hard to search through the test logs when an actual test failure occurs, so this change renames the word to just `fail` instead.
2026-01-14 14:40:07 -05:00
Ed Hennis
efa57e872b Change LendingProtocol feature and dependencies to supported (#6146) 2026-01-13 21:53:40 +00:00
Ed Hennis
33f4c92b61 Expand Number to support the full integer range (#6025)
- Refactor Number internals away from int64 to uint64 & a sign flag
  - ctors and accessors use `rep`. Very few things expose
    `internalrep`.
  - An exception is "unchecked" and the new "normalized", which explicitly
    take an internalrep. But with those special control flags, it's easier
    to distinguish and control when they are used.

- For now, skip the larger mantissas in AMM transactions and tests

- Remove trailing zeros from scientific notation Number strings
  - Update tests. This has the happy side effect of making some of the string
    representations _more_ consistent between the small and large
    mantissa ranges.

- Add semi-automatic rounding of STNumbers based on Asset types
  - Create a new SField metadata enum, sMD_NeedsAsset, which indicates
    the field should be associated with an Asset so it can be rounded.
  - Add a new STTakesAsset intermediate class to handle the Asset
    association to a derived ST class. Currently only used in STNumber,
    but could be used by other types in the future.
  - Add "associateAsset" which takes an SLE and an Asset, finds the
    sMD_NeedsAsset fields, and associates the Asset to them. In the case
    of STNumber, that both stores the Asset, and rounds the value
    immediately.
  - Transactors only need to add a call to associateAsset _after_ all of
    the STNumbers have been set. Unfortunately, the inner workings of
    STObject do not do the association correctly with uninitialized
    fields.
  - When serializing an STNumber that has an Asset, round it before
    serializing.
  - Add an override of roundToAsset, which rounds a Number value in place
    to an Asset, but without any additional scale.
  - Update and fix a bunch of Loan-related tests to accommodate the
    expanded Number class.

---------

Co-authored-by: Vito <5780819+Tapanito@users.noreply.github.com>
2026-01-13 21:01:11 +00:00
Ed Hennis
2601442e16 Improve and fix bugs in Lending Protocol (#6102)
- Spec: XLS-66

    Fix overpayment asserts (#6084)

    MPTTester::operator() parameter should be std::int64_t
    - Originally defined as uint64_t, but the testIssuerLoan() test called
      it with a negative number, causing an overflow to a very large number
      that in some circumstances could be silently cast back to an int64_t,
      but might not be. I believe this is UB, and we don't want to rely on
      that.

    Review feedback from @Tapanito: overpayment value change
    - In overpayment results, the management fee was being calculated twice:
      once as part of the value change, and as part of the fees paid.
      Exclude it from the value change.

    Fix Overpayment Calculation  (#6087)
    - Adds additional unit tests to cover math calculations.
    - Removes unused methods.

    Review feedback from @shawnxie999: even more rounding
    - Round the initial total value computation upward, unless there is
      0-interest.
    - Rename getVaultScale to getAssetsTotalScale, and convert one incorrect
      computation to use it.
    - Use adjustImpreciseNumber for LossUnrealized.
    - Add some logging to computeLoanProperties.

    Fix LoanBrokerSet debtMaximum limits (#6116)

    Fix some minor bugs in Lending Protocol (#6101)
    - add nodiscard to unimpairLoan, and check result in LoanPay
    - add a check to verify that issuer exists
    - improve LoanManage error code for dust amounts

    Check permissions in LoanSet and LoanPay (#6108)

    Disallow pseudo accounts to be Destination for LoanBrokerCoverWithdraw (#6106)

    Ensure vault asset cap is not exceeded (#6124)

    Fix Overpayment ValueChange calculation in Lending Protocol (#6114)
    - Adds loan state to LoanProperties.
    - Cleans up computeLoanProperties.
    - Fixes missing management fee from overpayment.

    fix: Enable LP Deposits when the broker is the asset issuer (#6119)
    * Replace accountHolds with accountSpendable when checking
    for account funds in VaultDeposit and LoanBrokerCoverDeposit

    Add a few minor changes (#6158)
    - Updates or fixes a couple of things I noticed while reviewing changes
      to the spec.
    - Rename sfPreviousPaymentDate to sfPreviousPaymentDueDate.
    - Make the vault asset cap check added in #6124 a little more robust:
      1. Check in preflight if the vault is _already_ over the limit.
      2. Prevent overflow when checking with the loan value. (Subtract
         instead of adding, in case the values are near maxint. Both return
         the same result. Also add a unit test so each case is covered.

    Add minimum grace period validation (#6133)

    Fix bugs: frozen pseudo-account, and FLC cutoff (#6170)

    refactor: Rename raw state to theoretical state (#6187)

    Check if a withdrawal amount exceeds any applicable receiving limit. (#6117)

    Fix overpayment result calculation (#6195)

    Address review feedback from Lending Protocol re-review (#6161)

---------

Co-authored-by: Gregory Tsipenyuk <gregtatcam@users.noreply.github.com>
Co-authored-by: Bronek Kozicki <brok@incorrekt.com>
Co-authored-by: Vito Tumas <5780819+Tapanito@users.noreply.github.com>
Co-authored-by: Shawn Xie <35279399+shawnxie999@users.noreply.github.com>
Co-authored-by: Jingchen <a1q123456@users.noreply.github.com>
2026-01-13 19:42:58 +00:00
Bart
9686604963 fix: Update Conan lock file with changed OpenSSL recipe (#6211)
This change updates the `conan.lock` file with a changed OpenSSL recipe that contains a fix regarding options passed to the compiler
2026-01-13 17:29:04 +00:00
Ayaz Salikhov
0efae5d16e ci: Update actions/images to use cmake 4.2.1 and conan 2.24.0 (#6209) 2026-01-13 11:52:10 -05:00
Bart
4755bb8606 refactor: Remove unnecessary version number and options in cmake find_package (#6169)
This change removes unnecessary version numbers in the OpenSSL and Boost `find_package` CMake statements. An unnecessary OpenSSL definition is removed, while Conan options for SSL are updated to disable insecure ciphers. Moreover, the statements are now ordered alphabetically and more logically.
2026-01-12 19:14:39 -05:00
Bart
92d40de4cb chore: Pin pre-commit hooks to commit hashes (#6205)
This change updates and pins the Black and CSpell pre-commit hooks.
2026-01-12 12:53:46 -05:00
Ed Hennis
b2c5927b48 fix: Inner batch transactions never have valid signatures (#6069)
- Introduces amendment `fixBatchInnerSigs`
- Update Batch unit tests
  - Fix all the Env instantiations to _use_ the "features" parameter.
  - testInnerSubmitRPC runs with Batch enabled and disabled.
  - Add a test to testInnerSubmitRPC for a correctly signed tx incorrectly
    using the tfInnerBatchTxn flag.
  - Generalize the submitAndValidate lambda in testInnerSubmitRPC.
  - With the fix amendment, a transaction never reaches the transaction
    engine (Transactor and derived classes.)
  - Test submitting a pseudo-transaction. Stopped before reaching the
    transaction engine, but with different errors.
- The tests verify that without the amendment, a transaction with
  tfInnerBatchTxn is immediately rejected. Without the amendment, things
  are safe. The amendment just makes things safer and more future-proof.
2026-01-10 03:10:04 +00:00
Bart
7c1183547a chore: Change /Zi to /Z7 for ccache, remove debug symbols in CI (#6198)
As the `/Zi` compiler flag is unsupported by ccache, this change switches it to `/Z7` instead. For CI runs all debug info is omitted.
2026-01-09 21:44:43 +00:00
Vito Tumas
14467fba5e VaultClawback: Burn shares of an empty vault (#6120)
- Adds a mechanism for the vault owner to burn user shares when the vault is stuck. If the Vault has 0 AssetsAvailable and Total, the owner may submit a VaultClawback to reclaim the worthless fees, and thus allow the Vault to be deleted. The Amount must be left off (unless the owner is the asset issuer), specified as 0 Shares, or specified as the number of Shares held.
2026-01-09 14:58:02 -05:00
Zhanibek Bakin
fc00723836 fix: Truncate thread name to 15 chars on Linux (#5758)
This change:
* Truncates thread names if more than 15 chars with `snprintf`.
* Adds warnings for truncated thread names if `-DTRUNCATED_THREAD_NAME_LOGS=ON`.
* Add a static assert for string literals to stop compiling if > 15 chars.
* Shortens `Resource::Manager` to `Resource::Mngr` to fix the static assert failure.
* Updates `CurrentThreadName_test` unit test specifically for Linux to verify truncation.
2026-01-09 13:37:55 -05:00
oncecelll
c24a6041f7 docs: Fix minor spelling issues in comments (#6194) 2026-01-09 13:15:05 -05:00
Bart
e1d97bea12 ci: Use updated prepare-runner in actions and worfklows (#6188)
This change updates the XRPLF pre-commit workflow and prepare-runner action to their latest versions. For naming consistency the prepare-runner action changed the disable_ccache variable into enable_ccache, which matches our naming.
2026-01-08 15:02:59 -05:00
Mayukha Vadari
53aa5ca903 refactor: Fix typos, enable cspell pre-commit (#5719)
This change fixes the last of the spelling issues, and enables the pre-commit (and CI) check for spelling. There are no functionality changes, but it does rename some enum values.
2026-01-08 10:34:49 -05:00
Denis Angell
510c0d82e9 fix: Reorder Batch Preflight Errors (#6176)
This change fixes https://github.com/XRPLF/rippled/issues/6058.
2026-01-08 13:48:39 +00:00
Mayukha Vadari
17565d21d4 refactor: Remove unused credentials signature hash prefix (#6186)
This change removes the unused credentials signature hash prefix from `HashPrefix.h`.
2026-01-08 08:29:59 -05:00
Mayukha Vadari
07ff532d30 refactor: Fix spelling issues in all variables/functions (#6184)
This change fixes many typos in comments, variables, and public functions. There is no functionality change.
2026-01-07 21:30:35 +00:00
Mayukha Vadari
2c37ef7762 refactor: Fix spelling issues in private/local variables and functions (#6182)
This change fixes several typos in private/local variables and private functions. There is no functionality change.
2026-01-07 14:26:14 -05:00
Mayukha Vadari
3c9f5b6252 refactor: Fix typos in comments, configure cspell (#6164)
This change sets up a `cspell `configuration and fixes lots of typos in comments. There are no other code changes.
2026-01-07 12:10:19 -05:00
Bart
f80059e467 ci: Move variable into right place (#6179)
This change moves the `enable_ccache` variable in the `on-trigger.yml` file to the correct location.
2026-01-07 06:07:53 -05:00
Bart
d734c8dddd ci: Use ccache to cache build objects for speeding up building (#6104)
Right now, each pipeline invocation builds the source code from scratch. Although compiled Conan dependencies are cached in a remote server, the source build objects are not. We are able to further speed up our builds by leveraging `ccache`. This change enables caching of build objects using `ccache` on Linux, macOS, and Windows.
2026-01-07 01:34:21 +00:00
Mayukha Vadari
44d21b8f6d test: add more tests for ledger_entry RPC (#5858)
This change adds some basic tests for all the `ledger_entry` helper functions, so each ledger entry type is covered. There are further some minor refactors in `parseAMM` to provide better error messages. Finally, to improve readability, alphabetization was applied in the helper functions.
2026-01-05 10:54:24 -05:00
Bart
3d1b3a49b3 refactor: Rename rippled.cfg to xrpld.cfg (#6098)
This change renames all occurrences of `rippled.cfg` to `xrpld.cfg`. It also provides a script to allow developers to replicate the changes in their local branch or fork to avoid conflicts. For the time being it maintains support for `rippled.cfg` as config file, if `xrpld.cfg` does not exist.
2026-01-05 14:55:12 +00:00
Ayaz Salikhov
0b87a26f04 Revert "chore: Pin ruamel.yaml<0.19 in pre-commit-hooks (#6166)" (#6167)
This reverts commit 0f23ad820c.
2026-01-05 14:01:14 +00:00
Ayaz Salikhov
0f23ad820c chore: Pin ruamel.yaml<0.19 in pre-commit-hooks (#6166)
See https://github.com/pre-commit/pre-commit-hooks/issues/1229 for more details.
2026-01-02 11:53:33 -05:00
Michael Legleux
b7139da4d0 fix: Remove cryptographic libs from libxrpl Conan package (#6163)
* fix: rm crypto libs and fix protobuf path

* update/rm comments
2025-12-23 16:38:35 -08:00
Bart
40198d9792 ci: Remove superfluous build directory creation (#6159)
This change modifies the build directory structure from `build/build/xxx` or `.build/build/xxx` to just `build/xxx`. Namely, the `conanfile.py` has the CMake generators build directory hardcoded to `build/generators`. We may as well leverage the top-level build directory without introducing another layer of directory nesting.
2025-12-22 16:30:23 -05:00
Bart
f059f0beda Set version to 3.2.0-b0 (#6153) 2025-12-17 18:21:01 -05:00
Mayukha Vadari
41c1be2bac refactor: remove Json::Object and related files/classes (#5894)
`Json::Object` and related objects are not used at all, so this change removes `include/xrpl/json/Object.h` and all downstream files. There are a number of minor downstream changes as well.

Full list of deleted classes and functions:
* `Json::Collections`
* `Json::Object`
* `Json::Array`
* `Json::WriterObject`
* `Json::setArray`
* `Json::addObject`
* `Json::appendArray`
* `Json::appendObject`

The last helper function, `copyFrom`, seemed a bit more complex and was actually used in a few places, so it was moved to `LedgerToJson.h` instead of deleting it.
2025-12-15 13:40:08 -05:00
Bart
f816ffa55f ci: Update shared actions (#6147)
The latest update to `cleanup-workspace`, `get-nproc`, and `prepare-runner` moved the action to the repository root directory, and also includes some ccache changes. In response, this change updates the various shared actions to the latest commit hash.
2025-12-12 19:47:34 +00:00
liuyueyangxmu
cf748702af chore: Fix some typos in comments (#6082) 2025-12-12 11:06:17 -05:00
Bart
1eb0fdac65 refactor: Rename ripple namespace to xrpl (#5982)
This change renames all occurrences of `namespace ripple` and `ripple::` to `namespace xrpl` and `xrpl::`, respectively, as well as the names of test suites. It also provides a script to allow developers to replicate the changes in their local branch or fork to avoid conflicts.
2025-12-11 16:51:49 +00:00
Pratik Mankawde
496efb71ca refactor: Move JobQueue and related classes into xrpl.core module (#6121) 2025-12-11 10:30:54 -05:00
Bart
9eb84a561e refactor: Rename rippled binary to xrpld (#5983)
Per [XLS-0095](https://xls.xrpl.org/xls/XLS-0095-rename-rippled-to-xrpld.html), we are taking steps to rename ripple(d) to xrpl(d).

This change modifies the binary name from `rippled` to `xrpld`, and creates a symlink named `rippled` that points to the `xrpld` binary.

Note that https://github.com/XRPLF/rippled/pull/5975 renamed any references to `rippled` in the CMake files and their contents, but explicitly maintained the `rippled` binary name by adding an exception. This change now undoes this exception and adds an explicit symlink instead.
2025-12-11 13:54:23 +00:00
Mayukha Vadari
62efecbfb1 refactor: rename info() to header() (#6138)
This change renames all the `info()` functions to `header()`, since they return `LedgerHeader` structs. It also renames the underlying variables from `info_` to `header_`.
2025-12-10 16:04:37 -05:00
Mayukha Vadari
bff5954acf refactor: rename LedgerInfo to LedgerHeader (#6136)
This PR renames `LedgerInfo` to `LedgerHeader`. Namely, `LedgerInfo` was already an alias for `LedgerHeader`, and the comments next to the alias suggested that it would make sense to rename it, since that makes it clearer what it is.
2025-12-10 19:12:14 +00:00
Mayukha Vadari
42a432c5dc refactor: clean up RPCHelpers (#5684)
This PR cleans up `RPCHelpers.h` and `RPCHelpers.cpp`. It splits out all the fetch-ledger functions to a new set of files, `RPCLedgerHelpers.h`/`RPCLedgerHelpers.cpp`, and moves the general-API functions to `ApiVersion.h`. There is no functionality change.
2025-12-10 18:43:02 +00:00
Bart
4565cc280b chore: Fix docs readme and cmake (#6122)
This change removes the unused `with_docs` option and fixes the README instructions on how to build the `docs` target.
2025-12-08 18:39:38 +00:00
Bart
9625514da8 chore: Clean up .gitignore and .gitattributes (#6001)
The .gitignore and .gitattributes files contain references to files and directories that the current build no longer produces, so this change removes obsolete entries in these files, and does some general reorganizing of the remaining entries.
2025-12-08 12:35:23 -05:00
Bart
a4c60b4160 chore: Use updated secp256k1 recipe (#6118)
This change updates the secp256k1 recipe that defines the SECP256K1_STATIC, so it no longer needs to be defined in the code here. Running the Conan update script also updated two other recipes in the lock file.
2025-12-08 11:27:55 -05:00
Bart
b986395ecc docs: Infer version of Conan dependency to export (#6112)
This change updates a script in the documentation to automatically infer the version of a patched Conan dependency from the conan.lock file.
2025-12-05 11:44:48 -05:00
Bart
020ea3f412 refactor: Update Conan dependencies: protobuf and grpc (#5589)
This PR updates protobuf and grpc to their latest versions. The latest protobuf version no longer requires patches, so we can use it directly from the official Conan Center Index, while the latest grpc still needed a patch, which was added to our own Conan Center Index fork in XRPLF/conan-center-index#8.
2025-12-04 10:34:37 -05:00
Bart
51f1fe5f9a ci: Re-enable linux and macos matrix (#6107)
This change re-enables the Linux and macOS builds that were accidentally disabled in #6089 during testing.
2025-12-04 14:40:00 +00:00
Bart
813bc4d949 refactor: Replaces secp256k1 source by Conan package (#6089)
This change substitutes the secp256k1 source code copy by the Conan recipe added in XRPLF/conan-center-index#24, which updates the version of the library to 0.7.0.
2025-12-04 08:32:45 -05:00
Ed Hennis
6c67f1f525 Implement Lending Protocol (unsupported) (#5270)
- Spec: XLS-66
- Introduces amendment "LendingProtocol", but leaves it UNSUPPORTED to
  allow for standalone testing, future development work, and potential
  bug fixes.
- AccountInfo RPC will indicate the type of pseudo-account when
  appropriate.
- Refactors and improves several existing classes and functional areas,
  including Number, STAmount, STObject, json_value, Asset, directory
  handling, View helper functions, and unit test helpers.
2025-12-02 16:38:17 +00:00
Mayukha Vadari
c9f17dd85d docs: Update CONTRIBUTING.md for XLS submission guidelines (#6065)
This change clarifies the status of XLS in the pull request process.
2025-12-01 12:46:50 -05:00
Bart
b33b506b90 refactor: Replaces ed25519-donna source by Conan package (#6088)
This change substitutes the `ed25519-donna` source code copy by the Conan recipe added in https://github.com/XRPLF/conan-center-index/pull/23.
2025-11-27 16:51:32 +00:00
Ayaz Salikhov
f399749ee2 chore: Add black pre-commit hook (#6086)
This change adds Black as a pre-commit hook to format Python files.
2025-11-26 19:14:17 +00:00
Ayaz Salikhov
2ed4047840 chore: Make conan lockfile generation commands into a script (#6085)
This change moves the lockfile instructions into a script, and instead of removing packages it sets the Conan home directory to a temporary directory.

There are several advantages, such as:
* Not affecting the user's Conan home directory, so there is no need to remove packages.
* Only the script needs to be run, rather than several commands.
2025-11-26 18:43:14 +00:00
Ayaz Salikhov
4e25dc9291 chore: Update lockfile (#6083)
This change update recipes, to make sure we have the best compatibility with latest compilers and so on.
2025-11-26 17:54:36 +00:00
Bart
a18b30b765 docs: Update instructions how to (re)generate conan.lock file (#6070)
This change updates the instructions for how to generate a Conan lockfile that is compatible with Linux, macOS, and Windows.

Whenever Conan dependencies change, the Conan lock file needs to be regenerated. However, different OSes have slightly different requirements, and thus require slightly different dependencies. Luckily a single `conan.lock` file can be used, as long as the union of dependencies is included.

The current instructions in the `BUILD.md` file are insufficient to regenerate the lock file such that it is compatible with all OSes, which this change addresses. The three profiles contain the bare minimum needed to generate the lockfile; it does not particularly matter whether the build type is Debug or Release, for instance.
2025-11-26 17:28:06 +00:00
Bart
856470203a ci: Trigger clio pipeline on PRs targeting release branches (#6080)
This change triggers the Clio pipeline on PRs that target any of the `release*` branches (in addition to the `master` branch), as opposed to only the `release` branch.
2025-11-25 21:03:17 +00:00
Jingchen
b124c9f7e3 refactor: Retire Flow and FlowSortStrands amendments (#6054)
Amendments activated for more than 2 years can be retired. This change retires the Flow and FlowSortStrands amendments.
2025-11-25 14:21:17 +00:00
Bart
b550dc00ed ci: Remove missing commits check (#6077)
This change removes the CI check for missing commits, as well as a stray path to the publish-docs workflow that isn't used in the on-trigger workflow.
2025-11-24 21:43:39 -05:00
Jingchen
21c02232a5 refactor: Retire RequireFullyCanonicalSig amendment (#6035)
Amendments activated for more than 2 years can be retired. This change retires the RequireFullyCanonicalSig amendment.
2025-11-24 13:58:37 +00:00
Jingchen
a791c03dc1 refactor: Retire DeletableAccounts amendment (#6056)
Amendments activated for more than 2 years can be retired. This change retires the DeletableAccounts amendment.
2025-11-24 11:52:08 +00:00
Jingchen
800a315383 refactor: Retire CryptoConditionsSuite amendment (#6036)
Amendments activated for more than 2 years can be retired. This change retires the CryptoConditionsSuite amendment.
2025-11-24 06:23:16 -05:00
Olek
8449c6c365 Fix: nullptr resolving without db config (#6029)
If the config disables SQL db usage, such as a validator:

```
[ledger_tx_tables]
use_tx_tables = 0
```

then the pointer to DB engine is null, but it was still resolved during startup. Although it didn't crash in Release mode, possibly due to the compiler optimizing it away, it did crash in Debug mode. This change explicitly checks for the validity of the pointer and generates a runtime error if not set.
2025-11-21 22:20:45 +00:00
Vito Tumas
58e03190ac docs: Improve VaultWithdraw documentation (#6068) 2025-11-21 16:59:12 -05:00
Jingchen
fb74dc28e1 chore: Clean up comment in NetworkOps_test.cpp (#6066)
This change removes a copyright notice that was accidentally copied over from another file.
2025-11-21 17:11:00 +00:00
Pratik Mankawde
e4dccfd49b refactor: Retire DisallowIncoming amendment (#6045)
Amendments activated for more than 2 years can be retired. This change retires the DisallowIncoming amendment.
2025-11-21 15:18:00 +00:00
Jingchen
57f4b4eb7f refactor: Retire Checks amendment (#6055)
Amendments activated for more than 2 years can be retired. This change retires the Checks amendment.
2025-11-21 14:19:43 +00:00
Ayaz Salikhov
adbeb94c2b ci: Only upload artifacts in XRPLF repo owner (#6060)
This change prevents uploading too many artifacts in non-public repositories.
2025-11-20 18:09:03 +00:00
Mayukha Vadari
a3d4be4eaf fix: Set correct index for limit in book_offers CLI (#6043)
This change fixes an indexing typo in the `book_offers` CLI processing, and does not affect the HTTPS/WS RPC processing.
2025-11-20 06:37:28 -05:00
Olek
6ff495fd9b Fix: Perform array size check (#6030)
The `ledger_entry` and `deposit_preauth` requests require an array of credentials. However, the array size is not checked before is gets processing. This fix adds checks and return errors in case array size is too big.
2025-11-19 16:58:18 +00:00
sunnyraindy
ad37461ab2 chore: Fix some typos in comments (#6040) 2025-11-18 20:21:35 -05:00
Mayukha Vadari
d9c27da529 refactor: split up RPCHelpers.h into two (#6047)
This PR splits `RPCHelpers.h` into two files, by moving out all the ledger-fetching-related functions into a separate file, `RPCLedgerHelpers.h`. It also moves `getAccountObjects` to `AccountObjects.h`, since it is only used in that one place.
2025-11-18 15:44:39 -05:00
Bart
3fb6acd29e ci: Fix filtering out of Clang 20+ on ARM (#6046)
This change fixes the strategy matrix check to filter out the Clang 20+ on ARM, which still fail due to problems with Boost.
2025-11-17 21:54:13 +00:00
Bart
77b7cef5a7 ci: Use new Debian Trixie images (#6034)
This change uses the new Debian Trixie CI images added by XRPLF/ci#83.
2025-11-17 19:31:19 +00:00
Jingchen
2c187461cc refactor: Retire NegativeUNL amendment (#6033)
Amendments activated for more than 2 years can be retired. This change retires the NegativeUNL amendment.
2025-11-17 14:02:10 +00:00
Ayaz Salikhov
13a12c6402 chore: Update nudb recipe to remove linker warnings (#6038) 2025-11-14 20:27:28 +00:00
Bronek Kozicki
362ecbd1cb fix: Apply object reserve for Vault pseudo-account (#5954) 2025-11-14 17:30:56 +00:00
Jingchen
7025e92080 refactor: Retire TicketBatch amendment (#6032)
Amendments activated for more than 2 years can be retired. This change retires the TicketBatch amendment.
2025-11-14 13:33:34 +00:00
Vlad
f81d0d8c98 chore: Clean up incorrect comments (#6031)
This change cleans up incorrect comments that were left in test cases after one of the amendments was retired.
2025-11-13 13:37:38 +00:00
Jingchen
508937f3d1 refactor: Retire MultiSignReserve and ExpandedSignerList amendments (#5981)
Amendments activated for more than 2 years can be retired. This change retires the MultiSignReserve and ExpandedSignerList amendments.
2025-11-13 11:42:45 +00:00
Bronek Kozicki
8580a5795a chore: Set version 3.1.0-b0 (#5986)
Technically b0 is not a release, so no "release" prefix here. It marks the point at which we moved the preceding release (3.0.0 in this case) from Beta to Release Candidate.
2025-11-12 18:55:49 +00:00
Bart
9b53bd9871 ci: Clean workspace on Windows self-hosted runners (#6024)
This change updates the `cleanup-workspace` action to its latest version, which added support for Windows.
2025-11-12 09:30:45 -05:00
hustrust
5fc07e3979 docs: fix spelling in comments (#6002) 2025-11-12 08:23:45 -05:00
Bronek Kozicki
2ebc2ca885 fix: floating point representation errors in vault (#5997)
This change fixes floating point errors in conversion of shares to assets and other way, used in `VaultDeposit`, `VaultWithdraw` and `VaultClawback`. In the floating point calculations the division introduces a larger error than multiplication. If we do division first, then the error introduced will be increased by the multiplication that follows, which is therefore the wrong order to perform these two operations. This change flips the order of arithmetic operations, which minimizes the error.
2025-11-11 19:39:09 +00:00
Ayaz Salikhov
c2a90b706f ci: Specify bash as the default shell in workflows (#6021) 2025-11-11 18:17:03 +00:00
Jingchen
9ffb434315 refactor: Add XRPL_RETIRE_FIX and XRPL_RETIRE_FEATURE macros (#6014)
Rather than having a single `XRPL_RETIRE` macro that applies to both feature and fix amendments, this change replaces it by new `XRPL_RETIRE_FIX` and `XRPL_RETIRE_FEATURE` macros that avoids confusion between whether to prefix the amendment name with `feature` or `fix`.
2025-11-11 12:45:13 -05:00
Jingchen
ff18cfef96 refactor: Retire DepositPreAuth and DepositAuth amendments (#5978)
Amendments activated for more than 2 years can be retired. This change retires the fDepositPreAuth and DepositAuth amendments.
2025-11-11 15:21:07 +00:00
Bronek Kozicki
03704f712b chore: Move running of unit tests out of coverage target (#6018)
This change makes the progress of unit tests visible and also gives more flexibility when running them.
2025-11-11 14:55:16 +00:00
Pratik Mankawde
9b332d88c1 refactor: Retire PayChanRecipientOwnerDir amendment (#5946)
Amendments activated for more than 2 years can be retired. This change retires the PayChanRecipientOwnerDir amendment.
2025-11-11 09:07:45 -05:00
Ayaz Salikhov
33309480d4 ci: Update Conan to 2.22.2 (#6019)
This updates the CI image hashes after following change: https://github.com/XRPLF/ci/pull/81. And, since we use latest Conan, we can have `conan.lock` with a newline at the end, and we don't need to exclude it from `pre-commit` hooks any longer.
2025-11-10 16:23:40 -05:00
Bart
098eadca0a refactor: Update RocksDB, SQLite, Doctest (#6015) 2025-11-10 18:02:35 +00:00
Bronek Kozicki
3b810c305a fix: JSON parsing of negative STNumber and STAmount (#5990)
This change fixes JSON parsing of negative `int` input in `STNumber` and `STAmount`. The conversion of JSON to `STNumber` or `STAmount` may trigger a condition where we negate smallest possible `int` value, which is undefined behaviour. We use a temporary storage as `int64_t` to avoid this bug. Note that this only affects RPC, because we do not parse JSON in the protocol layer, and hence no amendment is needed.
2025-11-10 17:33:20 +00:00
Bart
3968efb5f1 chore: Make CMake improvements (#6010)
This change removes unused definitions from the CMake files, moves variable definitions from `XrplSanity` to `XrplSettings` where they better belong, and updates the minimum GCC and Clang versions to match what we actually minimally support.
2025-11-10 16:33:54 +00:00
Jingchen
12c629a1d2 refactor: Retire CheckCashMakesTrustLine amendment (#5974)
Amendments activated for more than 2 years can be retired. This change retires the CheckCashMakesTrustLine amendment.
2025-11-10 16:03:10 +00:00
Bronek Kozicki
8d2dff2e48 chore: Unify build & test, add ctest to coverage (#6013)
This change unifies the build and test jobs into a single job, and adds `ctest` to coverage reporting.

The mechanics of coverage reporting is slightly complex and most of it is encapsulated in the `coverage` target. The status quo way of preparing coverage reports involves running a single target `cmake --build . --target coverage`, which does three things:
* Build the `rippled` binary (via target dependency)
* Prepare coverage reports:
  * Run `./rippled -u` unit tests.
  * Gather test output and build reports.

This makes it awkward to add an additional `ctest` step between build and coverage reporting steps. The better solution is to split `coverage` target into separate build, followed by `ctest`, followed by test generation. Luckily, the `coverage` target has been designed specifically to support such case; it does not need to build `rippled`, it's just a dependency. Similarly it allows additional tests to be run before gathering test outputs; in principle we could even strip it from running tests and run them separately instead. This means we can keep build, `ctest` and generation of coverage reports as separate steps, as long as the state of build directory is fully (including file timestamps, additional coverage files etc.) preserved between the steps. This means that in order to run `ctest` for coverage reporting we need to integrate build and test into a single job, which this change does.
2025-11-10 10:32:08 -05:00
Michael Legleux
c39f9c561c chore: Point xrpld symlink to rippled (#6012)
As part of renaming ripple(d) to xrpl(d), the xrpld symlink was made to point to itself instead of to the rippled binary. This change fixes the symlink.
2025-11-07 10:51:12 +00:00
Bart
173f9f7bb0 chore: Removes unnecessary creation of symlink in CMake install file (#6009) 2025-11-06 09:06:45 +00:00
Shawn Xie
28a1f90938 fix: domain order book insertion #5998 2025-11-05 23:08:10 +00:00
Jingchen
673fb06c75 refactor: Retire fixTrustLinesToSelf amendment (#5989)
Amendments activated for more than 2 years can be retired. This change retires the fixTrustLinesToSelf amendment.
2025-11-05 14:56:20 +00:00
Jingchen
f28ba57b81 refactor: Retire HardenedValidations amendment (#5988)
Amendments activated for more than 2 years can be retired. This change retires the HardenedValidations amendment.
2025-11-04 17:04:01 +00:00
Bart
f3a2ec1fb2 refactor: Rename cmake files and definitions (#5975)
Per XLS-0095, we are taking steps to rename ripple(d) to xrpl(d).

This change updates the CMake files and definitions therein, plus a handful of related modifications. Specifically, the compiler files are renamed from `RippleXXX.cmake` or `RippledXXX.cmake` to `XrplXXX.cmake`, and any references to `ripple` and `rippled` (with or without capital letters) are renamed to `xrpl` and `xrpld`, respectively. The name of the binary, currently `rippled`, remains unchanged and will be updated in a separate PR. This change is purely cosmetic and does not affect the functioning of the binary.
2025-11-04 10:07:36 +00:00
Bart
1d42c4f6de refactor: Remove unnecessary copyright notices already covered by LICENSE.md (#5929)
Per XLS-0095, we are taking steps to rename ripple(d) to xrpl(d).

This change specifically removes all copyright notices referencing Ripple, XRPLF, and certain affiliated contributors upon mutual agreement, so the notice in the LICENSE.md file applies throughout. Copyright notices referencing external contributions remain as-is. Duplicate verbiage is also removed.
2025-11-04 08:33:42 +00:00
Bart
ada83564d8 refactor: Rename RIPPLE_ and RIPPLED_ definitions to XRPL_ (#5821)
Per XLS-0095, we are taking steps to rename ripple(d) to xrpl(d).

C++ include guards are used to prevent the contents of a header file from being included multiple times in a single compilation unit. This change renames all `RIPPLE_` and `RIPPLED_` definitions, primarily include guards, to `XRPL_`. It also provides a script to allow developers to replicate the changes in their local branch or fork to avoid conflicts.
2025-11-04 07:13:58 +00:00
Mayukha Vadari
b18dece145 refactor: move API functions from RPCHelpers.h to ApiVersion.h (#5889)
This change moves two functions, `setVersion` and `getAPIVersionNumber`, from `RPCHelpers.h` to `ApiVersion.h`.
2025-11-03 19:09:14 +00:00
Jingchen
63a08560ca refactor: retire/remove NFT amendments (#5971)
Amendments activated for more than 2 years can be retired, and obsolete retirements that were never activated can also be removed after 2 years. This change retires the NonFungibleTokensV1_1, fixNonFungibleTokensV1_2, and fixNFTokenRemint amendments, and removes the NonFungibleTokensV1, fixNFTokenNegOffer, and fixNFTokenDirV1 amendments.
2025-11-03 18:43:57 +00:00
Jingchen
8ac8a47c99 refactor: Retire ImmediateOfferKilled amendment (#5973)
Amendments activated for more than 2 years can be retired. This change retires the ImmediateOfferKilled amendment.
2025-11-03 17:26:12 +00:00
Bart
12c4b5a632 ci: Update CI image hashes to use netstat (#5987)
To debug test failures we would like to use `netstat`, but that package wasn't installed yet in the CI images. This change uses the new CI images created by https://github.com/XRPLF/ci/pull/79.
2025-11-03 16:57:24 +00:00
Bart
25c5e3b17f chore: Remove version number in find_dependency for OpenSSL (#5985)
We are already using OpenSSL 3.5.2. The version number in the `find_dependency` statement is optional, and belongs in `conanfile.py` anyway.
2025-11-03 13:53:19 +00:00
Jingchen
8eb233c2ea refactor: Modularize shamap and nodestore (#5668)
This change moves the shamap and nodestore from `xrpld` to `libxrpl`.
2025-10-31 22:25:16 +00:00
Jingchen
50fc93f742 refactor: Retire fixMasterKeyAsRegularKey amendment (#5959)
Amendments activated for more than 2 years can be retired. This change retires the fixMasterKeyAsRegularKey amendment.
2025-10-31 21:01:44 +00:00
Jingchen
ab45a8a737 refactor: Retire fixReducedOffersV1 amendment (#5972)
Amendments activated for more than 2 years can be retired. This change retires the fixReducedOffersV1 amendment.
2025-10-31 20:25:05 +00:00
Jingchen
dfafb141cc refactor: Retire fixAmendmentMajorityCalc amendment (#5961)
Amendments activated for more than 2 years can be retired. This change retires the fixAmendmentMajorityCalc amendment.
2025-10-31 20:01:12 +00:00
Mayukha Vadari
4e32d2ed98 refactor: Clean up TxMeta (#5845)
This change:
* Simplifies the `TxMeta` constructors - both were setting the same set of fields, and to make it harder for future bugs to arise and keep the code DRY, we can combine those into one helper function.
* Removes an unused constructor.
* Renames the variables to avoid Hungarian naming.
* Removes a bunch of now-unnecessary helper functions.
2025-10-31 19:29:30 +00:00
yinyiqian1
fa69918124 fix: Address permission delegation vulnerability (#5825)
This change introduces the `featurePermissionDelegationV1_1` amendment, which is designed to supersede both `featurePermissionDelegation` and `fixDelegateV1_1 amendments, which should be considered deprecated. The `checkPermission` function will now return `terNO_DELEGATE_PERMISSION` when a delegate transaction lacks the necessary permissions.
2025-10-31 15:01:06 -04:00
Ed Hennis
cbbb2b1be0 test: Count crashed test suites (#5924)
When outputting the unit test summary, this change counts crashed tests as failures.
2025-10-31 17:10:53 +00:00
Vlad
cf2d763fa1 refactor: Improve txset handling (#5951) 2025-10-31 16:10:14 +00:00
Bronek Kozicki
2dd1d682ac Remove directory size limit (#5935)
This change introduces the `fixDirectoryLimit` amendment to remove the directory pages limit. We found that the directory size limit is easier to hit than originally assumed, and there is no good reason to keep this limit, since the object reserve provides the necessary incentive to avoid creating unnecessary objects on the ledger.
2025-10-30 21:31:03 +00:00
Bronek Kozicki
4cb1084c02 fix: Change Credential sfSubjectNode to optional (#5936)
Field `sfSubjectNode` is not populated by `CredentialCreate` in self-issued credentials. Rather than fixup the Credentials already on the ledger, we can in this case safely change the object template for this field from `soeREQUIRED` to `soeOPTIONAL`.
2025-10-30 21:04:55 +00:00
Ed Hennis
8d1b3b3994 refactor: Add support for extra transaction signature validation (#5851)
- Restructures `STTx` signature checking code to be able to handle
  a `sigObject`, which may be the full transaction, or may be an object
  field containing a separate signature. Either way, the `sigObject` can
  be a single- or multi-sign signature.
- This is distinct from 550f90a75e (#5594), which changed the check in
  Transactor, which validates whether a given account is allowed to sign
  for the given transaction. This cryptographically checks the signature
  validity.
2025-10-30 15:39:56 -04:00
Pratik Mankawde
b39d7a6519 refactor: Retire fixQualityUpperBound amendment (#5960)
Amendments activated for more than 2 years can be retired. This change retires the fixQualityUpperBound amendment.
2025-10-30 18:47:47 +00:00
Pratik Mankawde
b0910e359e refactor: Retire fix1623 amendment (#5928)
Amendments activated for more than 2 years can be retired. This change retires the fix1623 amendment.
2025-10-30 17:33:08 +00:00
Pratik Mankawde
44e027e516 refactor: Retire fixTakerDryOfferRemoval amendment (#5958)
Amendments activated for more than 2 years can be retired. This change retires the fixTakerDryOfferRemoval amendment.
2025-10-30 11:27:01 -04:00
Bart
a10f42a3aa ci: Check whether test failures are caused by port exhaustion (#5938)
This change adds an extra step to the CI test job that outputs network info, which may allow us to confirm whether random test failures are caused by port exhaustion.
2025-10-30 13:19:51 +00:00
Ayaz Salikhov
efd4c1b95d chore: Use new prepare-runner (#5970)
See: XRPLF/actions#19.
2025-10-30 08:49:44 -04:00
Pratik Mankawde
f8b4f692f1 refactor: Retire fixSTAmountCanonicalize code (#5956)
Amendments activated for more than 2 years can be retired. This change retires the fixSTAmountCanonicalize amendment.
2025-10-29 18:17:50 +00:00
Pratik Mankawde
80a3ae6386 refactor: Retire fixRmSmallIncreasedQOffers amendment (#5955)
Amendments activated for more than 2 years can be retired. This change retires the fixRmSmallIncreasedQOffers amendment.
2025-10-29 17:34:06 +00:00
Bart
48d38c1e2c refactor: Sorts retired amendments to reduce conflicts (#5966)
We are on an amendment retiring spree, but each change results in conflicts in `features.macro` because currently they all add the retired amendment to the end of the list. By sorting the list the number of conflicts should be reduced, making it easier to merge them.
2025-10-29 17:03:16 +00:00
Jingchen
553fb5be3b refactor: Retire fixCheckThreading amendment (#5957)
Amendments activated for more than 2 years can be retired. This change retires the fixCheckThreading amendment.
2025-10-29 16:36:51 +00:00
Pratik Mankawde
efa917d9f3 refactor: Retire fix1578 amendment (#5927)
Amendments activated for more than 2 years can be retired. This change retires the fix1578 amendment.
2025-10-29 16:08:17 +00:00
Pratik Mankawde
bd3bc917f8 refactor: Retire fix1571 amendment (#5925)
Amendments activated for more than 2 years can be retired. This change retires the fix1571 amendment.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-29 14:21:50 +00:00
Jingchen
ed5d6f3e22 feat: Add public key to log messages (#5678)
To protect the identity of UNL validators, the IP addresses are redacted from the log messages sent to the common Grafana instance. However, without such identifying information it is challenging to debug issues. This change adds a node's public key to logs to improve our ability to debug issues.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-29 14:16:37 +00:00
Pratik Mankawde
a8e4da0b11 Retire fix1781 amendment (#5931)
* Retired fix1781 amendment

Signed-off-by: Pratik Mankawde <pmankawde@ripple.com>

* refactor: Retire fix1781 amendment

Amendments activated for more than 2 years can be retired. This change retires the fix1781 amendment.

---------

Signed-off-by: Pratik Mankawde <pmankawde@ripple.com>
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-29 11:32:43 +00:00
Bart
1dd60242de ci: Use nproc-2 to set parallelism for builds and tests (#5939)
This change reduces the number of cores used to build and test, as using all cores may be contributing to occasional build and test failures.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-29 00:07:09 +00:00
Bart
76611c3f46 ci: Use commit hash so workflows are not canceled when merging multiple PRs (#5950)
This change changes the CI concurrency group for pushes to the `develop` branch to use the commit hash instead of the target branch.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 20:08:08 +00:00
Bart
5efaf0c328 ci: Only upload codecov reports in the original repo, not in forks (#5953)
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 19:52:52 +00:00
Bart
0aa23933ea ci: Only log into Conan when uploading packages (#5952)
There are separate steps for logging into Conan and uploading packages. However, at the moment sometimes the login step is executed even though no packages will be uploaded. The condition for performing both steps should be the same.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 19:52:13 +00:00
Bronek Kozicki
21f3c12d85 fix: invariant error in fee-sized VaultWithdraw (#5876)
This changes fixes an invariant error where the amount withdrawn is equal to the transaction fee.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 18:12:11 +00:00
Copilot
7d5ed0cd8d fix: account_tx limit parameter validation for malformed values (#5891)
This change fixes the `account_tx` RPC method to properly validate malformed limit parameter values. Previously, invalid values like `0`, `1.2`, `"10"`, `true`, `false`, `-1`, `[]`, `{}`, etc. were either accepted without errors or caused internal errors. Now all malformed values correctly return the `invalidParams` error.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 17:42:43 +00:00
Pratik Mankawde
d9960d5ba0 refactor: Retire fix1543 amendment (#5926)
Amendments activated for more than 2 years can be retired. This change retires the fix1543 amendment.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 15:10:38 +00:00
Ayaz Salikhov
91fa6b2295 ci: Only run .exe files during test phase on Windows (#5947) 2025-10-28 14:26:25 +00:00
Jingchen
76f774e22d refactor: Migrate json unit tests to use doctest (#5533)
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-28 14:19:39 +00:00
Shawn Xie
f4f7618173 Change fixMPTDeliveredAmount to Supported::yes (#5833)
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-27 19:04:14 +00:00
Ayaz Salikhov
66f16469f9 fix: Upload all test binaries (#5932) 2025-10-27 17:27:56 +00:00
Ayaz Salikhov
1845b1c656 chore: Better pre-commit failure message (#5940) 2025-10-27 14:43:45 +00:00
Ayaz Salikhov
e192ffe964 fix: Clean up build profile options (#5934)
The `-Wno-missing-template-arg-list-after-template-kw` flag is only needed for the grpc library. Use `+=` for the default build flags to make it easier to extend in the future.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-24 15:16:15 +00:00
Pratik Mankawde
2bf77cc8f6 refactor: Retire fix1515 amendment (#5920)
Amendments activated for more than 2 years can be retired. This change retires the fix1515 amendment.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-23 13:35:54 +00:00
Ayaz Salikhov
5e33ca56fd Use "${ENVVAR}" instead of ${{ env.ENVVAR }} syntax in GitHub Actions (#5923) 2025-10-22 18:43:04 +00:00
Pratik Mankawde
7c39c810eb Moved fix1513 to retire state (#5919)
Signed-off-by: Pratik Mankawde <pmankawde@ripple.com>
2025-10-22 14:50:43 +00:00
Valon Mamudi
a7792ebcae Add configurable NuDB block size feature (#5468)
As XRPL network demand grows and ledger sizes increase, the default 4K NuDB block size becomes a performance bottleneck, especially on high-performance storage systems. Modern SSDs and enterprise storage often perform better with larger block sizes, but rippled previously had no way to configure this parameter. This change therefore implements configurable NuDB block size support, allowing operators to optimize storage performance based on their hardware configuration. The feature adds a new `nudb_block_size` configuration parameter that enables block sizes from 4K to 32K bytes, with comprehensive validation and backward compatibility.

Specific changes are:
- Implements `parseBlockSize()` function with validation.
- Adds `nudb_block_size` configuration parameter.
- Supports block sizes from 4K to 32K (power of 2).
- Adds comprehensive logging and error handling.
- Maintains backward compatibility with 4K default.
- Adds unit tests for block size validation.
- Updates configuration documentation with performance guidance.
- Marks feature as experimental.
- Applies code formatting fixes.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-21 00:51:44 +00:00
Bronek Kozicki
83ee3788e1 fix: Enforce reserve when creating trust line or MPToken in VaultWithdraw (#5857)
Similarly to other transaction typed that can create a trust line or MPToken for the transaction submitter (e.g. CashCheck #5285, EscrowFinish #5185 ), VaultWithdraw should enforce reserve before creating a new object. Additionally, the lsfRequireDestTag account flag should be enforced for the transaction submitter.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-20 23:07:12 +00:00
Mayukha Vadari
ae719b86d3 refactor: move server_definitions code to its own files (#5890) 2025-10-20 22:24:48 +00:00
Mayukha Vadari
dd722f8b3f chore: remove unnecessary LCOV_EXCL_LINE (#5913) 2025-10-20 22:23:52 +00:00
Bart
30190a5feb chore: Set explicit timeouts for build and test jobs (#5912)
The default job timeout is 5 hours, while build times are anywhere between 4-20 mins and test times between 2-10. As a runner occasionally gets stuck, we should fail much quicker.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-20 20:49:19 +00:00
Bart
afb6e0e41b chore: Set fail fast to false, except for when the merge group is used (#5897)
This PR sets the fail-fast strategy option to false (it defaults to true), unless it is run by a merge group.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-17 16:17:02 +00:00
Bart
5523557226 chore: Clean up Conan variables in CI (#5903)
This change sanitizes inputs by setting them as environment variables, and adjusts the number of CPUs used for building. Namely, GitHub inputs should be sanitized, per recommendation by Semgrep, as using them directly poses a security risk. A recent change further overrode the global configuration by having builds use all cores, but as we have noticed an increased number of job cancelation this change updates it to use all cores less one.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-17 16:04:58 +00:00
Bart
b64707f53b chore: Add support for RHEL 8 (#5880)
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-17 14:09:47 +00:00
Ayaz Salikhov
0b113f371f refactor: Update pre-commit workflow to latest version (#5902)
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-17 13:40:10 +00:00
tequ
b4c894c1ba refactor: Autofill signature for Simulate RPC (#5852)
This change enables autofilling of signature-related fields in the Simulate RPC.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-16 21:18:53 +00:00
Mayukha Vadari
92281a4ede refactor: replace string JSONs with Json::Value (#5886)
There are some tests that write out JSONs as a string instead of using the Json::Value library, which are cleaned up by this change.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-16 16:02:25 +00:00
Bronek Kozicki
e80642fc12 fix: Fix regression in ConnectAttempt (#5900)
A regression was introduced in #5669 which would cause rippled to potentially dereference a disengaged std::optional when connecting to a peer. This would cause UB in release build and crash in debug.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-16 12:54:36 +00:00
Mayukha Vadari
640ce4988f refactor: replace boost::lexical_cast<std::string> with to_string (#5883)
This change replaces boost::lexical_cast<std::string> with to_string in some of the tests to make them more readable.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-16 12:46:21 +00:00
Mayukha Vadari
a422855ea7 refactor: replace JSON LastLedgerSequence with last_ledger_seq (#5884)
This change replaces instances of JSON LastLedgerSequence with last_ledger_seq, which makes the tests a bit simpler and easier to read.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-15 20:55:11 +00:00
Jingchen
108f90586c chore: Reduce build log verbosity on Windows (#5865)
Windows is extremely chatty and generates tons of logs when building, making it practically impossible to use the build logs to debug issues. This change sets the verbosity to 'quiet' on Windows.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-15 20:53:01 +00:00
tequ
519d1dbc34 refactor: Replace fee().accountReserve(0) with fee().reserve (#5843)
This PR changes fee().accountReserve(0) to fee().reserve, as the current network reserve amount should be used instead of the account reserve.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-15 20:50:06 +00:00
Bart
3d44758e5a fix: Update tools image shas (#5896)
This change updates the Docker image hashes of the tools-rippled images to fix a missing dependency.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-15 18:23:44 +00:00
Michael Legleux
97bc94a7f6 feat: Install validator-keys (#5841)
* feat: Install validator-keys

* output validator-keys with everything else
2025-10-14 22:02:38 +00:00
zingero
34619f2504 docs: Fix typo in JSON writer documentation (#5881)
Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-14 19:10:19 +00:00
tequ
3509de9c5f refactor: Add paychan namespace and update related tests (#5840)
This change adds a paychan namespace to the TestHelpers and implementation files, improving organization and clarity. Additionally, it updates the AMM test to use the new `paychan::create` function for payment channel creation.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-14 18:37:39 +00:00
Ayaz Salikhov
459d0da010 chore: Support CMake 4 without workarounds (#5866) 2025-10-14 11:18:34 -04:00
Mayukha Vadari
8637d606a4 chore: Exclude code/unreachable transaction code from Codecov (#5847)
This change excludes from Codecov unreachable/difficult-to-test transaction code (such as `tecINTERNAL`) and old code (from amendments that have been enabled for a long time that are only around for ledger replay reasons). This removes about 200 lines of misses and increases the Codecov coverage by 0.3% (79.2% to 79.5%).
2025-10-13 14:56:18 +00:00
Bart
8456b8275e chore: Add wildcard to support triggering for release pipelines (#5879)
This change adds a wildcard to the release branch in the CI pipeline spec. Namely, after adopting an improved release process, with release branches that now look like release-X.Y, the trigger pipeline was no longer running as it only searched for an exact match to release.
2025-10-10 12:22:42 -04:00
Bart
3c88786bb0 refactor: Downgrades OpenSSL to 3.5.4 (#5878)
This change downgrades OpenSSL 3.6.0 to 3.5.4. To avoid potential zero-day issues in a new major version of OpenSSL, 3.6.0, it is safer to stick with 3.5.4. While 3.6.0 has some nice new features, such as improved SHA512 hashing, it also introduces new features that could contain bugs. In contrast, 3.5.4 has seen quite a few bug fixes over 3.5.0 and has been used in the wild for a while now.
2025-10-10 14:18:24 +00:00
Bart
46ba8a28fe refactor: Update Conan dependencies: OpenSSL (#5873)
This change bumps OpenSSL from 1.1.1w to 3.6.0.
2025-10-09 13:27:26 -04:00
Bronek Kozicki
5ecde3cf39 Add vault invariants (#5518)
This change adds invariants for SingleAssetVault #5224 (XLS-065), which had been intentionally skipped earlier to keep the SAV PR size manageable.
2025-10-08 15:04:02 +00:00
tequ
620fb26823 test: Add more tests for Simulate RPC metadata (#5827) 2025-10-08 14:36:09 +00:00
Bronek Kozicki
6b6b213cf5 chore: Fix release build error (#5864)
This change fixes a release build error with GCC 15.2.

The `fields` variable is only used in `XRPL_ASSERT`, which evaluates to nothing in a Release build, leaving the variable unused. This change silences the build warning.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-08 13:45:44 +00:00
Bart
f61086b43c refactor: Update CI strategy matrix to use new RHEL 9 and RHEL 10 images (#5856)
This change uses the new RHEL 9 and 10 images to build and test the binary, and adds support for having different Docker image SHAs per distro-compiler combination.

Instead of supporting RHEL each minor version, we are simplifying our pipelines by only supporting RHEL major versions. Our CI Docker images have already been updated accordingly, and we recently added support for RHEL 10 as well. Up until now, the CI Docker images had all been rebuilt at the same time, but that is not necessarily true as the most recent push to the CI repo has shown where the RHEL images now have a different SHA than the Debian and Ubuntu ones.

Co-authored-by: Bart Thomee <11445373+bthomee@users.noreply.github.com>
2025-10-08 13:15:24 +00:00
Mayukha Vadari
176fd2b6e4 chore: exclude all UNREACHABLE blocks from codecov (#5846) 2025-10-08 09:25:51 +01:00
1820 changed files with 75103 additions and 191844 deletions

View File

@@ -37,7 +37,7 @@ BinPackParameters: false
BreakBeforeBinaryOperators: false
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: true
ColumnLimit: 80
ColumnLimit: 120
CommentPragmas: "^ IWYU pragma:"
ConstructorInitializerAllOnOneLineOrOnePerLine: true
ConstructorInitializerIndentWidth: 4

54
.claude/CLAUDE.md Normal file
View File

@@ -0,0 +1,54 @@
# Workflow Orchestration
## 1. Plan Mode Default
- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
- If something goes sideways, STOP and re-plan immediately - don't keep pushing
- Use plan mode for verification steps, not just building
- Write detailed specs upfront to reduce ambiguity
## 2. Subagent Strategy
- Use subagents liberally to keep main context window clean
- Offload research, exploration, and parallel analysis to subagents
- For complex problems, throw compute at it via parallelizing
- One task per subagent for focused execution
## 3. Self-Improvement Loop
- After ANY correction from the user: update `tasks/lessons.md` with the pattern
- Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these rules until mistake drops
- Review lessons at session start for relevant project
## 4. Verification Before Done
- Never mark a task complete without proving it works
- Diff behavior between main and your changes when relevant
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness
## 5. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask "is there a more elegant way?"
- If a fix feels hacky: "Know now, do later, implement the elegant solution"
- Skip this for simple, obvious fixes - don't over-engineer
- Challenge your own first solution
## 6. Autonomous Bug Fixing
- When given a bug report: just fix it. Don't ask for hand-holding
- Point at logs, errors, failing tests - then resolve them
- Zero context switching required from the user
- Go fix failing CI tests without being told how
# Task Management
1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
2. **Verify Plans**: Check in before starting implementation
3. **Track Progress**: Mark items complete as you go
4. **Explain Changes**: High-level summary at each step
5. **Document Results**: Add review section to `tasks/todo.md`
6. **Capture Lessons**: Update `tasks/lessons.md` after corrections
# Core Principles
**Simplicity First**: Make every change as simple as possible. Impact minimal code.
**No Boilerplate**: Skip documentation. No README/docs bloat. Test only if requested.
**Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

530
.claude/skills/amendment.md Normal file
View File

@@ -0,0 +1,530 @@
# XRPL Amendment Creation Skill
This skill guides you through creating XRPL amendments, whether for brand new features or fixes/extensions to existing functionality.
## Amendment Types
There are two main types of amendments:
1. **New Feature Amendment** (`feature{Name}`) - Entirely new functionality
2. **Fix/Extension Amendment** (`fix{Name}`) - Modifications to existing functionality
## Step 1: Determine Amendment Type
Ask the user:
- Is this a **brand new feature** (new transaction type, ledger entry, or capability)?
- Or is this a **fix or extension** to existing functionality?
---
## For NEW FEATURE Amendments
### Checklist:
#### 1. Feature Definition in features.macro
**ONLY FILE TO EDIT:** `include/xrpl/protocol/detail/features.macro`
- [ ] Add to TOP of features.macro (reverse chronological order):
```
XRPL_FEATURE(YourFeatureName, Supported::no, VoteBehavior::DefaultNo)
```
- [ ] This creates the variable `featureYourFeatureName` automatically
- [ ] Follow naming convention: Use the feature name WITHOUT the "feature" prefix
- [ ] Examples: `Batch``featureBatch`, `LendingProtocol``featureLendingProtocol`
#### 2. Support Status
- [ ] Start with `Supported::no` during development
- [ ] Change to `Supported::yes` when ready for network voting
- [ ] Use `VoteBehavior::DefaultNo` (validators must explicitly vote for it)
#### 3. Code Implementation
- [ ] Implement new functionality (transaction type, ledger entry, etc.)
- [ ] Add feature gate check in preflight:
```cpp
if (!env.current()->rules().enabled(feature{Name}))
{
return temDISABLED;
}
```
#### 4. Disable Route Handling
- [ ] Ensure transaction returns `temDISABLED` when amendment is disabled
- [ ] Implement early rejection in preflight/preclaim phase
- [ ] Add appropriate error messages
#### 5. Test Implementation
Create comprehensive test suite with this structure:
```cpp
class {FeatureName}_test : public beast::unit_test::suite
{
public:
void testEnable(FeatureBitset features)
{
testcase("enabled");
// Test with feature DISABLED
{
auto const amendNoFeature = features - feature{Name};
Env env{*this, amendNoFeature};
env(transaction, ter(temDISABLED));
}
// Test with feature ENABLED
{
Env env{*this, features};
env(transaction, ter(tesSUCCESS));
// Validate new functionality works
}
}
void testPreflight(FeatureBitset features)
{
testcase("preflight");
// Test malformed transaction validation
}
void testPreclaim(FeatureBitset features)
{
testcase("preclaim");
// Test signature and claim phase validation
}
void testWithFeats(FeatureBitset features)
{
testEnable(features);
testPreflight(features);
testPreclaim(features);
// Add feature-specific tests
}
void run() override
{
using namespace test::jtx;
auto const all = supported_amendments();
testWithFeats(all);
}
};
```
#### 6. Test Coverage Requirements
- [ ] Test amendment DISABLED state (returns `temDISABLED`)
- [ ] Test amendment ENABLED state (returns `tesSUCCESS`)
- [ ] Test malformed transactions
- [ ] Test signature validation
- [ ] Test edge cases specific to feature
- [ ] Test amendment transition behavior
#### 7. Documentation
- [ ] Create specification document (XLS_{NAME}.md)
- [ ] Document new transaction types, ledger entries, or capabilities
- [ ] Create test plan document
- [ ] Document expected behavior when enabled/disabled
---
## For FIX/EXTENSION Amendments
### Checklist:
#### 1. Fix Definition in features.macro
**ONLY FILE TO EDIT:** `include/xrpl/protocol/detail/features.macro`
- [ ] Add to TOP of features.macro (reverse chronological order):
```
XRPL_FIX(YourFixName, Supported::no, VoteBehavior::DefaultNo)
```
- [ ] This creates the variable `fixYourFixName` automatically
- [ ] Follow naming convention: Use the fix name WITHOUT the "fix" prefix (it's added automatically)
- [ ] Examples: `TokenEscrowV1``fixTokenEscrowV1`, `DirectoryLimit``fixDirectoryLimit`
- [ ] Start with `Supported::no` during development, change to `Supported::yes` when ready
#### 2. Backward Compatibility Implementation
**Critical**: Use enable() with if/else to preserve existing functionality
```cpp
// Check if fix is enabled
bool const fix{Name} = env.current()->rules().enabled(fix{Name});
// Conditional logic based on amendment state
if (fix{Name})
{
// NEW behavior with fix applied
// This is the corrected/improved logic
}
else
{
// OLD behavior (legacy path)
// Preserve original functionality for backward compatibility
}
```
**Alternative pattern with ternary operator:**
```cpp
auto& viewToUse = sb.rules().enabled(fix{Name}) ? sb : legacyView;
```
#### 3. Multiple Fix Versions Pattern
For iterative fixes, use version checking:
```cpp
bool const fixV1 = rv.rules().enabled(fixXahauV1);
bool const fixV2 = rv.rules().enabled(fixXahauV2);
switch (transactionType)
{
case TYPE_1:
if (fixV1) {
// Behavior with V1 fix
} else {
// Legacy behavior
}
break;
case TYPE_2:
if (fixV2) {
// Behavior with V2 fix
} else if (fixV1) {
// Behavior with only V1
} else {
// Legacy behavior
}
break;
}
```
#### 4. Test Both Paths
Always test BOTH enabled and disabled states:
```cpp
void testFix(FeatureBitset features)
{
testcase("fix behavior");
for (bool withFix : {false, true})
{
auto const amend = withFix ? features : features - fix{Name};
Env env{*this, amend};
// Setup test scenario
env.fund(XRP(1000), alice);
env.close();
if (!withFix)
{
// Test OLD behavior (before fix)
env(operation, ter(expectedErrorWithoutFix));
// Verify old behavior is preserved
}
else
{
// Test NEW behavior (after fix)
env(operation, ter(expectedErrorWithFix));
// Verify fix works correctly
}
}
}
```
#### 5. Security Fix Pattern
For security-critical fixes (like fixBatchInnerSigs):
```cpp
// Test vulnerability exists WITHOUT fix
{
auto const amendNoFix = features - fix{Name};
Env env{*this, amendNoFix};
// Demonstrate vulnerability
// Expected: Validity::Valid (WRONG - vulnerable!)
BEAST_EXPECT(result == Validity::Valid);
}
// Test vulnerability is FIXED WITH amendment
{
Env env{*this, features};
// Demonstrate fix
// Expected: Validity::SigBad (CORRECT - protected!)
BEAST_EXPECT(result == Validity::SigBad);
}
```
#### 6. Test Coverage Requirements
- [ ] Test fix DISABLED (legacy behavior preserved)
- [ ] Test fix ENABLED (new behavior applied)
- [ ] Test amendment transition
- [ ] For security fixes: demonstrate vulnerability without fix
- [ ] For security fixes: demonstrate protection with fix
- [ ] Test edge cases that triggered the fix
- [ ] Test combinations with other amendments
#### 7. Documentation
- [ ] Document what was broken/suboptimal
- [ ] Document the fix applied
- [ ] Document backward compatibility behavior
- [ ] Create test summary showing both paths
---
## Best Practices for All Amendments
### 1. Naming Conventions
- New features: `feature{DescriptiveName}` (e.g., `featureBatch`, `featureHooks`)
- Fixes: `fix{IssueDescription}` (e.g., `fixBatchInnerSigs`, `fixNSDelete`)
- Use CamelCase without underscores
### 2. Feature Flag Checking
```cpp
// At the point where behavior diverges:
bool const amendmentEnabled = env.current()->rules().enabled(feature{Name});
// Or in view/rules context:
if (!rv.rules().enabled(feature{Name}))
return {}; // or legacy behavior
```
### 3. Error Codes
- New features when disabled: `temDISABLED`
- Fixes may return different validation errors based on state
- Document all error code changes
### 4. Test Structure Template
```cpp
class Amendment_test : public beast::unit_test::suite
{
public:
// Core tests
void testEnable(FeatureBitset features); // Enable/disable states
void testPreflight(FeatureBitset features); // Validation
void testPreclaim(FeatureBitset features); // Claim phase
// Feature-specific tests
void test{SpecificScenario1}(FeatureBitset features);
void test{SpecificScenario2}(FeatureBitset features);
// Master orchestrator
void testWithFeats(FeatureBitset features)
{
testEnable(features);
testPreflight(features);
testPreclaim(features);
test{SpecificScenario1}(features);
test{SpecificScenario2}(features);
}
void run() override
{
using namespace test::jtx;
auto const all = supported_amendments();
testWithFeats(all);
}
};
BEAST_DEFINE_TESTSUITE(Amendment, app, ripple);
```
### 5. Documentation Files
Create these files:
- **Specification**: `XLS_{FEATURE_NAME}.md` - Technical specification
- **Test Plan**: `{FEATURE}_COMPREHENSIVE_TEST_PLAN.md` - Test strategy
- **Test Summary**: `{FEATURE}_TEST_IMPLEMENTATION_SUMMARY.md` - Test results
- **Review Findings**: `{FEATURE}_REVIEW_FINDINGS.md` (if applicable)
### 6. Amendment Transition Testing
Test the moment an amendment activates:
```cpp
void testAmendmentTransition(FeatureBitset features)
{
testcase("amendment transition");
// Start with amendment disabled
auto const amendNoFeature = features - feature{Name};
Env env{*this, amendNoFeature};
// Perform operations in disabled state
env(operation1, ter(temDISABLED));
// Enable amendment mid-test (if testing mechanism supports it)
// Verify state transitions correctly
// Perform operations in enabled state
env(operation2, ter(tesSUCCESS));
}
```
### 7. Cache Behavior
If amendment affects caching (like fixBatchInnerSigs):
- [ ] Test cache behavior without fix
- [ ] Test cache behavior with fix
- [ ] Document cache invalidation requirements
### 8. Multi-Amendment Combinations
Test interactions with other amendments:
```cpp
void testMultipleAmendments(FeatureBitset features)
{
// Test all combinations
for (bool withFeature1 : {false, true})
for (bool withFeature2 : {false, true})
{
auto amend = features;
if (!withFeature1) amend -= feature1;
if (!withFeature2) amend -= feature2;
Env env{*this, amend};
// Test interaction behavior
}
}
```
### 9. Performance Considerations
- [ ] Minimize runtime checks (cache `rules().enabled()` result if used multiple times)
- [ ] Avoid nested feature checks where possible
- [ ] Document performance impact
### 10. Code Review Checklist
- [ ] Both enabled/disabled paths are tested
- [ ] Backward compatibility is preserved (for fixes)
- [ ] Error codes are appropriate
- [ ] Documentation is complete
- [ ] Security implications are considered
- [ ] Cache behavior is correct
- [ ] Edge cases are covered
---
## Common Patterns Reference
### Pattern: New Transaction Type
```cpp
// In transactor code:
TER doApply() override
{
if (!ctx_.view().rules().enabled(feature{Name}))
return temDISABLED;
// New transaction logic here
return tesSUCCESS;
}
```
### Pattern: New Ledger Entry Type
```cpp
// In ledger entry creation:
if (!view.rules().enabled(feature{Name}))
return temDISABLED;
auto const sle = std::make_shared<SLE>(ltNEW_TYPE, keylet);
view.insert(sle);
```
### Pattern: Behavioral Fix
```cpp
// At decision point:
bool const useFix = view.rules().enabled(fix{Name});
if (useFix)
{
// Corrected behavior
return performCorrectValidation();
}
else
{
// Legacy behavior (preserved for compatibility)
return performLegacyValidation();
}
```
### Pattern: View Selection
```cpp
// Select which view to use based on amendment:
auto& applyView = sb.rules().enabled(feature{Name}) ? newView : legacyView;
```
---
## Example Workflows
### Workflow 1: Creating a New Feature Amendment
1. User requests: "Add a new ClaimReward transaction type"
2. Skill asks: "What should the amendment be called? (e.g., BalanceRewards - without 'feature' prefix)"
3. Add to features.macro:
```
XRPL_FEATURE(BalanceRewards, Supported::no, VoteBehavior::DefaultNo)
```
4. Implement transaction with `temDISABLED` gate using `featureBalanceRewards`
5. Create test suite with testEnable, testPreflight, testPreclaim
6. Run tests with amendment enabled and disabled
7. When ready, update to `Supported::yes` in features.macro
8. Create specification document
9. Review checklist
### Workflow 2: Creating a Fix Amendment
1. User requests: "Fix the signature validation bug in batch transactions"
2. Skill asks: "What should the fix be called? (e.g., BatchInnerSigs - without 'fix' prefix)"
3. Add to features.macro:
```
XRPL_FIX(BatchInnerSigs, Supported::no, VoteBehavior::DefaultNo)
```
4. Implement fix with if/else using `fixBatchInnerSigs` to preserve old behavior
5. Create test demonstrating vulnerability without fix
6. Create test showing fix works when enabled
7. When ready, update to `Supported::yes` in features.macro
8. Document both code paths
9. Review checklist
---
## Quick Reference: File Locations
- **Amendment definitions (ONLY place to add)**: `include/xrpl/protocol/detail/features.macro`
- **Feature.h (auto-generated, DO NOT EDIT)**: `include/xrpl/protocol/Feature.h`
- **Feature.cpp (auto-generated, DO NOT EDIT)**: `src/libxrpl/protocol/Feature.cpp`
- **Test files**: `src/test/app/` or `src/test/protocol/`
- **Specifications**: Project root (e.g., `XLS_SMART_CONTRACTS.md`)
- **Test plans**: Project root (e.g., `BATCH_COMPREHENSIVE_TEST_PLAN.md`)
## How the Macro System Works
The amendment system uses C preprocessor macros:
1. **features.macro** - Single source of truth (ONLY file you edit):
```
XRPL_FEATURE(Batch, Supported::yes, VoteBehavior::DefaultNo)
XRPL_FIX(TokenEscrowV1, Supported::yes, VoteBehavior::DefaultNo)
```
2. **Feature.h** - Auto-generated declarations from macro:
```cpp
extern uint256 const featureBatch;
extern uint256 const fixTokenEscrowV1;
```
3. **Feature.cpp** - Auto-generated registrations from macro:
```cpp
uint256 const featureBatch = registerFeature("Batch", ...);
uint256 const fixTokenEscrowV1 = registerFeature("fixTokenEscrowV1", ...);
```
**DO NOT** modify Feature.h or Feature.cpp directly - they process features.macro automatically.
---
## When to Use This Skill
Invoke this skill when:
- Creating a new XRPL amendment
- Adding a new transaction type or ledger entry
- Fixing existing XRPL functionality
- Need guidance on amendment best practices
- Setting up amendment tests
- Reviewing amendment implementation
The skill will guide you through the appropriate workflow based on amendment type.

99
.claude/skills/index.md Normal file
View File

@@ -0,0 +1,99 @@
# xrpld Codebase Skills Index
## Description
This is the top-level guide for all best-practices skills in this repository. Use this to understand the codebase organization and find the right skill for any task.
## When to Use Skills
Reference a skill whenever you are:
- **Writing new code** in a module - check the skill first for established patterns
- **Modifying existing code** - verify your changes follow module conventions
- **Adding a new transaction type** - see `libxrpl/tx/transactors.md` for the full template
- **Debugging** - skills list key files and common pitfalls per module
- **Reviewing code** - skills document what "correct" looks like for each module
## Codebase Architecture
The codebase is split into two main areas:
### `src/libxrpl/` — The Library (skills in `.claude/skills/libxrpl/`)
Reusable library code: data types, serialization, cryptography, ledger state, transaction processing, and storage. This is the **protocol layer**.
| Module | Responsibility |
|--------|---------------|
| `basics` | Foundational types: Buffer, Slice, base_uint, Number, logging, error contracts |
| `beast` | Support layer: Journal logging, test framework, instrumentation, IP types |
| `conditions` | Crypto-conditions (RFC): fulfillment validation, DER encoding |
| `core` | Job queue, load monitoring, hash-based message dedup |
| `crypto` | CSPRNG, secure erasure, RFC1751 encoding |
| `json` | Json::Value, parsing, serialization, StaticString optimization |
| `ledger` | ReadView/ApplyView, state tables, payment sandbox, credit ops |
| `net` | HTTP/HTTPS client, SSL certs, async I/O |
| `nodestore` | Persistent node storage: RocksDB, NuDB, Memory backends |
| `protocol` | STObject hierarchy, SField, Serializer, TER codes, Features, Keylets |
| `proto` | Protocol Buffer generated headers (gRPC API definitions) |
| `rdb` | SOCI database wrapper, checkpointing |
| `resource` | Rate limiting, endpoint tracking, abuse prevention |
| `server` | Port config, SSL/TLS, WebSocket, admin networks |
| `shamap` | SHA-256 Merkle radix tree (16-way branching, COW) |
| `tx` | Transaction pipeline: Transactor base, preflight/preclaim/doApply |
### `src/xrpld/` — The Server Application (skills in `.claude/skills/xrpld/`)
The running rippled server: application lifecycle, consensus, networking, RPC, and peer management. This is the **application layer**.
| Module | Responsibility |
|--------|---------------|
| `app` | Application singleton, ledger management, consensus adapters, services |
| `app/main` | Application initialization and lifecycle |
| `app/ledger` | Ledger storage, retrieval, immutable state management |
| `app/consensus` | RCL consensus adapters (bridges generic algorithm to rippled) |
| `app/misc` | Fee voting, amendments, SHAMapStore, TxQ, validators, NetworkOPs |
| `app/paths` | Payment path finding algorithm, trust line caching |
| `app/rdb` | Application-level database operations |
| `app/tx` | Application-level transaction handling |
| `consensus` | Generic consensus algorithm (CRTP-based, app-independent) |
| `core` | Configuration (Config.h), time keeping, network ID |
| `overlay` | P2P networking: peer connections, protocol buffers, clustering |
| `peerfinder` | Network discovery: bootcache, livecache, slot management |
| `perflog` | Performance logging and instrumentation |
| `rpc` | RPC handler dispatch, coroutine suspension, 40+ command handlers |
| `shamap` | Application-level SHAMap operations (NodeFamily) |
### `include/xrpl/` — Header Files
Headers live in `include/xrpl/` and mirror the `src/libxrpl/` structure. Each skill already references its corresponding headers in the "Key Files" section.
## Cross-Cutting Conventions
### Error Handling
- **Transaction errors**: Return `TER` enum (tesSUCCESS, tecFROZEN, temBAD_AMOUNT, etc.)
- **Logic errors**: `Throw<std::runtime_error>()`, `LogicError()`, `XRPL_ASSERT()`
- **I/O errors**: `Status` enum or `boost::system::error_code`
- **RPC errors**: Inject via `context.params`
### Assertions
```cpp
XRPL_ASSERT(condition, "ClassName::method : description"); // Debug only
XRPL_VERIFY(condition, "ClassName::method : description"); // Always enabled
```
### Logging
```cpp
JLOG(j_.warn()) << "Message"; // Always wrap in JLOG macro
```
### Memory Management
- `IntrusiveRefCounts` + `SharedIntrusive` for shared ownership in libxrpl
- `std::shared_ptr` for shared ownership in xrpld
- `std::unique_ptr` for exclusive ownership
- `CountedObject<T>` mixin for instance tracking
### Feature Gating
```cpp
if (ctx.rules.enabled(featureMyFeature)) { /* new behavior */ }
```
### Code Organization
- Headers in `include/xrpl/`, implementations in `src/libxrpl/` or `src/xrpld/`
- `#pragma once` (never `#ifndef` guards)
- `namespace xrpl { }` for all code
- `detail/` namespace for internal helpers
- Factory functions: `make_*()` returning `unique_ptr` or `shared_ptr`

View File

@@ -0,0 +1,79 @@
# Basics Module Best Practices
## Description
Use when working with foundational utilities in `src/libxrpl/basics/` or `include/xrpl/basics/`. Covers data structures, memory management, logging, numeric operations, error handling, and string utilities.
## Responsibility
Provides fundamental building blocks for the entire codebase: memory types (Buffer, Slice, Blob), intrusive smart pointers, arbitrary-precision integers (base_uint), multi-precision decimal arithmetic (Number), logging infrastructure, exception handling contracts, and platform abstractions.
## Key Patterns
### Memory Types
- **Slice** - Non-owning view into contiguous bytes (like std::span)
- **Buffer** - Owning byte container (like std::vector<uint8_t>)
- **Blob** - Alias for std::vector<unsigned char>
- Prefer `Slice` for read-only parameters, `Buffer` for owned data
### Intrusive Smart Pointers
```cpp
// Prefer intrusive pointers over std::shared_ptr for minimal overhead
// Object embeds its own reference count
class MyObject : public IntrusiveRefCounts {
// ...
};
// Use SharedIntrusive<MyObject> when weak pointers needed
```
### Error Handling
```cpp
// Contract-based exceptions (logs call stack then throws)
Throw<std::runtime_error>("Invalid source file");
LogThrow("exception message");
// Logic errors for invariant violations
LogicError("This should never happen");
// Assertions (fuzzing-aware)
XRPL_ASSERT(condition, "function_name : description");
XRPL_VERIFY(condition, "message"); // Always enabled, not just debug
```
### Logging
```cpp
// Use JLOG macro - short-circuits if level disabled
JLOG(debugLog().warn()) << "Message: " << value;
JLOG(j_.trace()) << "Verbose detail";
// Never: debugLog().warn() << "msg"; // Missing JLOG wastes formatting
```
### Number Precision
```cpp
// Use Number for multi-precision decimal arithmetic
// Always use RAII guard for rounding mode
NumberRoundModeGuard mg(Number::towards_zero);
auto result = amount * rate;
// Guard restores previous mode on scope exit
```
### base_uint Template
```cpp
// Typed big-endian integers: base_uint<Bits, Tag>
// Tag prevents mixing unrelated types of same width
using uint256 = base_uint<256, void>;
using AccountID = base_uint<160, detail::AccountIDTag>;
```
## Common Pitfalls
- Never use `std::shared_ptr` when IntrusiveRefCounts is available - it adds a separate allocation
- Never format log messages without JLOG wrapper - wastes CPU when level is disabled
- Never use raw `assert()` - use `XRPL_ASSERT` for fuzzing instrumentation support
- Never mix `Buffer` and `Slice` ownership semantics - Slice does NOT own its data
## Key Files
- `include/xrpl/basics/IntrusiveRefCounts.h` - Atomic reference counting
- `include/xrpl/basics/IntrusivePointer.h` - Smart pointer using intrusive refs
- `include/xrpl/basics/base_uint.h` - Arbitrary-length big-endian integers
- `include/xrpl/basics/Buffer.h`, `Blob.h`, `Slice.h` - Memory types
- `include/xrpl/basics/Number.h` - Multi-precision decimal arithmetic
- `include/xrpl/basics/Log.h` - Logging infrastructure
- `include/xrpl/basics/contract.h` - Throw, LogicError, XRPL_ASSERT

View File

@@ -0,0 +1,62 @@
# Beast Module Best Practices
## Description
Use when working with the Beast support layer in `src/libxrpl/beast/` or `include/xrpl/beast/`. Covers networking types, unit testing, Journal logging, and instrumentation.
## Responsibility
Library support layer providing network types (IP addresses, endpoints), unit testing framework, Journal/logging abstractions, instrumentation/assertion macros, and type introspection utilities.
## Key Patterns
### Journal Logging
```cpp
// Journal wraps a Sink pointer - copy by value is cheap
beast::Journal const j_;
// Severity levels: kTrace, kDebug, kInfo, kWarning, kError, kFatal
JLOG(j_.warn()) << "User-facing issue";
JLOG(j_.debug()) << "Implementation detail";
JLOG(j_.trace()) << "Very verbose diagnostic";
JLOG(j_.error()) << "Unexpected failure";
```
### Unit Testing
```cpp
class MyTest : public beast::unit_test::suite {
void run() override {
testcase("feature description");
BEAST_EXPECT(value == expected); // Non-fatal assertion
BEAST_REQUIRE(value == expected); // Fatal - aborts test on failure
}
};
BEAST_DEFINE_TESTSUITE(MyTest, module, ripple);
```
### Instrumentation
```cpp
// Use XRPL_ASSERT for debug-only assertions (fuzzing-aware)
XRPL_ASSERT(ptr != nullptr, "MyClass::method : null pointer");
// Format: "ClassName::methodName : description"
// The string format is important for fuzzing instrumentation
```
### IP Endpoint Types
```cpp
// Use beast::IP::Endpoint for network addresses
beast::IP::Endpoint endpoint;
// Supports both IPv4 and IPv6
// Includes port information
```
## Common Pitfalls
- Never use `BEAST_EXPECT` when the test cannot continue on failure - use `BEAST_REQUIRE` instead
- Never create a Journal with a dangling Sink pointer - ensure Sink outlives Journal
- Always include "ClassName::methodName" prefix in XRPL_ASSERT messages for traceability
## Key Files
- `include/xrpl/beast/utility/Journal.h` - Log sink abstraction
- `include/xrpl/beast/unit_test/suite.h` - Test framework
- `include/xrpl/beast/utility/instrumentation.h` - XRPL_ASSERT macros
- `include/xrpl/beast/net/IPEndpoint.h` - Network endpoint types
- `include/xrpl/beast/core/SemanticVersion.h` - Version parsing

View File

@@ -0,0 +1,33 @@
# Beast Clock Module Best Practices
## Description
Use when working with clock abstractions in `src/libxrpl/beast/clock/` or `include/xrpl/beast/clock/`. Covers abstract clock interfaces and manual clock implementations for testing.
## Responsibility
Provides clock abstractions that decouple code from system time, enabling deterministic testing with manual clocks and supporting different time granularities.
## Key Patterns
### Abstract Clock Interface
```cpp
// Use abstract_clock<T> for testable time-dependent code
// Production: uses system clock
// Testing: uses manual_clock for deterministic control
```
### Manual Clock for Testing
```cpp
// Advance time manually in tests
manual_clock<std::chrono::steady_clock> clock;
clock.advance(std::chrono::seconds(30));
// Deterministic - no flaky tests from timing issues
```
## Common Pitfalls
- Never use `std::chrono::system_clock::now()` directly - inject clock dependency
- Always use manual_clock in unit tests for deterministic behavior
- Be aware of Ripple Epoch vs Unix Epoch when working with ledger timestamps
## Key Files
- `include/xrpl/beast/clock/abstract_clock.h` - Abstract clock interface
- `include/xrpl/beast/clock/manual_clock.h` - Testable clock implementation

View File

@@ -0,0 +1,29 @@
# Beast Core Module Best Practices
## Description
Use when working with core beast utilities in `src/libxrpl/beast/core/` or `include/xrpl/beast/core/`. Covers semantic versioning and core type utilities.
## Responsibility
Provides core utilities including semantic version parsing/comparison, system abstractions, and foundational type support.
## Key Patterns
### Semantic Version Parsing
```cpp
// Parse version strings following semver spec
SemanticVersion version;
if (version.parse("1.2.3-beta")) {
auto major = version.majorVersion;
auto minor = version.minorVersion;
auto patch = version.patchVersion;
}
// Supports comparison operators for version ordering
```
## Common Pitfalls
- Always validate version strings before using - parse() returns false on invalid input
- Remember that pre-release versions have lower precedence than release versions
## Key Files
- `include/xrpl/beast/core/SemanticVersion.h` - Version parsing and comparison
- `src/libxrpl/beast/core/SemanticVersion.cpp` - Implementation

View File

@@ -0,0 +1,41 @@
# Beast Insight Module Best Practices
## Description
Use when working with metrics and monitoring in `src/libxrpl/beast/insight/` or `include/xrpl/beast/insight/`. Covers counters, gauges, and metrics collection.
## Responsibility
Provides metrics collection infrastructure for monitoring application performance: counters for cumulative values, gauges for point-in-time measurements, and hooks for metrics export.
## Key Patterns
### Metrics Types
```cpp
// Counter: Monotonically increasing value (e.g., total requests)
insight::Counter requests;
++requests;
// Gauge: Point-in-time value (e.g., current connections)
insight::Gauge connections;
connections = currentCount;
// Event: Timed operation tracking
insight::Event latency;
```
### Null Metrics
```cpp
// Use NullCollector when metrics disabled
// All operations become no-ops with zero overhead
auto collector = insight::NullCollector::New();
```
## Common Pitfalls
- Use Counter for cumulative values, Gauge for current state - don't mix them
- Always use NullCollector for tests - avoids metrics overhead
- Never store raw metric values in long-lived objects - use the insight types
## Key Files
- `include/xrpl/beast/insight/Counter.h` - Cumulative counter
- `include/xrpl/beast/insight/Gauge.h` - Point-in-time gauge
- `include/xrpl/beast/insight/Collector.h` - Metrics collector interface
- `include/xrpl/beast/insight/NullCollector.h` - No-op collector

View File

@@ -0,0 +1,46 @@
# Beast Net Module Best Practices
## Description
Use when working with network types in `src/libxrpl/beast/net/` or `include/xrpl/beast/net/`. Covers IP address and endpoint representations.
## Responsibility
Provides network type abstractions for IP addresses (v4 and v6) and endpoints (address + port), with parsing utilities and comparison operators.
## Key Patterns
### IP Endpoint Usage
```cpp
// beast::IP::Endpoint combines address + port
beast::IP::Endpoint endpoint(
beast::IP::Address::from_string("127.0.0.1"), 51235);
// Supports both IPv4 and IPv6
beast::IP::Endpoint v6endpoint(
beast::IP::Address::from_string("::1"), 51235);
```
### Address Parsing
```cpp
// Parse from string with error handling
boost::system::error_code ec;
auto address = beast::IP::Address::from_string(input, ec);
if (ec) { /* handle invalid address */ }
```
### Comparison and Ordering
```cpp
// Endpoints support full comparison for use in containers
std::set<beast::IP::Endpoint> endpoints;
std::map<beast::IP::Endpoint, Consumer> consumers;
```
## Common Pitfalls
- Always handle both IPv4 and IPv6 when working with endpoints
- Use error_code overload of from_string to handle invalid input gracefully
- Never assume address format - always parse and validate
## Key Files
- `include/xrpl/beast/net/IPEndpoint.h` - Combined address + port
- `include/xrpl/beast/net/IPAddress.h` - IP address types
- `include/xrpl/beast/net/IPAddressV4.h` - IPv4 specific
- `include/xrpl/beast/net/IPAddressV6.h` - IPv6 specific

View File

@@ -0,0 +1,47 @@
# Beast Utility Module Best Practices
## Description
Use when working with beast utility classes in `src/libxrpl/beast/utility/` or `include/xrpl/beast/utility/`. Covers Journal logging, instrumentation, and type introspection.
## Responsibility
Provides utility classes including the Journal logging abstraction (Sink + Stream), XRPL_ASSERT/XRPL_VERIFY instrumentation macros, and type introspection helpers.
## Key Patterns
### Journal and Sink Architecture
```cpp
// Sink: abstract base for log message routing
class Sink {
virtual void write(beast::severities::Severity level, std::string const& text) = 0;
void console(bool output); // Enable console output
};
// Journal: lightweight wrapper around Sink* (copy by value)
beast::Journal j(sinkPtr);
JLOG(j.warn()) << "Message";
// WrappedSink: adds prefix to all messages
beast::WrappedSink wrappedSink(parentSink, "MyModule");
```
### Instrumentation Macros
```cpp
// XRPL_ASSERT: Debug-only assertion (disabled in release, fuzzing-aware)
XRPL_ASSERT(condition, "ClassName::method : description");
// XRPL_VERIFY: Always-enabled assertion
XRPL_VERIFY(condition, "ClassName::method : description");
// Format convention: "ClassName::methodName : human-readable description"
```
## Common Pitfalls
- Always use "ClassName::methodName" prefix in assertion messages
- Journal is cheap to copy (just a pointer) - pass by value is fine
- WrappedSink must outlive any Journal created from it
- XRPL_ASSERT is no-op in release builds - don't put side effects in the condition
## Key Files
- `include/xrpl/beast/utility/Journal.h` - Log sink abstraction and Journal
- `include/xrpl/beast/utility/instrumentation.h` - XRPL_ASSERT, XRPL_VERIFY
- `include/xrpl/beast/utility/WrappedSink.h` - Prefixed log sink

View File

@@ -0,0 +1,63 @@
# Conditions Module Best Practices
## Description
Use when working with crypto-conditions in `src/libxrpl/conditions/` or `include/xrpl/conditions/`. Implements the RFC crypto-conditions specification.
## Responsibility
Implements crypto-conditions for conditional payments: condition fingerprints, fulfillment validation, multiple condition types (preimage, prefix, threshold, RSA, Ed25519), and binary DER serialization/deserialization.
## Key Patterns
### Fulfillment Interface
```cpp
// Abstract base for all fulfillment types
struct Fulfillment {
virtual ~Fulfillment() = default;
virtual Buffer fingerprint() const = 0;
virtual Type type() const = 0;
virtual bool validate(Slice data) const = 0;
virtual std::uint32_t cost() const = 0;
virtual Condition condition() const = 0;
};
```
### Factory Pattern for Deserialization
```cpp
// Returns unique_ptr + sets error_code (non-throwing)
std::unique_ptr<Fulfillment> deserialize(Slice s, std::error_code& ec);
// Usage:
std::error_code ec;
auto fulfillment = Fulfillment::deserialize(data, ec);
if (ec) return {}; // Early return on error
```
### Type-Safe Enums
```cpp
enum class Type : std::uint8_t {
preimageSha256 = 0,
prefixSha256 = 1,
thresholdSha256 = 2,
rsaSha256 = 3,
ed25519Sha256 = 4
};
```
### Size Limits
```cpp
static constexpr std::size_t maxSerializedCondition = 128;
static constexpr std::size_t maxSerializedFulfillment = 256;
// Always respect these limits when creating conditions
```
## Common Pitfalls
- Never throw exceptions from binary parsing - use `std::error_code` parameter pattern
- Always check `ec` after deserialization before using the result
- Respect `maxSerializedFulfillment` size limits
## Key Files
- `include/xrpl/conditions/Condition.h` - Base condition with type/fingerprint/cost
- `include/xrpl/conditions/Fulfillment.h` - Abstract fulfillment interface
- `include/xrpl/conditions/detail/PreimageSha256.h` - Preimage implementation
- `include/xrpl/conditions/detail/utils.h` - DER encoding/decoding
- `include/xrpl/conditions/detail/error.h` - Error codes

View File

@@ -0,0 +1,61 @@
# Core Module Best Practices
## Description
Use when working with job processing and routing infrastructure in `src/libxrpl/core/` or `include/xrpl/core/`. Covers job queues, load monitoring, and message deduplication.
## Responsibility
Distributed job processing with priority levels, load monitoring for execution tracking, and hash-based message suppression/routing for peer deduplication.
## Key Patterns
### Job Queue Priorities
```cpp
// Job types ordered by priority (lower enum = lower priority)
enum JobType {
jtINVALID = -1,
jtPACK, // Lowest priority
jtCLIENT_WEBSOCKET,
// ...
jtVALIDATION_t, // Trusted validation (high)
jtADMIN // Admin operations (highest)
};
// Position in enum determines scheduling priority
```
### HashRouter for Deduplication
```cpp
// Suppress duplicate messages from peers
std::optional<std::set<PeerShortID>> shouldRelay(uint256 const& key);
// Returns {} if already relayed, set of peers if should relay
// Track peer that sent a message
auto result = router.addSuppressionPeer(key, peer);
```
### RAII Locking
```cpp
// Always use lock_guard for mutex protection
std::lock_guard lock(mutex_);
auto result = emplace(key);
result.first.addPeer(peer);
return result.second; // Return while lock is held
```
### Optional Return Types
```cpp
// Use std::optional for "maybe" results
std::optional<std::set<PeerShortID>> shouldRelay(uint256 const& key);
// Caller checks: if (auto peers = shouldRelay(key)) { ... }
```
## Common Pitfalls
- Never hold locks longer than necessary - lock_guard scope = critical section
- Never ignore job priorities when scheduling work - use appropriate JobType
- Always let HashRouter handle message deduplication rather than implementing custom logic
## Key Files
- `include/xrpl/core/Job.h` - Job wrapper with type, index, function
- `include/xrpl/core/JobTypes.h` - Job type enumerations and metadata
- `include/xrpl/core/JobQueue.h` - Priority queue for dispatching jobs
- `include/xrpl/core/HashRouter.h` - Duplicate message suppression
- `include/xrpl/core/LoadMonitor.h` - Job execution time tracking

View File

@@ -0,0 +1,32 @@
# Core Detail Module Best Practices
## Description
Use when working with internal core implementation details in `src/libxrpl/core/detail/`. These are private implementation helpers not intended for direct external use.
## Responsibility
Internal implementation details for the core module, including helper functions and private data structures used by JobQueue, HashRouter, and LoadMonitor.
## Key Patterns
### Detail Namespace Convention
```cpp
namespace xrpl {
namespace detail {
// Internal helpers - not part of public API
// May change without notice between versions
}
}
```
### Encapsulation
- Code in `detail/` should only be included by its parent module
- Never include detail headers from outside the core module
- If you need functionality from detail, use the public core API instead
## Common Pitfalls
- Never depend on detail namespace types or functions from outside the core module
- Detail implementations may change without preserving API compatibility
- Always use the public `core/` headers for stable interfaces
## Key Files
- Files in this directory are implementation details of `include/xrpl/core/` headers

View File

@@ -0,0 +1,51 @@
# Crypto Module Best Practices
## Description
Use when working with cryptographic operations in `src/libxrpl/crypto/` or `include/xrpl/crypto/`. Covers CSPRNG, secure memory erasure, and RFC1751 encoding.
## Responsibility
Low-level cryptographic operations: cryptographically secure random number generation (CSPRNG), RFC1751 word-based encoding for keys, and secure memory erasure to prevent sensitive data leakage.
## Key Patterns
### CSPRNG Usage
```cpp
// Thread-safe PRNG - use the global singleton
auto& prng = crypto_prng();
// Generate random value
auto randomValue = prng();
// Fill buffer with random bytes
prng(buffer.data(), buffer.size());
// NEVER create your own csprng_engine - use crypto_prng()
```
### Secure Memory Erasure
```cpp
// Use volatile memset to prevent compiler optimization
secure_erase(secretKey.data(), secretKey.size());
// MUST be called before destroying any buffer containing secrets
```
### Engine Concept Conformance
```cpp
// csprng_engine meets UniformRandomNumberEngine requirements
using result_type = std::uint64_t;
static constexpr result_type min();
static constexpr result_type max();
// Can be used with standard distributions
```
## Common Pitfalls
- Never create a local `csprng_engine` instance - always use `crypto_prng()` singleton
- Never use `std::rand()` or `std::mt19937` for security-sensitive operations
- Always call `secure_erase()` on secret key material before destruction
- Never copy or move a `csprng_engine` - it's non-copyable and non-movable by design
- Be aware of OpenSSL version differences - locking behavior varies
## Key Files
- `include/xrpl/crypto/csprng.h` - Thread-safe PRNG engine
- `include/xrpl/crypto/RFC1751.h` - Human-readable key encoding
- `include/xrpl/crypto/secure_erase.h` - Volatile memset for secrets

View File

@@ -0,0 +1,68 @@
# JSON Module Best Practices
## Description
Use when working with JSON parsing and serialization in `src/libxrpl/json/` or `include/xrpl/json/`. Covers Json::Value, readers, writers, and custom allocators.
## Responsibility
JSON value representation (discriminated union for all JSON types), parsing text to Value objects, serialization from Value to text, and custom string allocation for memory control.
## Key Patterns
### Json::Value Usage
```cpp
// Discriminated union - supports all JSON types
Json::Value obj(Json::objectValue);
obj["key"] = "string_value";
obj["count"] = 42u;
obj["flag"] = true;
obj["nested"] = Json::objectValue;
// Array creation
Json::Value arr(Json::arrayValue);
arr.append("item");
arr.append(123);
// Type checking
if (obj.isObject()) { ... }
if (obj.isMember("key")) { ... }
```
### StaticString Optimization
```cpp
// Use StaticString for compile-time known keys to avoid allocation
static const Json::StaticString code("code");
static const Json::StaticString message("message");
object[code] = 1234; // No dynamic allocation for key
object[message] = "ok"; // Key stored as pointer, not copied
```
### Value Type Enum
```cpp
enum ValueType {
nullValue = 0,
intValue, uintValue, realValue,
stringValue, booleanValue,
arrayValue, objectValue
};
// Check type before accessing to avoid undefined behavior
```
### Lazy Initialization
```cpp
// Container elements auto-created on access (like JavaScript)
Json::Value obj;
obj["newKey"]["nested"] = 1; // Creates intermediate objects automatically
// Be aware: accessing a non-existent key creates it
```
## Common Pitfalls
- Accessing a non-existent key via `operator[]` creates a null entry - use `isMember()` to check first if you don't want side effects
- Use `const` overload of `operator[]` to avoid auto-creation: `obj["key"]` on const ref returns null reference
- Prefer `StaticString` for frequently-used keys to avoid repeated allocations
- Never assume JSON numeric types - check `isInt()`, `isUInt()`, `isDouble()` explicitly
## Key Files
- `include/xrpl/json/json_value.h` - Main Value class
- `include/xrpl/json/json_reader.h` - Text-to-Value parser
- `include/xrpl/json/json_writer.h` - Value-to-text serializer
- `include/xrpl/json/json_forwards.h` - Forward declarations and aliases

View File

@@ -0,0 +1,84 @@
# Ledger Module Best Practices
## Description
Use when working with ledger state management in `src/libxrpl/ledger/` or `include/xrpl/ledger/`. Covers views, state tables, payments, and credit operations.
## Responsibility
Manages the state of the distributed ledger: abstractions for viewing, reading, and applying transactions to ledger state. Handles account ownership tracking, trust lines, payment processing, directory management, and credential verification.
## Key Patterns
### ReadView vs ApplyView
```cpp
// ReadView: Read-only access to ledger state
bool exists = view.exists(keylet::account(accountID));
auto sle = view.read(keylet::account(accountID)); // Returns shared_ptr<SLE const>
// ApplyView: Mutable access for transaction application
auto sle = view.peek(keylet::account(accountID)); // Returns shared_ptr<SLE>
sle->setFieldAmount(sfBalance, newBalance);
view.update(sle); // Commit change
view.insert(newSle); // Create new entry
view.erase(sle); // Remove entry
```
### Enum-Based Control (No Boolean Blindness)
```cpp
// NEVER: bool ignoreFreeze = true;
// ALWAYS: Use named enums
enum FreezeHandling { fhIGNORE_FREEZE, fhZERO_IF_FROZEN };
enum AuthHandling { ahIGNORE_AUTH, ahZERO_IF_UNAUTHORIZED };
STAmount accountHolds(ReadView const& view, AccountID const& account,
Currency const& currency, AccountID const& issuer,
FreezeHandling zeroIfFrozen, beast::Journal j);
```
### Asset Variant Handling
```cpp
// Use std::visit for Asset (Issue or MPTIssue)
return std::visit(
[&](auto const& issue) {
return isIndividualFrozen(view, account, issue);
},
asset.value());
```
### PaymentSandbox for Isolation
```cpp
// Test payment effects before committing
PaymentSandbox sandbox(&view);
// ... apply changes to sandbox ...
sandbox.apply(view); // Commit all changes atomically
// Or let sandbox destruct to discard
```
### TER Return Codes
```cpp
// Transaction results are returned as TER, not exceptions
TER result = doApply();
if (result != tesSUCCESS) return result;
// TER categories: tes (success), tec (claimed fee), tef (failure), tel (local), tem (malformed)
```
### Depth Limiting
```cpp
// Recursive operations use depth parameter to prevent infinite recursion
TER checkVaultState(ReadView const& view, AccountID const& id, int depth = 0);
if (depth > maxDepth) return tecINTERNAL;
```
## Common Pitfalls
- Never use `read()` when you need to modify - use `peek()` instead
- Never forget to call `view.update(sle)` after modifying a peeked SLE
- Never use bare booleans for control flags - use the enum types
- Always check for frozen/unauthorized states before operating on trust lines
- Never ignore TER return values - propagate them up the call chain
## Key Files
- `include/xrpl/ledger/View.h` - Core read/write operations (largest file)
- `include/xrpl/ledger/ReadView.h` - Read-only interface
- `include/xrpl/ledger/ApplyView.h` - Mutable interface
- `src/libxrpl/ledger/PaymentSandbox.cpp` - Isolated payment testing
- `src/libxrpl/ledger/ApplyStateTable.cpp` - State change management
- `src/libxrpl/ledger/Credit.cpp` - Trust line and IOU operations

View File

@@ -0,0 +1,58 @@
# Net Module Best Practices
## Description
Use when working with network communication in `src/libxrpl/net/` or `include/xrpl/net/`. Covers HTTP/HTTPS client functionality and SSL certificate management.
## Responsibility
Provides HTTP/HTTPS client functionality for network requests, including SSL certificate registration, asynchronous request handling with boost::asio, and callback-based completion.
## Key Patterns
### Async HTTP with Callbacks
```cpp
// Callback returns bool indicating success/continuation
HTTPClient::get(
bSSL, io_context,
std::deque<std::string>{"site1.com", "site2.com"}, // Fallback sites
443, "/path",
maxResponseBytes,
timeout,
[](boost::system::error_code const& ec, int status, std::string const& body) -> bool {
if (ec) return false; // Stop
// Process response
return true; // Success
},
headers, journal);
```
### Lifetime Management with shared_from_this
```cpp
// Async callbacks use intrusive_ptr for safe lifetime
class HTTPClientImp : public HTTPClient,
public std::enable_shared_from_this<HTTPClientImp> {
void startAsync() {
auto self = shared_from_this(); // Prevent premature destruction
// ... schedule async operations ...
}
};
```
### Deadline Timers
```cpp
// Always set timeouts for network operations
boost::asio::basic_waitable_timer<std::chrono::steady_clock> timer_;
timer_.expires_after(std::chrono::seconds(timeout));
// Cancel pending operation on timeout
```
## Common Pitfalls
- Never start async operations without capturing shared_from_this - object may be destroyed before callback
- Always set deadline timers on network operations to prevent hanging connections
- Always set maximum response size limits to prevent resource exhaustion
- Never assume DNS resolution will succeed - handle resolver errors
## Key Files
- `include/xrpl/net/HTTPClient.h` - Main HTTP client interface
- `src/libxrpl/net/HTTPClient.cpp` - Implementation with async I/O
- `src/libxrpl/net/RegisterSSLCerts.cpp` - SSL certificate registration
- `include/xrpl/net/HTTPClientSSLContext.h` - SSL context management

View File

@@ -0,0 +1,24 @@
# Net Images Module Best Practices
## Description
Use when working with static image assets in `src/libxrpl/net/images/`. Contains embedded image data used by the HTTP server.
## Responsibility
Stores static image assets (favicons, logos) as embedded byte arrays for serving via the built-in HTTP server without external file dependencies.
## Key Patterns
### Embedded Assets
```cpp
// Images stored as static const byte arrays
// Compiled directly into the binary - no file I/O needed at runtime
static unsigned char const favicon[] = { /* ... */ };
```
## Common Pitfalls
- Keep embedded images small - they increase binary size
- Use appropriate image formats (ICO for favicons, PNG for logos)
- Update both the source image and the byte array when changing assets
## Key Files
- `src/libxrpl/net/images/` - Static image byte arrays embedded in the binary

View File

@@ -0,0 +1,68 @@
# NodeStore Module Best Practices
## Description
Use when working with persistent node storage in `src/libxrpl/nodestore/` or `include/xrpl/nodestore/`. Covers the storage abstraction layer, backend implementations, and caching.
## Responsibility
Abstraction layer for persistent storage of ledger nodes (SHAMap leaves and inner nodes). Supports multiple backend implementations (RocksDB, NuDB, Memory, Null) with a plugin architecture, caching, and async operations.
## Key Patterns
### Abstract Factory for Backends
```cpp
// Backend is pure virtual - concrete implementations selected at runtime
class Backend {
virtual ~Backend() = default;
virtual Status fetch(void const* key, std::shared_ptr<NodeObject>*) = 0;
virtual void store(std::shared_ptr<NodeObject> const&) = 0;
virtual void storeBatch(Batch const& batch) = 0;
};
// Backends: RocksDB, NuDB, Memory (testing), Null (disabled)
```
### Batch Operations
```cpp
// Always prefer batch operations for multiple reads/writes
virtual std::pair<std::vector<std::shared_ptr<NodeObject>>, Status>
fetchBatch(std::vector<uint256 const*> const& hashes) = 0;
virtual void storeBatch(Batch const& batch) = 0;
// Significantly reduces I/O overhead vs individual operations
```
### Status Enum (Not Exceptions)
```cpp
enum class Status { ok, notFound, keyTooBig, /* ... */ };
// I/O operations return Status, NOT throw exceptions
auto [objects, status] = backend->fetchBatch(hashes);
if (status != Status::ok) { /* handle */ }
```
### Configuration via Section
```cpp
// Backend options come from config file sections
RocksDBBackend(int keyBytes, Section const& keyValues,
Scheduler& scheduler, beast::Journal journal);
// Allows runtime tuning without recompilation
```
### Async Fetch with Scheduler
```cpp
// Non-blocking reads via scheduler integration
virtual void asyncFetch(uint256 const& hash,
std::function<void(std::shared_ptr<NodeObject>)>&& callback);
// Callback invoked on scheduler thread
```
## Common Pitfalls
- Never use individual fetch/store in tight loops - use batch operations
- Never throw exceptions from backend implementations - return Status enum
- Always configure appropriate cache sizes for the workload
- Never assume a fetch will succeed - always check Status
- Use Memory backend for unit tests, never RocksDB
## Key Files
- `include/xrpl/nodestore/Database.h` - Main storage interface
- `include/xrpl/nodestore/Backend.h` - Abstract backend interface
- `include/xrpl/nodestore/Manager.h` - Backend factory
- `include/xrpl/nodestore/NodeObject.h` - Individual node wrapper
- `src/libxrpl/nodestore/BatchWriter.cpp` - Batch write optimization

View File

@@ -0,0 +1,66 @@
# NodeStore Backend Module Best Practices
## Description
Use when working with storage backend implementations in `src/libxrpl/nodestore/backend/`. Covers RocksDB, NuDB, Memory, and Null backend factories.
## Responsibility
Concrete backend implementations for the NodeStore abstraction layer. Each backend provides persistent (or ephemeral) storage with different performance characteristics and use cases.
## Key Patterns
### Backend Factory Registration
```cpp
// Each backend is a factory that creates Backend instances
// Registered by name in the Manager
class RocksDBFactory : public Factory {
std::string getName() const override { return "RocksDB"; }
std::unique_ptr<Backend> createInstance(...) override;
};
```
### RocksDB Configuration
```cpp
// Extensive tuning via config Section
// Key options:
// open_files - Max open file descriptors
// filter_bits - Bloom filter bits per key (default 10)
// cache_mb - Block cache size in MB
// file_size_mb - Target SST file size
// compression - snappy (default), zlib, lz4, none
// block_size - Block size in KB (default 4)
// num_threads - Background compaction threads
```
### NuDB for Deterministic Storage
```cpp
// NuDB supports deterministic initialization
// Useful for reproducible test databases
// Hash-based storage with direct memory-mapped I/O
// Lower CPU overhead than RocksDB for write-heavy workloads
```
### Memory Backend for Testing
```cpp
// In-memory storage - fast but not persistent
// Use for unit tests only
// Thread-safe with internal mutex
```
### Null Backend for Disabled Storage
```cpp
// No-op backend - all operations succeed but store nothing
// Use when storage feature is disabled in config
```
## Common Pitfalls
- Use Memory backend for tests, never RocksDB (test isolation and speed)
- Always tune RocksDB bloom filter bits - default 10 is good for most workloads
- NuDB doesn't support range queries - only point lookups by hash
- Never use Null backend in production - data loss guaranteed
- Always configure appropriate open_files limits for the OS
## Key Files
- `src/libxrpl/nodestore/backend/RocksDBFactory.cpp` - RocksDB backend (~12.5KB)
- `src/libxrpl/nodestore/backend/NuDBFactory.cpp` - NuDB backend (~12KB)
- `src/libxrpl/nodestore/backend/MemoryFactory.cpp` - In-memory backend (~5KB)
- `src/libxrpl/nodestore/backend/NullFactory.cpp` - No-op backend (~2KB)

View File

@@ -0,0 +1,35 @@
# Proto Module Best Practices
## Description
Use when working with Protocol Buffer definitions in `include/xrpl/proto/`. Covers gRPC API definitions and generated protobuf headers.
## Responsibility
Contains Protocol Buffer generated headers defining the gRPC API for rippled. These define the wire format for RPC communication between clients and the server.
## Key Patterns
### Proto Organization
```
include/xrpl/proto/
└── org/xrpl/rpc/v1/
└── *.proto generated headers
```
### Usage
```cpp
#include <xrpl/proto/org/xrpl/rpc/v1/xrp_ledger.grpc.pb.h>
// Use generated types for gRPC request/response
```
### Versioning
- API is versioned under `org/xrpl/rpc/v1/`
- New versions get a new directory (v2/, etc.)
- Never modify generated files directly - modify the .proto source
## Common Pitfalls
- Never hand-edit generated .pb.h files - regenerate from .proto sources
- Always use the versioned path (v1/) when including proto headers
- Proto types are for serialization only - convert to native types for business logic
## Key Files
- `include/xrpl/proto/org/xrpl/rpc/v1/` - Generated gRPC API headers

View File

@@ -0,0 +1,123 @@
# Protocol Module Best Practices
## Description
Use when working with serialization and data types in `src/libxrpl/protocol/` or `include/xrpl/protocol/`. Covers STObject hierarchy, SField registry, serialization, TER codes, features, and keylets.
## Responsibility
Defines serialization formats, data types, and protocol constants. Handles conversion between C++ objects and wire format, JSON representation, and database storage. The largest module in libxrpl with 60+ files.
## Key Patterns
### STObject Hierarchy
```cpp
// STBase is the abstract root for all serializable types
// Concrete types: STInteger<N>, STBlob, STAmount, STArray, STObject, STPathSet, STVector256
// Access fields type-safely via SField references
auto amount = obj[sfAmount]; // Returns STAmount
auto flags = obj[sfFlags]; // Returns uint32
auto dest = obj[sfDestination]; // Returns AccountID
auto has = obj.isFieldPresent(sfMemos); // Check presence
```
### SField Registry
```cpp
// Fields are statically registered - never create SField at runtime
// SField carries type information and field ID
extern SField const sfAmount; // STAmount type
extern SField const sfFlags; // STInteger<uint32> type
extern SField const sfDestination; // STAccount type
// Field IDs are protocol-defined and must not change
```
### Serializer for Binary Format
```cpp
// Deterministic binary serialization
Serializer s;
obj.add(s); // Append binary representation
auto blob = s.peekData(); // Get bytes
// Deserialization
SerialIter sit(blob.data(), blob.size());
auto obj = std::make_shared<STObject>(sit, sfTransaction);
```
### Bidirectional JSON/Binary Conversion
```cpp
// Object to JSON
Json::Value json = obj.getJson(JsonOptions::none);
// JSON to Object
STParsedJSONObject parsed("tx_json", json);
if (parsed.object) { /* use parsed.object */ }
```
### TER (Transaction Error Result) Codes
```cpp
// Categories:
// tes - success (tesSUCCESS)
// tec - claimed fee, no effect (tecNO_DST, tecFROZEN, tecINSUFFICIENT_RESERVE)
// tef - failure (tefFAILURE)
// tel - local error (telNETWORK_ID_MAKES_TX_NON_CANONICAL)
// tem - malformed (temINVALID, temBAD_AMOUNT, temDISABLED)
// Check categories:
isTesSuccess(ter) // ter == tesSUCCESS
isTecClaim(ter) // tec range
isTemMalformed(ter) // tem range
```
### Feature/Amendment Flags
```cpp
// Gate new behavior on amendments
if (ctx.rules.enabled(featureMyFeature)) {
// New behavior
} else {
// Legacy behavior
}
// Register features in Feature.cpp
```
### Keylet for Ledger Entry Keys
```cpp
// Type-safe ledger key generation
auto key = keylet::account(accountID); // Account root
auto key = keylet::line(a, b, currency); // Trust line
auto key = keylet::offer(account, seq); // Offer
auto key = keylet::nftoken(tokenID); // NFT
// Keylet carries both the key (uint256) and the expected ledger entry type
```
### SOTemplate for Schema Validation
```cpp
// Define expected fields for a ledger entry type
SOTemplate const ltACCOUNT_ROOT = {
{sfAccount, soeREQUIRED},
{sfBalance, soeREQUIRED},
{sfFlags, soeREQUIRED},
{sfSequence, soeREQUIRED},
{sfOwnerCount, soeDEFAULT},
// ...
};
```
## Common Pitfalls
- Never create SField instances at runtime - they are static protocol definitions
- Never modify field IDs - they are part of the binary protocol
- Always use `isFieldPresent()` before accessing optional fields
- Never ignore TER return values - they carry critical error information
- Always gate new fields/behavior on feature amendments for consensus safety
- Respect JSON parsing depth limit of 10 to prevent stack overflow
- Use `[[nodiscard]]` on functions returning TER
## Key Files
- `include/xrpl/protocol/STObject.h` - Generic structured object container
- `include/xrpl/protocol/STAmount.h` - XRP and IOU amounts
- `include/xrpl/protocol/SField.h` - Field definitions
- `include/xrpl/protocol/TER.h` - Transaction result codes
- `include/xrpl/protocol/Feature.h` - Amendment flags
- `include/xrpl/protocol/Indexes.h` - Ledger entry key generation
- `include/xrpl/protocol/Keylet.h` - Type-safe ledger keys
- `include/xrpl/protocol/SOTemplate.h` - Object schema definitions
- `src/libxrpl/protocol/STParsedJSON.cpp` - JSON to object conversion

View File

@@ -0,0 +1,60 @@
# RDB Module Best Practices
## Description
Use when working with relational database access in `src/libxrpl/rdb/` or `include/xrpl/rdb/`. Covers SOCI wrapper, database configuration, and checkpointing.
## Responsibility
Provides a C++ wrapper around SOCI (SQLite/PostgreSQL abstraction) for relational data access, configuration management, blob type conversions, and periodic WAL checkpoint management.
## Key Patterns
### DBConfig Lazy Initialization
```cpp
// Construct config without opening connection
DBConfig config(basicConfig, "my_database");
// Open session later when needed
soci::session session;
config.open(session);
// Allows config parsing separate from database I/O
```
### Blob Conversions
```cpp
// Convert between SOCI blobs and standard types
soci::blob blob(session);
std::vector<std::uint8_t> bytes;
convert(blob, bytes); // blob -> vector
std::string str;
convert(blob, str); // blob -> string
```
### Checkpointer with Weak Pointer Safety
```cpp
// Checkpointer uses weak_ptr to detect session destruction
auto checkpointer = makeCheckpointer(
id,
std::weak_ptr<soci::session>(sessionPtr),
jobQueue,
logs);
checkpointer->schedule(); // Periodic WAL checkpoints
// If session is destroyed, checkpointer safely no-ops
```
### Thread-Safe Sessions
```cpp
// Each thread gets its own soci::session from the pool
// Never share a soci::session across threads
```
## Common Pitfalls
- Never share a soci::session across threads - each thread needs its own
- Always use `std::weak_ptr` for session references in long-lived objects (like Checkpointer)
- Be aware of SOCI include warnings - use pragma diagnostic push/pop
- Always convert blobs to standard types before processing
## Key Files
- `include/xrpl/rdb/SociDB.h` - Main wrapper interface
- `src/libxrpl/rdb/SociDB.cpp` - Implementation
- `src/libxrpl/rdb/DatabaseCon.cpp` - Database connection setup

View File

@@ -0,0 +1,64 @@
# Resource Module Best Practices
## Description
Use when working with rate limiting and resource management in `src/libxrpl/resource/` or `include/xrpl/resource/`. Covers endpoint tracking, charge/fee management, and abuse prevention.
## Responsibility
Tracks resource consumption by network endpoints (inbound/outbound connections) to prevent abuse and ensure fair resource allocation. Manages consumer lifecycle, charge accounting, and gossip-based reputation sharing.
## Key Patterns
### Manager/Impl Pattern
```cpp
// Abstract Manager interface with factory function
class Manager { virtual ~Manager() = 0; };
std::unique_ptr<Manager> make_Manager(beast::Journal journal);
// Implementation hidden in cpp
class ManagerImp : public Manager { /* ... */ };
```
### Consumer Factory
```cpp
// Different consumer types for different connection sources
Consumer newInboundEndpoint(beast::IP::Endpoint const& address);
Consumer newOutboundEndpoint(beast::IP::Endpoint const& address);
Consumer newUnlimitedEndpoint(beast::IP::Endpoint const& address);
```
### Background Thread Shutdown
```cpp
// Clean shutdown pattern with condition variable
~ManagerImp() {
{
std::lock_guard lock(mutex_);
stop_ = true;
cond_.notify_one();
}
thread_.join(); // Wait for thread to finish
}
```
### Proxy-Aware Endpoint Detection
```cpp
// Handle forwarded-for headers safely
boost::system::error_code ec;
auto proxiedIp = boost::asio::ip::make_address(forwardedFor, ec);
if (ec) {
journal_.warn() << "Invalid IP: " << ec.message();
return newInboundEndpoint(address); // Fallback to socket IP
}
```
## Common Pitfalls
- Never trust forwarded-for headers without proxy flag validation
- Always use the factory methods - never construct Consumer directly
- Always join background threads in destructor
- Use separate consumer types for different connection trust levels
## Key Files
- `include/xrpl/resource/ResourceManager.h` - Manager interface
- `src/libxrpl/resource/ResourceManager.cpp` - Implementation
- `include/xrpl/resource/Consumer.h` - Per-endpoint tracking
- `src/libxrpl/resource/Charge.cpp` - Cost definitions
- `src/libxrpl/resource/Fees.cpp` - Fee calculations

View File

@@ -0,0 +1,68 @@
# Server Module Best Practices
## Description
Use when working with server configuration in `src/libxrpl/server/` or `include/xrpl/server/`. Covers port configuration, SSL/TLS, WebSocket options, and authentication.
## Responsibility
Manages server listening ports, WebSocket configuration, SSL/TLS setup, authentication credentials, and admin network restrictions. Handles parsing configuration into validated port structures.
## Key Patterns
### Dual ParsedPort/Port Pattern
```cpp
// ParsedPort: intermediate parsing result (may be incomplete)
struct ParsedPort { /* partially validated fields */ };
// Port: final validated configuration (ready to use)
struct Port {
std::string name;
boost::asio::ip::address ip;
std::uint16_t port = 0;
std::set<std::string, iless> protocol;
// ...
};
```
### Configuration Section Parsing
```cpp
// Parse from config file section, log errors to stream
void parse_Port(ParsedPort& port, Section const& section, std::ostream& log);
// Does NOT throw - logs issues and sets defaults
```
### CIDR Admin Networks
```cpp
// IP-based admin access control with CIDR support
std::vector<boost::asio::ip::network_v4> admin_nets_v4;
std::vector<boost::asio::ip::network_v6> admin_nets_v6;
// Supports both IPv4 and IPv6 ranges
```
### WebSocket Options
```cpp
// Fine-grained compression control
boost::beast::websocket::permessage_deflate pmd_options;
// Queue limits prevent memory exhaustion
std::optional<std::uint16_t> ws_queue_limit;
// limit=0 means unlimited (not -1)
```
### SSL Context Lazy Creation
```cpp
// SSL context created only when needed
std::shared_ptr<boost::asio::ssl::context> context;
// Initialized when first SSL connection established
```
## Common Pitfalls
- Never use port-only access control - always use CIDR network restrictions for admin
- Use `iless` comparator for protocol names (case-insensitive)
- Remember that `limit=0` means unlimited, not disabled
- Always log parsing errors rather than throwing
- Separate user/admin credentials - don't reuse
## Key Files
- `include/xrpl/server/Port.h` - Port configuration structure
- `src/libxrpl/server/Port.cpp` - Parsing and validation
- `src/libxrpl/server/JSONRPCUtil.cpp` - RPC utility functions
- `src/libxrpl/server/LoadFeeTrack.cpp` - Load and fee tracking

View File

@@ -0,0 +1,83 @@
# SHAMap Module Best Practices
## Description
Use when working with the Merkle tree implementation in `src/libxrpl/shamap/` or `include/xrpl/shamap/`. Covers the SHA-256 based radix tree used for ledger state representation.
## Responsibility
Implements a SHA-256 based Merkle radix tree with 16-way branching (hexadecimal). Provides efficient ledger state representation with O(log N) proof-of-inclusion, copy-on-write snapshots, synchronization, and delta calculation.
## Key Patterns
### State Machine Lifecycle
```cpp
enum class SHAMapState { Modifying, Immutable, Synching, Invalid };
// Modifying: Can add/remove/modify entries
// Immutable: Snapshot - no modifications allowed
// Synching: Being synchronized from peers
// Invalid: Corrupted or destroyed
// Transitions are one-way: Modifying -> Immutable (via snapshot)
```
### Copy-on-Write via COWID
```cpp
std::uint32_t cowid_ = 1;
// Each snapshot gets a new COWID
// Children are only copied when modified (lazy copy)
// Immutable snapshots share nodes with the active map
auto snapshot = map.snapShot(true); // Creates immutable copy
```
### 16-Way Radix Branching
```cpp
static inline constexpr unsigned int branchFactor = 16;
static inline constexpr unsigned int leafDepth = 64;
// 256-bit key / 4 bits per nibble = 64 levels max
// Each inner node has up to 16 children
```
### Node Type Hierarchy
```cpp
// SHAMapTreeNode (base) -> SHAMapInnerNode (16 children)
// -> SHAMapLeafNode (data + key)
// Use dynamic_pointer_cast for safe downcasting
auto inner = intr_ptr::dynamic_pointer_cast<SHAMapInnerNode>(node);
if (inner) { /* process inner node */ }
```
### Walk-Up for Modifications (dirtyUp)
```cpp
// After modifying a leaf, propagate hash changes to root
void dirtyUp(SharedPtrNodeStack& stack, uint256 const& target, ...);
// Updates hashes from leaf -> root through the stack
```
### Lazy Traversal
```cpp
// Navigate to a leaf by key
SHAMapLeafNode* walkTowardsKey(uint256 const& id,
SharedPtrNodeStack* stack = nullptr);
// Returns leaf or nullptr; optionally records path for dirtyUp
```
### Intrusive Pointers for Nodes
```cpp
// Nodes use intrusive reference counting (not std::shared_ptr)
intr_ptr::SharedPtr<SHAMapTreeNode> root_;
// Minimal overhead - reference count embedded in node
```
## Common Pitfalls
- Never modify an Immutable map - check state before mutations
- Always call dirtyUp after modifying a leaf to maintain hash integrity
- Never assume node type without dynamic_pointer_cast check
- Remember that snapshots share nodes - COW means nodes are only copied on write
- Always use the provided iterators for safe traversal, not manual tree walking
## Key Files
- `include/xrpl/shamap/SHAMap.h` - Main map implementation
- `include/xrpl/shamap/SHAMapTreeNode.h` - Base node class
- `include/xrpl/shamap/SHAMapInnerNode.h` - Interior nodes (16-way)
- `include/xrpl/shamap/SHAMapLeafNode.h` - Leaf nodes with data
- `include/xrpl/shamap/SHAMapNodeID.h` - Tree position identifier
- `src/libxrpl/shamap/SHAMapDelta.cpp` - Difference between maps
- `src/libxrpl/shamap/SHAMapSync.cpp` - Synchronization algorithm

View File

@@ -0,0 +1,137 @@
# Transaction (tx) Module Best Practices
## Description
Use when working with transaction processing in `src/libxrpl/tx/` or `include/xrpl/tx/`. Covers the Transactor base class, transaction pipeline, invariant checks, and apply context.
## Responsibility
Implements the transaction processing pipeline: static validation (preflight), fee-claim checks (preclaim), transaction execution (doApply), and post-apply invariant verification. All transaction types derive from the Transactor base class.
## Key Patterns
### Transaction Pipeline (3 Phases)
```cpp
// Phase 1: Preflight - Static validation, NO ledger access
static NotTEC preflight(PreflightContext const& ctx) {
if (ctx.tx[sfAmount] <= beast::zero)
return temBAD_AMOUNT;
return tesSUCCESS;
}
// Phase 2: Preclaim - Ledger read-only checks
static TER preclaim(PreclaimContext const& ctx) {
auto sle = ctx.view.read(keylet::account(ctx.tx[sfAccount]));
if (!sle) return tecNO_DST;
return tesSUCCESS;
}
// Phase 3: doApply - Actual ledger mutations
TER doApply() override {
auto sle = view().peek(keylet::account(account_));
sle->setFieldAmount(sfBalance, newBalance);
view().update(sle);
return tesSUCCESS;
}
```
### Transactor Base Class
```cpp
class MyTransaction : public Transactor {
public:
static constexpr ConsequencesFactoryType ConsequencesFactory{Normal};
explicit MyTransaction(ApplyContext& ctx) : Transactor(ctx) {}
// Optional: Gate on amendment
static bool checkExtraFeatures(PreflightContext const& ctx);
// Optional: Custom flag mask
static std::uint32_t getFlagsMask(PreflightContext const& ctx);
// Required
static NotTEC preflight(PreflightContext const& ctx);
static TER preclaim(PreclaimContext const& ctx);
TER doApply() override;
// Optional: Custom fee calculation
static XRPAmount calculateBaseFee(ReadView const& view, STTx const& tx);
};
```
### Feature Gating
```cpp
static bool checkExtraFeatures(PreflightContext const& ctx) {
// Return false to disable when amendment not enabled
return ctx.rules.enabled(featureMyFeature);
}
```
### Flag Validation
```cpp
static std::uint32_t getFlagsMask(PreflightContext const& ctx) {
return tfMyTransactionMask; // Allowed flags
}
// Base class validates: (tx.getFlags() & ~getFlagsMask()) == 0
```
### ConsequencesFactory Types
```cpp
// Normal: Standard transaction
static constexpr ConsequencesFactoryType ConsequencesFactory{Normal};
// Blocker: Affects subsequent transactions' ability to claim fees
static constexpr ConsequencesFactoryType ConsequencesFactory{Blocker};
// Custom: Override makeTxConsequences() static method
static constexpr ConsequencesFactoryType ConsequencesFactory{Custom};
```
### TER Error Code Progression
```
tem* (malformed): temINVALID, temBAD_AMOUNT, temDISABLED - preflight errors
tef* (failure): tefFAILURE, tefNESTED_FAILURE - infrastructure errors
tel* (local): telNETWORK_ID_MAKES_TX_NON_CANONICAL - local-only errors
tec* (claimed): tecNO_DST, tecFROZEN, tecINSUFFICIENT_RESERVE - fee claimed, no effect
tes (success): tesSUCCESS - transaction applied
```
### Logging Convention
```cpp
JLOG(ctx.j.warn()) << "User error message"; // User-facing issues
JLOG(ctx.j.debug()) << "Detailed diagnostic"; // Implementation details
JLOG(ctx.j.trace()) << "Very verbose info"; // Deep debugging
JLOG(ctx.j.error()) << "Unexpected failure"; // Should not happen
```
### View Operations in doApply
```cpp
// Read-only (returns const SLE)
auto sle = view().read(keylet::account(accountID));
// Mutable (returns non-const SLE)
auto sle = view().peek(keylet::account(accountID));
sle->setFieldAmount(sfBalance, newBalance);
view().update(sle); // MUST call after modification
// Create new entry
auto sle = std::make_shared<SLE>(keylet::myEntry(id));
sle->setFieldText(sfData, data);
view().insert(sle);
// Remove entry
view().erase(sle);
```
## Common Pitfalls
- Never access ledger state in preflight - it only has PreflightContext (no view)
- Never mutate ledger state in preclaim - it has ReadView only
- Always call `view().update(sle)` after modifying a peeked SLE
- Never return `tesSUCCESS` from preclaim/preflight if validation failed
- Always gate new transaction types on feature amendments
- Use `NotTEC` return type for preflight (not TER) - prevents returning tec codes from static checks
- Never forget to register new transaction types in `transactions.macro` and `applySteps.cpp`
## Key Files
- `include/xrpl/tx/Transactor.h` - Base class with static method signatures
- `src/libxrpl/tx/Transactor.cpp` - Base implementation (41KB)
- `src/libxrpl/tx/apply.cpp` - Transaction application entry point
- `src/libxrpl/tx/ApplyContext.cpp` - Context management
- `src/libxrpl/tx/InvariantCheck.cpp` - Post-apply invariant validation (117KB)
- `src/libxrpl/tx/applySteps.cpp` - Step-by-step dispatch

View File

@@ -0,0 +1,72 @@
# Transaction Paths Module Best Practices
## Description
Use when working with payment path finding and execution in `src/libxrpl/tx/paths/` or `include/xrpl/tx/paths/`. Covers the flow engine, ripple calculation, and offer stream processing.
## Responsibility
Implements payment path finding and execution for cross-currency payments. Handles the flow engine for executing payments across multiple paths (strands), offer book management, and amount calculation.
## Key Patterns
### Flow Engine Entry Point
```cpp
path::RippleCalc::Output flow(
PaymentSandbox& view,
STAmount const& deliver,
AccountID const& src,
AccountID const& dst,
STPathSet const& paths,
bool defaultPaths,
bool partialPayment,
bool ownerPaysTransferFee,
OfferCrossing offerCrossing,
std::optional<Quality> const& limitQuality,
std::optional<STAmount> const& sendMax,
std::optional<uint256> const& domainID,
beast::Journal j,
path::detail::FlowDebugInfo* flowDebugInfo = nullptr);
```
### Strand-Based Execution
```cpp
// A "strand" is a single payment path through the DEX
// Multiple strands can be tried to find the best rate
// StrandFlow executes a single strand
// Flow tries all strands and picks the best result
```
### OfferStream for Order Book Processing
```cpp
// Iterates through offers in an order book
// Handles expired offers, unfunded offers, and self-crossing
// Automatically cleans up stale offers during traversal
```
### Quality-Based Routing
```cpp
// Quality = exchange rate between input and output
// Lower quality number = better rate
// limitQuality prevents accepting rates worse than threshold
```
### PaymentSandbox Isolation
```cpp
// All path calculations happen in a PaymentSandbox
// Changes are only committed if the payment succeeds
// Allows trying multiple paths without side effects
```
## Common Pitfalls
- Never modify the ledger directly during path calculation - use PaymentSandbox
- Always respect limitQuality to prevent unfavorable exchange rates
- Be aware that offer traversal may clean up stale offers as a side effect
- FlowDebugInfo is optional and only for debugging - never rely on it in production logic
- Path finding is computationally expensive - respect depth and complexity limits
## Key Files
- `include/xrpl/tx/paths/Flow.h` - Main flow engine entry point
- `include/xrpl/tx/paths/RippleCalc.h` - Payment amount calculation
- `src/libxrpl/tx/paths/OfferStream.cpp` - Order book traversal (~12KB)
- `src/libxrpl/tx/paths/BookTip.cpp` - Order book tip management
- `src/libxrpl/tx/paths/detail/Steps.h` - Step-by-step calculation
- `src/libxrpl/tx/paths/detail/StrandFlow.h` - Single path execution

View File

@@ -0,0 +1,164 @@
# Transactors Module Best Practices
## Description
Use when adding or modifying transaction types in `src/libxrpl/tx/transactors/`. This is the guide for implementing new transactors following the established patterns.
## Responsibility
Contains all concrete transaction type implementations. Each transactor follows the Transactor base class pattern with preflight/preclaim/doApply phases. Transaction types are organized by feature area in subdirectories.
## Template for New Transactors
### Header File (`include/xrpl/tx/transactors/MyTx.h`)
```cpp
#pragma once
#include <xrpl/tx/Transactor.h>
namespace xrpl {
class MyTransaction : public Transactor {
public:
static constexpr ConsequencesFactoryType ConsequencesFactory{Normal};
explicit MyTransaction(ApplyContext& ctx) : Transactor(ctx) {}
static bool checkExtraFeatures(PreflightContext const& ctx);
static std::uint32_t getFlagsMask(PreflightContext const& ctx);
static NotTEC preflight(PreflightContext const& ctx);
static TER preclaim(PreclaimContext const& ctx);
TER doApply() override;
};
}
```
### Implementation File (`src/libxrpl/tx/transactors/MyFeature/MyTx.cpp`)
```cpp
#include <xrpl/tx/transactors/MyTx.h>
#include <xrpl/ledger/View.h>
#include <xrpl/protocol/Feature.h>
#include <xrpl/protocol/Indexes.h>
#include <xrpl/protocol/TxFlags.h>
namespace xrpl {
bool
MyTransaction::checkExtraFeatures(PreflightContext const& ctx)
{
return ctx.rules.enabled(featureMyFeature);
}
std::uint32_t
MyTransaction::getFlagsMask(PreflightContext const& ctx)
{
return tfUniversalMask; // Or custom mask
}
NotTEC
MyTransaction::preflight(PreflightContext const& ctx)
{
// Static validation - NO ledger access
auto const& tx = ctx.tx;
if (tx[sfAmount] <= beast::zero)
{
JLOG(ctx.j.warn()) << "Bad amount.";
return temBAD_AMOUNT;
}
return tesSUCCESS;
}
TER
MyTransaction::preclaim(PreclaimContext const& ctx)
{
// Ledger read-only checks
auto const sle = ctx.view.read(
keylet::account(ctx.tx[sfAccount]));
if (!sle)
return terNO_ACCOUNT;
return tesSUCCESS;
}
TER
MyTransaction::doApply()
{
// Mutate ledger state
auto sle = view().peek(keylet::account(account_));
if (!sle)
return tefINTERNAL;
sle->setFieldAmount(sfBalance, newBalance);
view().update(sle);
return tesSUCCESS;
}
}
```
### Registration Checklist
1. Add transaction type to `include/xrpl/protocol/detail/transactions.macro`
2. Add dispatch case to `src/libxrpl/tx/applySteps.cpp`
3. Add feature flag to `include/xrpl/protocol/Feature.h` and `src/libxrpl/protocol/Feature.cpp`
4. Add invariant checks if needed in `src/libxrpl/tx/InvariantCheck.cpp`
5. Add to `disabledTxTypes` in Batch.cpp if not batch-compatible
## Key Patterns Across All Transactors
### Feature Gating
```cpp
static bool checkExtraFeatures(PreflightContext const& ctx) {
return ctx.rules.enabled(featureMyFeature);
}
```
### Variant-Aware Validation
```cpp
// When handling Asset (Issue or MPTIssue):
if (auto const ret = std::visit(
[&]<typename T>(T const&) { return preflightHelper<T>(ctx); },
ctx.tx[sfAmount].asset().value()); !isTesSuccess(ret))
return ret;
```
### Ledger Entry CRUD in doApply
```cpp
// Create
auto sle = std::make_shared<SLE>(keylet::myEntry(id));
view().insert(sle);
// Read (mutable)
auto sle = view().peek(keylet::myEntry(id));
// Update
sle->setFieldU32(sfFlags, newFlags);
view().update(sle);
// Delete
view().erase(sle);
```
### Helper/Utils Files
```cpp
// Complex features use a separate Helpers/Utils file:
// AMM -> AMMHelpers.h, AMMUtils.h
// NFT -> NFTokenUtils.h
// Lending -> LendingHelpers.h
// Keep reusable logic in helpers, transaction-specific logic in transactors
```
## Common Pitfalls
- Never forget to register in `transactions.macro` and `applySteps.cpp`
- Never access ledger state in preflight (no view available)
- Never mutate state in preclaim (read-only view)
- Always call `view().update(sle)` after modifying a peeked entry
- Always gate on feature amendment for consensus safety
- Use `NotTEC` return type from preflight, `TER` from preclaim/doApply
- Put shared logic in a *Helpers.h file, not duplicated across transactors
## Key Files
- `include/xrpl/tx/Transactor.h` - Base class definition
- `src/libxrpl/tx/applySteps.cpp` - Transaction type dispatch
- `include/xrpl/protocol/detail/transactions.macro` - Transaction type registry
- `src/libxrpl/tx/InvariantCheck.cpp` - Post-apply validation

View File

@@ -0,0 +1,68 @@
# AMM (Automated Market Maker) Transactors Best Practices
## Description
Use when working with AMM transaction types in `src/libxrpl/tx/transactors/AMM/`. Covers pool creation, deposits, withdrawals, voting, bidding, deletion, and clawback.
## Responsibility
Implements decentralized trading pools with liquidity provider (LP) tokens. Allows users to create AMM pools, deposit/withdraw liquidity, vote on trading fees, bid on auction slots, and manage pool lifecycle.
## Key Patterns
### AMM Transaction Types
- **AMMCreate** - Create a new AMM pool with two assets
- **AMMDeposit** - Add liquidity to a pool, receive LP tokens
- **AMMWithdraw** - Remove liquidity, burn LP tokens
- **AMMVote** - Vote on trading fee percentage
- **AMMBid** - Bid on the auction slot for discounted trading
- **AMMDelete** - Remove an empty AMM pool
- **AMMClawback** - Issuer clawback of assets from AMM
### Precision Arithmetic
```cpp
// AMM calculations require controlled rounding
// ALWAYS use NumberRoundModeGuard for rounding control
NumberRoundModeGuard mg(Number::towards_zero);
auto lpTokens = ammLPTokens(amount1, amount2, lptIssue);
// Or explicit mode changes with RAII save
{
saveNumberRoundMode _{Number::getround()};
Number::setround(Number::upward);
auto value = calculation;
}
```
### Helper Functions (AMMHelpers.h)
```cpp
ammLPTokens() // Calculate LP tokens from pool reserves
lpTokensOut() // LP tokens from deposit
ammAssetIn() / ammAssetOut() // Calculate swap amounts
withinRelativeDistance() // Quality tolerance checks
changeSpotPriceQuality() // Quote generation algorithm
// Quadratic equation solving for pricing
```
### Feature Gates
```cpp
// Multiple amendment versions
ammEnabled(ctx.rules) // Base AMM feature
fixAMMv1_1 // First fix amendment
fixAMMv1_3 // Third fix amendment
// Always check which amendments are active
```
## Common Pitfalls
- Never perform AMM math without setting the rounding mode first
- Always use `NumberRoundModeGuard` (RAII) - never manually set/restore rounding
- Be aware that AMM calculations involve quadratic equations - precision matters
- AMMClawback has different authorization requirements than regular clawback
- Check `withinRelativeDistance` for quality tolerance rather than exact equality
## Key Files
- `src/libxrpl/tx/transactors/AMM/AMMCreate.cpp` - Pool creation
- `src/libxrpl/tx/transactors/AMM/AMMDeposit.cpp` - Liquidity deposit (~887 lines)
- `src/libxrpl/tx/transactors/AMM/AMMWithdraw.cpp` - Liquidity withdrawal (~911 lines)
- `src/libxrpl/tx/transactors/AMM/AMMVote.cpp` - Fee voting
- `src/libxrpl/tx/transactors/AMM/AMMBid.cpp` - Auction slot bidding
- `include/xrpl/tx/transactors/AMM/AMMHelpers.h` - Shared math utilities
- `include/xrpl/tx/transactors/AMM/AMMUtils.h` - AMM state utilities

View File

@@ -0,0 +1,44 @@
# Check Transactors Best Practices
## Description
Use when working with Check transaction types in `src/libxrpl/tx/transactors/Check/`. Covers check creation, cashing, and cancellation.
## Responsibility
Implements a check-like payment mechanism (delayed payment authorization). A sender creates a check, the recipient cashes it, and either party can cancel it (with expiration support).
## Key Patterns
### Check Lifecycle
```cpp
// 1. CreateCheck - Sender authorizes payment
// Validates: destination exists, amount valid, expiration future
// Creates: Check ledger entry with sender, destination, amount
// 2. CashCheck - Recipient claims payment
// Validates: caller is destination, check not expired
// Executes: transfers funds from sender to destination
// 3. CancelCheck - Either party cancels
// Validates: caller is sender or destination, or check expired
// Removes: Check ledger entry
```
### Error Codes
```cpp
tecNO_DST // Destination account doesn't exist
temREDUNDANT // Check to self
temBAD_AMOUNT // Invalid amount
temBAD_EXPIRATION // Expiration in the past
tecEXPIRED // Check has expired (for CashCheck)
```
## Common Pitfalls
- Checks can be cancelled by either sender or destination
- Expired checks can be cancelled by anyone
- CashCheck must handle both exact amount and "deliver minimum" modes
- Always validate expiration against the parent ledger close time
## Key Files
- `src/libxrpl/tx/transactors/Check/CreateCheck.cpp` - Check creation
- `src/libxrpl/tx/transactors/Check/CashCheck.cpp` - Check fulfillment (~440 lines)
- `src/libxrpl/tx/transactors/Check/CancelCheck.cpp` - Check cancellation

View File

@@ -0,0 +1,43 @@
# Delegate Transactors Best Practices
## Description
Use when working with delegation transaction types in `src/libxrpl/tx/transactors/Delegate/`. Covers delegate set and utilities.
## Responsibility
Manages transaction signing delegation, allowing accounts to authorize other accounts to sign transactions on their behalf without exposing the master key.
## Key Patterns
### Delegate Operations
```cpp
// DelegateSet - Create or modify a delegation
// Validates: delegate account exists, permissions valid
// Creates/Updates: Delegate ledger entry
// DelegateUtils - Shared utilities
// deleteDelegate() - Public cleanup interface, used by DeleteAccount
```
### Feature Gates
```cpp
// fixDelegateV1_1 - Added data existence checks
if (ctx.rules.enabled(fixDelegateV1_1)) {
// Perform additional validation
}
```
### Integration with DeleteAccount
```cpp
// DelegateUtils::deleteDelegate() is called by DeleteAccount
// for cleanup when an account is being deleted
// Must handle all delegation-related ledger entries
```
## Common Pitfalls
- Always check feature gate `fixDelegateV1_1` for data existence validation
- Delegate cleanup must be thorough - used by DeleteAccount
- Never allow self-delegation
## Key Files
- `src/libxrpl/tx/transactors/Delegate/DelegateSet.cpp` - Delegation management
- `include/xrpl/tx/transactors/Delegate/DelegateUtils.h` - Shared utilities

View File

@@ -0,0 +1,69 @@
# Lending Transactors Best Practices
## Description
Use when working with lending protocol transaction types in `src/libxrpl/tx/transactors/Lending/`. Covers loan management, broker operations, and payment calculation.
## Responsibility
Implements a complex loan protocol with amortization schedules, interest calculation, broker management, and collateral handling. The largest transactor feature area by code volume.
## Key Patterns
### Loan Lifecycle
```cpp
// LoanSet - Create or configure a loan
// LoanPay - Make loan payments (principal + interest)
// LoanManage - Manage loan state transitions
// LoanDelete - Remove a completed/cancelled loan
```
### Broker Operations
```cpp
// LoanBrokerSet - Create/configure a broker
// LoanBrokerDelete - Remove a broker
// LoanBrokerCoverDeposit - Deposit collateral
// LoanBrokerCoverWithdraw - Withdraw collateral
// LoanBrokerCoverClawback - Clawback broker assets
```
### Payment Calculation (LendingHelpers.h)
```cpp
struct LoanPaymentParts {
Number principalPaid; // Reduces loan balance
Number interestPaid; // Goes to Vault
Number valueChange; // Loan value adjustment
Number feePaid; // Goes to Broker
};
// Key helper functions:
checkLendingProtocolDependencies() // Validate feature gates
loanPeriodicRate() // Interest with secondsInYear
roundPeriodicPayment() // Consistent rounding
```
### Feature Gate
```cpp
// All lending operations gated on single feature
ctx.rules.enabled(featureLendingProtocol)
```
### Batch Transaction Restriction
```cpp
// Lending transactions are DISABLED in batch transactions
// Listed in Batch::disabledTxTypes
// Cannot be included in atomic batch operations
```
## Common Pitfalls
- Lending is disabled in Batch transactions - do not try to batch lending ops
- Payment calculations require precise rounding - use LendingHelpers functions
- Always validate lending protocol dependencies before operations
- Interest calculation uses `secondsInYear` constant - be aware of leap year handling
- LendingHelpers.h is ~1800 lines - the most complex helper file in the codebase
## Key Files
- `src/libxrpl/tx/transactors/Lending/LoanSet.cpp` - Loan configuration (~585 lines)
- `src/libxrpl/tx/transactors/Lending/LoanPay.cpp` - Payment processing (~548 lines)
- `src/libxrpl/tx/transactors/Lending/LoanManage.cpp` - State management
- `src/libxrpl/tx/transactors/Lending/LoanDelete.cpp` - Loan removal
- `src/libxrpl/tx/transactors/Lending/LoanBrokerSet.cpp` - Broker setup
- `include/xrpl/tx/transactors/Lending/LendingHelpers.h` - Shared calculations (~1799 lines)

View File

@@ -0,0 +1,53 @@
# MPT (Multi-Purpose Token) Transactors Best Practices
## Description
Use when working with MPT transaction types in `src/libxrpl/tx/transactors/MPT/`. Covers token issuance creation, configuration, destruction, and authorization.
## Responsibility
Implements Multi-Purpose Token (MPT) operations - a fungible token system simpler than full IOU trust lines. Handles token issuance lifecycle and holder authorization.
## Key Patterns
### MPT Transaction Types
```cpp
// MPTokenIssuanceCreate - Create a new token issuance
// MPTokenIssuanceSet - Modify issuance settings
// MPTokenIssuanceDestroy - Destroy an issuance (if no holders)
// MPTokenAuthorize - Authorize/deauthorize a holder
```
### MPT vs IOU Trust Lines
```cpp
// MPT is simpler than IOU trust lines:
// - No rippling mechanics
// - No transfer fees between holders (only issuer)
// - Simpler authorization model
// - Uses MPTIssue instead of Issue
// - Uses MPTAmount instead of IOUAmount
```
### Feature Gate
```cpp
ctx.rules.enabled(featureMPTokensV1)
```
### Asset Variant Handling
```cpp
// MPTIssue is part of the Asset variant (Issue | MPTIssue)
// Use std::visit when handling Asset generically:
std::visit([&](auto const& issue) {
// Works for both Issue and MPTIssue
}, asset.value());
```
## Common Pitfalls
- MPT issuances cannot be destroyed if any holders exist
- Authorization is per-holder, not per-token
- Don't confuse MPTIssue with Issue - they have different keylet types
- Always check `featureMPTokensV1` before MPT operations
## Key Files
- `src/libxrpl/tx/transactors/MPT/MPTokenIssuanceCreate.cpp` - Create issuance
- `src/libxrpl/tx/transactors/MPT/MPTokenIssuanceSet.cpp` - Modify settings
- `src/libxrpl/tx/transactors/MPT/MPTokenIssuanceDestroy.cpp` - Destroy issuance
- `src/libxrpl/tx/transactors/MPT/MPTokenAuthorize.cpp` - Holder authorization

View File

@@ -0,0 +1,76 @@
# NFT (Non-Fungible Token) Transactors Best Practices
## Description
Use when working with NFT transaction types in `src/libxrpl/tx/transactors/NFT/`. Covers minting, burning, offer management, and token modification.
## Responsibility
Implements NFT creation, trading, and lifecycle management. Handles token minting, burning, buy/sell offer creation and acceptance, offer cancellation, and dynamic NFT modification.
## Key Patterns
### NFT Transaction Types
```cpp
// NFTokenMint - Create a new NFT
// NFTokenBurn - Destroy an NFT
// NFTokenCreateOffer - Create a buy or sell offer
// NFTokenCancelOffer - Cancel an existing offer
// NFTokenAcceptOffer - Accept a buy or sell offer (execute trade)
// NFTokenModify - Modify NFT metadata (dynamic NFTs)
```
### NFTokenUtils - Shared Utilities (~1025 lines)
```cpp
// Key utility functions:
findToken() // Find an NFT in owner's token pages
insertToken() // Add NFT to owner's directory
removeToken() // Remove NFT from owner's directory
deleteTokenOffer() // Clean up a single offer
removeTokenOffersWithLimit() // Batch cleanup with limit
notTooManyOffers() // Check offer count limits
changeTokenURI() // Update NFT URI (dynamic NFTs)
struct TokenAndPage {
STObject token;
std::shared_ptr<SLE> page;
};
```
### Token Storage in Pages
```cpp
// NFTs are stored in paginated directories
// Each page holds multiple tokens
// Pages are linked as a doubly-linked list
// insertToken/removeToken manage page splits and merges
```
### Feature Gates
```cpp
featureNFTokenMintOffer // Combined mint + offer
fixRemoveNFTokenAutoTrustLine // Fix for auto trust line removal
featureDynamicNFT // NFTokenModify support
```
### Offer Directory Structure
```cpp
// Buy offers and sell offers stored in separate directories
// Indexed by token ID
// Offers can have expiration times
// Offers can specify a destination (private offers)
```
## Common Pitfalls
- Token page management is complex - always use NFTokenUtils functions
- Offer cleanup has limits (`removeTokenOffersWithLimit`) - don't assume all offers removed
- `notTooManyOffers()` must be checked before creating new offers
- Dynamic NFT modification requires `featureDynamicNFT` amendment
- Transfer fees only apply when the NFT issuer is not a party to the trade
- Burning an NFT with outstanding offers requires offer cleanup
## Key Files
- `src/libxrpl/tx/transactors/NFT/NFTokenMint.cpp` - Token minting
- `src/libxrpl/tx/transactors/NFT/NFTokenBurn.cpp` - Token destruction
- `src/libxrpl/tx/transactors/NFT/NFTokenCreateOffer.cpp` - Offer creation
- `src/libxrpl/tx/transactors/NFT/NFTokenAcceptOffer.cpp` - Offer acceptance (trade)
- `src/libxrpl/tx/transactors/NFT/NFTokenCancelOffer.cpp` - Offer cancellation
- `src/libxrpl/tx/transactors/NFT/NFTokenModify.cpp` - Dynamic NFT changes
- `include/xrpl/tx/transactors/NFT/NFTokenUtils.h` - Shared utilities (~1025 lines)

View File

@@ -0,0 +1,56 @@
# Offer Transactors Best Practices
## Description
Use when working with DEX offer transaction types in `src/libxrpl/tx/transactors/Offer/`. Covers order creation and cancellation on the native decentralized exchange.
## Responsibility
Implements decentralized exchange order management for the native XRPL order book. Handles offer creation (with matching/crossing), cancellation, and order book management.
## Key Patterns
### Offer Transaction Types
```cpp
// CreateOffer (~854 lines) - Create a new DEX order
// - Validates amounts, currency pairs, account state
// - Attempts to cross with existing offers (matching engine)
// - Remaining amount becomes a standing order if not fully filled
// - Handles self-crossing, expired offers, unfunded offers
// CancelOffer - Remove an existing order
// - Validates caller owns the offer
// - Removes offer from order book directory
```
### Offer Crossing (Matching Engine)
```cpp
// CreateOffer performs offer crossing inline:
// 1. Look up existing offers on the opposite side
// 2. Match at the offer's quality (exchange rate)
// 3. Consume matched offers (partial or full)
// 4. Place remaining amount as standing order
// This is the core DEX matching engine
```
### Quality and Order Books
```cpp
// Quality = exchange rate between TakerPays and TakerGets
// Order books indexed by currency pair and sorted by quality
// Lower quality number = better rate for taker
```
### Ticket Support
```cpp
// Offers can use tickets for sequence management
// Feature gate: featureTickets
```
## Common Pitfalls
- CreateOffer is one of the most complex transactors (~854 lines) - be thorough with changes
- Offer crossing modifies multiple ledger entries atomically
- Self-crossing (same account on both sides) has special handling
- Expired and unfunded offers are cleaned up during crossing
- Always validate that TakerPays and TakerGets are different assets
## Key Files
- `src/libxrpl/tx/transactors/Offer/CreateOffer.cpp` - Order creation and matching (~854 lines)
- `src/libxrpl/tx/transactors/Offer/CancelOffer.cpp` - Order cancellation

View File

@@ -0,0 +1,36 @@
# PermissionedDomain Transactors Best Practices
## Description
Use when working with permissioned domain transaction types in `src/libxrpl/tx/transactors/PermissionedDomain/`. Covers domain-based access control for the DEX.
## Responsibility
Implements domain-based access control for permissioned DEX operations. Allows creating and deleting permissioned domains that gate who can participate in certain trading activities.
## Key Patterns
### PermissionedDomain Transaction Types
```cpp
// PermissionedDomainSet - Create or update a permissioned domain
// PermissionedDomainDelete - Remove a permissioned domain
```
### Integration with Payments
```cpp
// Payments can reference a domain via sfDomainID field
// The domain gates which accounts can participate
// Used for regulated/permissioned trading environments
```
### Feature Gate
```cpp
ctx.rules.enabled(featurePermissionedDEX)
```
## Common Pitfalls
- Domains are referenced by other transactions (Payments) - deletion must check for references
- Always validate the feature gate before domain operations
- Domain ID matching is exact - no partial matches
## Key Files
- `src/libxrpl/tx/transactors/PermissionedDomain/PermissionedDomainSet.cpp` - Create/update domain
- `src/libxrpl/tx/transactors/PermissionedDomain/PermissionedDomainDelete.cpp` - Remove domain

View File

@@ -0,0 +1,61 @@
# Vault Transactors Best Practices
## Description
Use when working with vault transaction types in `src/libxrpl/tx/transactors/Vault/`. Covers vault creation, configuration, deposits, withdrawals, deletion, and clawback.
## Responsibility
Implements the vault mechanism for asset holding and loan collateral management. Allows creating vaults, depositing/withdrawing assets, configuring vault parameters, and managing vault lifecycle.
## Key Patterns
### Vault Transaction Types
```cpp
// VaultCreate - Create a new vault
// VaultSet - Configure vault parameters
// VaultDelete - Remove an empty vault
// VaultDeposit - Deposit assets into a vault
// VaultWithdraw - Withdraw assets from a vault
// VaultClawback - Issuer clawback from vault
```
### Feature Gate
```cpp
ctx.rules.enabled(featureSingleAssetVault)
```
### Batch Transaction Restriction
```cpp
// Vault transactions are DISABLED in batch transactions
// Listed in Batch::disabledTxTypes alongside Lending
// Cannot be included in atomic batch operations
```
### Depth Limiting for Recursive Operations
```cpp
// Vault operations may involve recursive state checks
// Use depth parameter to prevent infinite recursion
TER checkVaultState(ReadView const& view, AccountID const& id, int depth = 0);
if (depth > maxDepth) return tecINTERNAL;
```
### Integration with Lending
```cpp
// Vaults serve as collateral for the lending protocol
// VaultDeposit/Withdraw affect loan collateralization
// Vault state changes may trigger loan state recalculation
```
## Common Pitfalls
- Vault operations are disabled in batch transactions
- Vaults can only be deleted when empty
- Clawback has different authorization requirements than regular withdrawal
- Always respect depth limits in recursive vault state checks
- Vault operations may interact with lending protocol state
## Key Files
- `src/libxrpl/tx/transactors/Vault/VaultCreate.cpp` - Vault creation
- `src/libxrpl/tx/transactors/Vault/VaultSet.cpp` - Configuration
- `src/libxrpl/tx/transactors/Vault/VaultDelete.cpp` - Deletion
- `src/libxrpl/tx/transactors/Vault/VaultDeposit.cpp` - Asset deposit
- `src/libxrpl/tx/transactors/Vault/VaultWithdraw.cpp` - Asset withdrawal
- `src/libxrpl/tx/transactors/Vault/VaultClawback.cpp` - Issuer clawback

View File

@@ -0,0 +1,57 @@
# App Module Best Practices
## Description
Use when working with the main application layer in `src/xrpld/app/`. Covers the Application singleton, ledger management, consensus adapters, services, and runtime coordination.
## Responsibility
Contains the main application logic and runtime coordination for the rippled server. The Application singleton provides access to all services. Sub-modules handle ledger management, consensus, fee voting, amendments, path finding, and transaction queuing.
## Key Patterns
### Application Singleton
```cpp
// Application is the master interface - access all services through it
class Application {
virtual Config& config() = 0;
virtual Logs& logs() = 0;
virtual JobQueue& getJobQueue() = 0;
virtual LedgerMaster& getLedgerMaster() = 0;
virtual NetworkOPs& getOPs() = 0;
virtual NodeStore::Database& getNodeStore() = 0;
// ... many more service accessors
};
// Implemented by ApplicationImp (hidden in .cpp)
```
### ServiceRegistry Pattern
```cpp
// Services are injected via ServiceRegistry from libxrpl
// Application provides centralized access to all registered services
```
### Master Mutex
```cpp
// Recursive mutex protects shared state:
using MutexType = std::recursive_mutex;
// Protects: open ledger, server state, consensus engine
// Use std::lock_guard<Application::MutexType> for access
```
### Module Interface Pattern
```cpp
// Public interface: Module.h (abstract)
// Implementation: ModuleImp.h/cpp (hidden)
// Factory: make_Module() returns unique_ptr
```
## Common Pitfalls
- Never access Application services before setup() completes
- Always acquire master mutex when modifying open ledger or consensus state
- Use `std::recursive_mutex` (not plain mutex) - multiple services may lock re-entrantly
- Never create a second Application instance
## Key Files
- `src/xrpld/app/main/Application.h` - Core application interface
- `src/xrpld/app/main/Application.cpp` - Implementation (150+ includes)
- `src/xrpld/app/main/BasicApp.h` - Base application services
- `src/xrpld/app/main/GRPCServer.h` - gRPC server integration

View File

@@ -0,0 +1,47 @@
# App Consensus Module Best Practices
## Description
Use when working with RCL consensus adapters in `src/xrpld/app/consensus/`. Bridges the generic consensus algorithm to rippled-specific types.
## Responsibility
Adapts the generic consensus algorithm (in `xrpld/consensus/`) to work with rippled application types. Provides concrete type adapters for transactions, transaction sets, and ledgers.
## Key Patterns
### RCL Adapters
```cpp
// RCLCxTx - Adapts SHAMapItem as a consensus transaction
// RCLCxTxSet - Adapts SHAMap as a consensus transaction set
// RCLCxLedger - Adapts Ledger as a consensus ledger
// RCLConsensus - Glues generic consensus to rippled Application
```
### Adapter Pattern
```cpp
// Generic consensus works with abstract types via CRTP
// RCL adapters provide concrete implementations
class RCLConsensus : public Consensus<RCLConsensus> {
// Implements required methods using rippled types
// e.g., acquireLedger(), proposeTx(), relay()
};
```
### Validation Handling
```cpp
// RCLValidations tracks validation messages from the network
// Maps to the generic Validations<> template
// Handles trusted vs untrusted validators
```
## Common Pitfalls
- Adapter methods must match the CRTP interface exactly - compiler errors are cryptic
- Never import generic consensus types into adapter code - always go through the adapter
- RCLConsensus holds references to Application services - ensure Application outlives it
## Key Files
- `src/xrpld/app/consensus/RCLConsensus.h` - Main consensus orchestrator
- `src/xrpld/app/consensus/RCLConsensus.cpp` - Implementation
- `src/xrpld/app/consensus/RCLValidations.h` - Validation handling
- `src/xrpld/app/consensus/RCLCxTx.h` - Transaction adapter
- `src/xrpld/app/consensus/RCLCxTxSet.h` - Transaction set adapter
- `src/xrpld/app/consensus/RCLCxLedger.h` - Ledger adapter

View File

@@ -0,0 +1,67 @@
# App Ledger Module Best Practices
## Description
Use when working with ledger management in `src/xrpld/app/ledger/`. Covers ledger storage, retrieval, history, and the Ledger class itself.
## Responsibility
Manages the lifecycle of ledger objects: creation, storage, retrieval, history tracking, inbound acquisition from network, and order book caching. The Ledger class is the central data structure.
## Key Patterns
### Ledger Class
```cpp
// Ledger is composed of two SHAMaps:
// 1. State Map - Account roots, order books, ledger entries (STLedgerEntry)
// 2. Transaction Map - Transactions and metadata for that ledger
class Ledger final : public std::enable_shared_from_this<Ledger>,
public CountedObject<Ledger> {
// Can be mutable (sole ownership) or immutable (shared, read-only)
// Genesis ledger has special constructor
};
```
### Mutable vs Immutable
```cpp
// Mutable: Only one owner, can be modified
// Immutable: Shared via shared_ptr, read-only
// Transition: mutable -> immutable when accepted
// Never modify an immutable ledger
```
### LedgerMaster
```cpp
// Manages the chain of validated ledgers
// Tracks: current, validated, closed ledgers
// Handles ledger transitions during consensus
```
### Inbound Ledger Acquisition
```cpp
// InboundLedgers manages acquiring missing ledgers from peers
// InboundTransactions handles transaction set acquisition
// Both use async fetch with timeout and retry
```
### Iterator Adapters
```cpp
// sles_iter_impl - Iterate over SLE (state entries)
// txs_iter_impl - Iterate over transactions
// Efficient iteration without copying
```
## Common Pitfalls
- Never modify an immutable ledger - check mutability first
- Ledger must be shared via shared_ptr (enable_shared_from_this)
- Genesis ledger construction is special - don't use for normal ledgers
- LedgerMaster state transitions must be atomic with consensus
- CountedObject tracking helps detect leaks - don't disable it
## Key Files
- `src/xrpld/app/ledger/Ledger.h` - Core ledger class
- `src/xrpld/app/ledger/LedgerMaster.h` - Ledger chain management
- `src/xrpld/app/ledger/LedgerHistory.h` - Historical tracking
- `src/xrpld/app/ledger/LedgerCleaner.h` - Online deletion
- `src/xrpld/app/ledger/InboundLedgers.h` - Network acquisition
- `src/xrpld/app/ledger/OrderBookDB.h` - Order book cache
- `src/xrpld/app/ledger/TransactionMaster.h` - Transaction lookup

View File

@@ -0,0 +1,18 @@
# App Ledger Detail Module Best Practices
## Description
Use when working with ledger implementation details in `src/xrpld/app/ledger/detail/`. Internal helpers for the ledger module.
## Responsibility
Internal implementation details for the app/ledger module. Contains private helpers for ledger state management, iteration, and storage operations.
## Key Patterns
### Detail Namespace Convention
- Code in `detail/` is internal to the `app/ledger` module
- Never include detail headers from outside `app/ledger`
- If you need functionality, use the public `app/ledger/` headers instead
## Common Pitfalls
- Detail implementations may change without API compatibility
- Never expose detail types in public interfaces

View File

@@ -0,0 +1,54 @@
# App Main Module Best Practices
## Description
Use when working with application initialization and lifecycle in `src/xrpld/app/main/`. Covers Application startup, shutdown, and core services.
## Responsibility
Application initialization, lifecycle management, and core service wiring. Contains the Application interface and its implementation, gRPC server, load management, node identity, and the node store scheduler.
## Key Patterns
### Application Lifecycle
```cpp
// 1. Construct Application (parse config, create services)
// 2. setup() - Initialize all services, open databases
// 3. run() - Main event loop
// 4. signalStop() - Graceful shutdown
// 5. Destructor - Clean up resources
```
### Node Identity
```cpp
// NodeIdentity manages the node's public/private key pair
// Used for peer handshake, session signatures, and cluster membership
// Keys persisted in wallet_db
```
### Load Manager
```cpp
// Tracks server load across all subsystems
// Triggers load-based fee escalation
// Monitors job queue depth and execution time
```
### gRPC Server
```cpp
// Optional gRPC server alongside JSON-RPC
// Uses proto definitions from include/xrpl/proto/
// Separate handler set from JSON-RPC
```
## Common Pitfalls
- setup() must complete before any service is used
- signalStop() should be called for graceful shutdown - avoid hard kills
- Node identity keys must never be logged or exposed
- Load manager affects fee escalation - test under load
## Key Files
- `src/xrpld/app/main/Application.h` - Core interface
- `src/xrpld/app/main/Application.cpp` - Implementation
- `src/xrpld/app/main/BasicApp.h` - Base services
- `src/xrpld/app/main/GRPCServer.h` - gRPC integration
- `src/xrpld/app/main/LoadManager.h` - Load tracking
- `src/xrpld/app/main/NodeIdentity.h` - Node key management
- `src/xrpld/app/main/NodeStoreScheduler.h` - Async DB scheduler

View File

@@ -0,0 +1,75 @@
# App Misc Module Best Practices
## Description
Use when working with application services in `src/xrpld/app/misc/`. Covers fee voting, amendments, SHAMapStore, transaction queue, validator management, and NetworkOPs.
## Responsibility
Collection of application-level services: fee voting system, amendment mechanism, online deletion (SHAMapStore), transaction queue (TxQ), validator key/list management, and NetworkOPs (the central operations coordinator).
## Key Patterns
### Fee Voting
```cpp
// Validators vote on fee schedules every 256 ledgers ("voting ledgers")
// Pseudo-transactions injected to set fees
// Majority vote determines new fee schedule
// FeeVote.h - voting logic
// FeeEscalation.md - escalation documentation
```
### Amendment Mechanism
```cpp
// Network-wide ledger rule changes
// Requires 80% validator approval sustained for 2 weeks
// Tracked as pseudo-transactions in each ledger
// AmendmentTableImpl.h manages tracking and state
```
### SHAMapStore (Online Delete)
```cpp
// Prunes old ledger history automatically
// Uses rotation between two databases
// Configurable deletion intervals
// Must not delete data needed for active operations
```
### Transaction Queue (TxQ)
```cpp
// Queues transactions when ledger is full
// Priority based on fee level
// Handles fee escalation under load
// TxQ.h - queue implementation
```
### Validator Management
```cpp
// ValidatorKeys.h - Node's own validator keys
// ValidatorList.h - Trusted validator list (UNL)
// ValidatorSite.h - Sites serving validator lists
// Keys loaded from config, lists fetched from URLs
```
### NetworkOPs
```cpp
// Central operations coordinator - the "god object"
// Coordinates: consensus, ledger acceptance, transaction submission
// NetworkOPs.cpp is one of the largest files in the codebase
// Access via app.getOPs()
```
## Common Pitfalls
- Fee voting only happens on voting ledgers (every 256) - don't trigger manually
- Amendments require 2-week sustained 80% approval - no fast path
- SHAMapStore deletion must respect the advisory_delete safety window
- TxQ priority depends on current fee escalation level
- NetworkOPs is massive - changes here affect many systems
## Key Files
- `src/xrpld/app/misc/FeeVote.h` - Fee voting system
- `src/xrpld/app/misc/AmendmentTableImpl.h` - Amendment tracking
- `src/xrpld/app/misc/SHAMapStore.h` - Online deletion
- `src/xrpld/app/misc/TxQ.h` - Transaction queue
- `src/xrpld/app/misc/ValidatorKeys.h` - Validator key management
- `src/xrpld/app/misc/ValidatorList.h` - Trusted validator list
- `src/xrpld/app/misc/NetworkOPs.cpp` - Central operations
- `src/xrpld/app/misc/README.md` - Architecture documentation

View File

@@ -0,0 +1,18 @@
# App Misc Detail Module Best Practices
## Description
Use when working with internal service implementation details in `src/xrpld/app/misc/detail/`. Internal helpers for the misc services module.
## Responsibility
Internal implementation details for app/misc services (fee voting internals, amendment table implementation, SHAMapStore internals, etc.).
## Key Patterns
### Detail Namespace Convention
- Code in `detail/` is internal to the `app/misc` module
- Implementation classes (e.g., AmendmentTableImpl) live here
- Never include detail headers from outside `app/misc`
## Common Pitfalls
- Detail implementations may change without API compatibility
- Always use the public `app/misc/` interfaces

View File

@@ -0,0 +1,53 @@
# App Paths Module Best Practices
## Description
Use when working with payment path finding in `src/xrpld/app/paths/`. Covers the path finding algorithm, trust line caching, and AMM liquidity integration.
## Responsibility
Implements the XRP Ledger payment path finding algorithm at the application level. Manages path requests, trust line caching, and integration with Automated Market Maker liquidity.
## Key Patterns
### Path Finding
```cpp
// Pathfinder: Algorithm that finds payment paths between accounts
// Considers: trust lines, order books, AMM pools
// Returns: Set of paths ranked by cost/quality
```
### Path Request Management
```cpp
// PathRequest - Individual path find request
// PathRequests - Manages collection of active requests
// Requests can be one-shot or subscribed (streaming updates)
```
### Trust Line Caching
```cpp
// RippleLineCache caches trust line data
// Avoids repeated ledger lookups during path finding
// Cache is invalidated on ledger close
// TrustLine.h provides the trust line representation
```
### AMM Integration
```cpp
// AMMLiquidity.h - Integrates AMM pools into path finding
// AMMOffer.h - Represents AMM as a synthetic offer
// AMM pools are treated as a special offer type in the path finder
```
## Common Pitfalls
- Path finding is computationally expensive - respect search depth limits
- Trust line cache must be invalidated on ledger close
- AMM liquidity changes with pool state - don't cache AMM offers across ledgers
- Path subscriptions can be memory-intensive with many clients
## Key Files
- `src/xrpld/app/paths/Pathfinder.h` - Path finding algorithm
- `src/xrpld/app/paths/PathRequest.h` - Individual request handling
- `src/xrpld/app/paths/PathRequests.h` - Request collection management
- `src/xrpld/app/paths/RippleLineCache.h` - Trust line caching
- `src/xrpld/app/paths/TrustLine.h` - Trust line representation
- `src/xrpld/app/paths/AMMLiquidity.h` - AMM pool integration
- `src/xrpld/app/paths/AMMOffer.h` - Synthetic AMM offers

View File

@@ -0,0 +1,18 @@
# App Paths Detail Module Best Practices
## Description
Use when working with path finding implementation details in `src/xrpld/app/paths/detail/`. Internal helpers for the path finding module.
## Responsibility
Internal implementation details for the path finding algorithm, including search heuristics, cost calculation helpers, and internal data structures.
## Key Patterns
### Detail Namespace Convention
- Code in `detail/` is internal to the `app/paths` module
- Contains algorithm-specific helpers not needed by callers
- Never include detail headers from outside `app/paths`
## Common Pitfalls
- Path finding internals are performance-sensitive - profile before modifying
- Detail implementations may change without API compatibility

View File

@@ -0,0 +1,39 @@
# App RDB Module Best Practices
## Description
Use when working with application-level database operations in `src/xrpld/app/rdb/`. Covers database abstractions and backend implementations.
## Responsibility
Application-level relational database operations. Provides interfaces for peer finding data storage, SQLite backend implementation, and database operation details.
## Key Patterns
### Interface-Based Design
```cpp
// PeerFinder.h - Abstract interface for peer data storage
// Backend implementations in backend/ subdirectory
// Allows swapping database backends without changing callers
```
### SQLite Backend
```cpp
// SQLiteDatabase.h - Primary backend implementation
// Uses SOCI wrapper from libxrpl/rdb
// Handles: peer data, transaction history, ledger metadata
```
### Backend Abstraction
```cpp
// backend/ directory contains concrete implementations
// backend/detail/ has implementation-specific helpers
// detail/ has shared implementation details
```
## Common Pitfalls
- Always use the abstract interface, not the SQLite backend directly
- Database operations should be off the main thread (use job queue)
- Respect the SOCI wrapper patterns from libxrpl/rdb
## Key Files
- `src/xrpld/app/rdb/PeerFinder.h` - Peer data interface
- `src/xrpld/app/rdb/backend/SQLiteDatabase.h` - SQLite implementation

View File

@@ -0,0 +1,31 @@
# App RDB Backend Module Best Practices
## Description
Use when working with database backend implementations in `src/xrpld/app/rdb/backend/`. Covers concrete database implementations.
## Responsibility
Concrete database backend implementations for the app/rdb module. Primary implementation is SQLiteDatabase.
## Key Patterns
### SQLiteDatabase
```cpp
// Primary backend implementation using SQLite via SOCI
// Handles: peer storage, transaction history, ledger metadata
// Thread-safe via session-per-thread pattern from libxrpl/rdb
```
### Backend Detail
```cpp
// backend/detail/ contains SQLite-specific helpers
// Schema creation, migration, and optimization queries
```
## Common Pitfalls
- Always use parameterized queries via SOCI - never raw string SQL
- Database files can grow large - implement periodic VACUUM
- WAL checkpoint scheduling prevents unbounded WAL growth
## Key Files
- `src/xrpld/app/rdb/backend/SQLiteDatabase.h` - SQLite implementation
- `src/xrpld/app/rdb/backend/detail/` - SQLite-specific helpers

View File

@@ -0,0 +1,11 @@
# App RDB Backend Detail Module Best Practices
## Description
Use when working with database backend implementation details in `src/xrpld/app/rdb/backend/detail/`. SQLite-specific internal helpers.
## Responsibility
SQLite-specific implementation details: schema definitions, migration scripts, query optimization, and SOCI binding helpers.
## Common Pitfalls
- Schema migrations must be backwards-compatible
- Never include these headers from outside the rdb/backend module

View File

@@ -0,0 +1,18 @@
# App RDB Detail Module Best Practices
## Description
Use when working with database implementation details in `src/xrpld/app/rdb/detail/`. Internal helpers for the relational database module.
## Responsibility
Internal implementation details for app-level database operations, including SQL query helpers and schema management.
## Key Patterns
### Detail Namespace Convention
- Code in `detail/` is internal to the `app/rdb` module
- Contains SQL query construction and result parsing helpers
- Never include detail headers from outside `app/rdb`
## Common Pitfalls
- SQL queries must use parameterized bindings (SOCI style) - never string concatenation
- Detail implementations may change without API compatibility

View File

@@ -0,0 +1,34 @@
# App Tx Module Best Practices
## Description
Use when working with application-level transaction handling in `src/xrpld/app/tx/`. Covers transaction submission, validation, and application-layer processing.
## Responsibility
Application-level transaction handling that bridges the protocol-layer transaction processing (libxrpl/tx) with the running server. Handles transaction submission, validation, and integration with the consensus process.
## Key Patterns
### Relationship to libxrpl/tx
```cpp
// libxrpl/tx: Protocol-level transaction processing (Transactor, preflight, preclaim, doApply)
// xrpld/app/tx: Application-level orchestration (submission, queuing, consensus integration)
// This module calls into libxrpl/tx for actual transaction execution
```
### Transaction Submission Flow
```cpp
// 1. Client submits transaction via RPC
// 2. app/tx validates and queues transaction
// 3. Transaction enters TxQ (app/misc/TxQ)
// 4. Consensus selects transactions for next ledger
// 5. libxrpl/tx executes selected transactions
```
## Common Pitfalls
- Don't duplicate transaction validation logic - defer to libxrpl/tx
- Application-level checks (queue depth, fee escalation) happen here, not in libxrpl
- Transaction metadata is generated at this level after execution
## Key Files
- `src/xrpld/app/tx/` - Application transaction handling
- `src/xrpld/app/tx/detail/` - Implementation details

View File

@@ -0,0 +1,11 @@
# App Tx Detail Module Best Practices
## Description
Use when working with application transaction handling details in `src/xrpld/app/tx/detail/`. Internal helpers for transaction submission and processing.
## Responsibility
Internal implementation details for application-level transaction handling, including submission validation, queue integration, and metadata generation.
## Common Pitfalls
- Don't duplicate libxrpl/tx validation logic here
- Detail implementations may change without API compatibility

View File

@@ -0,0 +1,59 @@
# Consensus Module Best Practices
## Description
Use when working with the generic consensus algorithm in `src/xrpld/consensus/`. This is the application-independent consensus implementation.
## Responsibility
Implements the generic consensus algorithm separate from application-specific types. Uses CRTP (Curiously Recurring Template Pattern) to allow the application layer to plug in concrete types without virtual dispatch overhead.
## Key Patterns
### CRTP Design
```cpp
// Generic consensus uses CRTP - derived class provides concrete types
template <class Derived>
class Consensus {
// Calls static_cast<Derived*>(this)->method() for app-specific behavior
// No virtual dispatch overhead
};
// Application adapter:
class RCLConsensus : public Consensus<RCLConsensus> {
// Provides concrete types: RCLCxTx, RCLCxTxSet, RCLCxLedger
};
```
### Consensus Phases
```cpp
// Open -> Establish -> Accept
// Open: Collecting transactions
// Establish: Proposing and voting on transaction set
// Accept: Applying agreed-upon transaction set to ledger
```
### Consensus Parameters (ConsensusParms.h)
```cpp
// Timing parameters for consensus rounds
// These are tuned for network behavior - don't change without careful analysis
```
### Disputed Transactions
```cpp
// DisputedTx tracks transactions where validators disagree
// Votes are collected and transaction is included/excluded based on threshold
```
## Common Pitfalls
- Never modify consensus parameters without understanding network-wide impact
- CRTP means compilation errors from type mismatches appear in template instantiation - read errors carefully
- The generic consensus module should NEVER depend on application-specific types (Ledger, STTx, etc.)
- Always test consensus changes with multi-node simulation
## Key Files
- `src/xrpld/consensus/Consensus.h` - Main consensus class (extensively documented)
- `src/xrpld/consensus/ConsensusParms.h` - Timing parameters
- `src/xrpld/consensus/ConsensusProposal.h` - Proposal structures
- `src/xrpld/consensus/DisputedTx.h` - Transaction dispute tracking
- `src/xrpld/consensus/LedgerTiming.h` - Ledger timing calculations
- `src/xrpld/consensus/LedgerTrie.h` - Transaction set representation
- `src/xrpld/consensus/Validations.h` - Generic validation tracking

View File

@@ -0,0 +1,55 @@
# Core Module Best Practices
## Description
Use when working with core configuration and system services in `src/xrpld/core/`. Covers Config, time keeping, and network identity.
## Responsibility
System-level configuration and core services. The Config class extends BasicConfig from libxrpl with rippled-specific settings. Provides time keeping and network ID management.
## Key Patterns
### Config Class
```cpp
// Config extends BasicConfig from libxrpl
class Config : public BasicConfig {
// SizedItem enum for memory-dependent configuration
enum SizedItem { siSweepInterval, siNodeCacheSize, ... };
// FeeSetup for fee parameters
struct FeeSetup {
XRPAmount reference_fee;
XRPAmount account_reserve;
XRPAmount owner_reserve;
};
// Access sections by name
auto const& section = config["server"];
};
```
### Configuration Sections
```cpp
// Section names defined in ConfigSections.h
static constexpr char const* SECTION_NODE_DB = "node_db";
static constexpr char const* SECTION_VALIDATORS = "validators";
// Always use constants, never string literals
```
### Gradual Refactoring
```cpp
// Legacy config uses mixed patterns - refactoring is ongoing
// New code should follow the Section-based approach
// Deprecated patterns are documented with TODO comments
```
## Common Pitfalls
- Always use `ConfigSections.h` constants for section names
- Config extends BasicConfig - check both for available methods
- SizedItem values scale with node size configuration - don't hardcode sizes
- Never modify Config after Application startup
## Key Files
- `src/xrpld/core/Config.h` - Configuration object
- `src/xrpld/core/ConfigSections.h` - Section name constants
- `src/xrpld/core/TimeKeeper.h` - System time tracking
- `src/xrpld/core/NetworkIDServiceImpl.h` - Network ID implementation

View File

@@ -0,0 +1,11 @@
# Core Detail Module Best Practices
## Description
Use when working with core configuration implementation details in `src/xrpld/core/detail/`. Internal helpers for the Config system.
## Responsibility
Internal implementation details for the core configuration module, including config parsing helpers and platform-specific abstractions.
## Common Pitfalls
- Never include detail headers from outside the core module
- Config parsing must handle all edge cases gracefully (missing sections, invalid values)

View File

@@ -0,0 +1,74 @@
# Overlay Module Best Practices
## Description
Use when working with P2P networking in `src/xrpld/overlay/`. Covers peer connections, protocol negotiation, message relay, and clustering.
## Responsibility
Manages peer-to-peer connections and the overlay network protocol. Handles HTTP/1.1 upgrade handshake, session signatures (MITM prevention), Protocol Buffer message serialization, message compression, and cluster node management.
## Key Patterns
### HTTP/1.1 Upgrade Handshake
```cpp
// Connection starts as HTTP, upgrades to ripple protocol
// Custom headers:
// Connect-As, Public-Key, Session-Signature
// Network-ID, Network-Time
// Closed-Ledger, Previous-Ledger
// Remote-IP, Local-IP, Crawl
```
### Session Signature (MITM Prevention)
```cpp
// Binds SSL/TLS session to node identities
// Each peer signs the shared SSL session data
// Prevents man-in-the-middle attacks at the protocol level
```
### Message Serialization
```cpp
// Google Protocol Buffers for all p2p messages
// Messages are compressed before transmission
// Compression.h handles LZ4/no-compression selection
```
### Peer Management
```cpp
// Overlay manages the set of connected peers
class Overlay {
virtual Peer::ptr findPeerByShortID(Peer::id_t) = 0;
virtual void send(std::shared_ptr<Message> const&) = 0; // Broadcast
virtual void relay(Message const&, uint256 const& suppression) = 0;
};
```
### Clustering
```cpp
// Multiple rippled nodes can form a cluster
// Cluster nodes: share load, distribute crypto operations
// Cluster membership verified via node public keys
```
### Reduce Relay
```cpp
// ReduceRelayCommon.h - Minimize redundant message relay
// Uses HashRouter for message deduplication
// Peers track which messages they've already seen
```
## Common Pitfalls
- Always validate session signatures during handshake - never skip
- Never send uncompressed messages to peers that advertise compression support
- Cluster keys must be pre-configured - no dynamic cluster joining
- Message suppression via HashRouter is critical for network health - never bypass
- Protocol Buffer messages must match the expected schema version
## Key Files
- `src/xrpld/overlay/Overlay.h` - Main overlay manager interface
- `src/xrpld/overlay/Peer.h` - Peer connection representation
- `src/xrpld/overlay/PeerSet.h` - Collection of peers
- `src/xrpld/overlay/Cluster.h` - Cluster management
- `src/xrpld/overlay/Message.h` - Message structure
- `src/xrpld/overlay/Compression.h` - Message compression
- `src/xrpld/overlay/ReduceRelayCommon.h` - Relay optimization
- `src/xrpld/overlay/README.md` - Comprehensive protocol documentation

View File

@@ -0,0 +1,27 @@
# Overlay Detail Module Best Practices
## Description
Use when working with P2P networking implementation details in `src/xrpld/overlay/detail/`. Internal helpers for the overlay module.
## Responsibility
Internal implementation details for the overlay networking layer, including protocol message handling, peer connection state machines, and handshake implementation.
## Key Patterns
### PeerImp
```cpp
// PeerImp is the concrete implementation of the Peer interface
// Manages: SSL connection, protocol state, message queuing
// Uses enable_shared_from_this for async callback safety
```
### OverlayImpl
```cpp
// OverlayImpl is the concrete implementation of Overlay
// Manages: listening sockets, peer lifecycle, broadcast
```
## Common Pitfalls
- Peer connection state machine transitions must be atomic
- Never access PeerImp internals from outside overlay/detail/
- Message queuing must respect back-pressure limits

View File

@@ -0,0 +1,58 @@
# PeerFinder Module Best Practices
## Description
Use when working with network discovery in `src/xrpld/peerfinder/`. Covers peer bootstrap, cache management, and connection slot strategy.
## Responsibility
Bootstraps into the XRP Ledger network and discovers peers. Manages bootcache (persistent addresses ranked by success), livecache (ephemeral recently-seen peers), and connection slot allocation.
## Key Patterns
### Three-Stage Connection Strategy
```cpp
// Stage 1: Connect to fixed peers (configured addresses)
// Stage 2: Try Livecache addresses (recently seen, with open slots)
// Stage 3: Fall back to Bootcache (persistent, ranked by valence)
```
### Bootcache (Persistent)
```cpp
// Persistent store of peer addresses ranked by "valence" (connection success)
// Higher valence = more reliable peer
// Persisted across restarts
// Used as fallback when livecache is empty
```
### Livecache (Ephemeral)
```cpp
// Recently seen peers with available connection slots
// Uses hop counts for distance estimation
// Random distribution for load balancing
// Not persisted - rebuilt on restart via gossip
```
### Slot Management
```cpp
// Slot states: accept, connect, connected, active, closing
// Slot properties: Inbound/Outbound, Fixed, Cluster
// Slots track connection lifecycle from handshake to disconnect
```
### Callback Pattern
```cpp
// Abstract interface for socket operations
// PeerFinder doesn't directly manage sockets
// Delegates I/O to the overlay layer via callbacks
```
## Common Pitfalls
- Fixed peers should always be tried first (Stage 1) - they are trusted
- Bootcache valence can decay over time - implement proper aging
- Livecache entries expire quickly - don't rely on stale data
- Slot limits prevent connection exhaustion - never bypass them
- Always check README.md for algorithm details before modifying
## Key Files
- `src/xrpld/peerfinder/PeerfinderManager.h` - Main manager interface
- `src/xrpld/peerfinder/Slot.h` - Connection slot representation
- `src/xrpld/peerfinder/README.md` - Extensive design documentation

View File

@@ -0,0 +1,21 @@
# PeerFinder Detail Module Best Practices
## Description
Use when working with peer discovery implementation details in `src/xrpld/peerfinder/detail/`. Internal helpers for the peerfinder module.
## Responsibility
Internal implementation details for peer discovery: bootcache persistence, livecache management, slot state machine, and connection strategy implementation.
## Key Patterns
### Logic Class
```cpp
// The main implementation class for peer finding
// Implements the three-stage connection strategy
// Manages bootcache and livecache state
```
## Common Pitfalls
- Bootcache persistence must be atomic to prevent corruption
- Livecache expiration must be checked on every access
- Never include detail headers from outside peerfinder/

View File

@@ -0,0 +1,31 @@
# PerfLog Module Best Practices
## Description
Use when working with performance logging in `src/xrpld/perflog/`. Covers performance instrumentation and metric collection.
## Responsibility
Performance logging and instrumentation for the rippled server. Tracks timing data, throughput metrics, and operational statistics for monitoring and debugging.
## Key Patterns
### Performance Logging Interface
```cpp
// Abstract interface for performance data collection
// Implementations can log to file, export to monitoring systems, etc.
// Enabled/disabled via configuration
```
### Detail Namespace
```cpp
// Implementation details in detail/ subdirectory
// Not part of public API
```
## Common Pitfalls
- Performance logging should have minimal overhead when disabled
- Never log sensitive data (keys, balances) in performance logs
- Ensure timestamps use consistent clock sources
## Key Files
- `src/xrpld/perflog/` - Performance logging implementation
- `src/xrpld/perflog/detail/` - Implementation details

View File

@@ -0,0 +1,11 @@
# PerfLog Detail Module Best Practices
## Description
Use when working with performance logging implementation details in `src/xrpld/perflog/detail/`. Internal helpers for the perflog module.
## Responsibility
Internal implementation details for performance logging, including metric collection, formatting, and output management.
## Common Pitfalls
- Performance logging overhead must be minimal when disabled
- Never include detail headers from outside perflog/

View File

@@ -0,0 +1,91 @@
# RPC Module Best Practices
## Description
Use when working with RPC request handling in `src/xrpld/rpc/`. Covers command dispatch, handler implementation, coroutine suspension, and the gRPC interface.
## Responsibility
HTTP/JSON and gRPC RPC interface to rippled. Dispatches requests to 40+ command handlers, manages request context, supports coroutine-based suspension for async operations, and handles user roles/permissions.
## Key Patterns
### RPC Handler Pattern
```cpp
// Each handler is a function taking context, returning Json::Value
Json::Value doMyCommand(RPC::JsonContext& context) {
// Validate parameters
if (!context.params.isMember("field"))
return RPC::missing_field_error("field");
// Access application services
auto& app = context.app;
// Build response
Json::Value result(Json::objectValue);
result["status"] = "success";
return result;
}
```
### Coroutine Suspension
```cpp
// RPC handlers can suspend for async operations
// Key types:
// Callback - 0-argument function
// Continuation - Takes callback, promises to call it later
// Suspend - Function from coroutine that takes continuation
// Coroutine - Function given suspend to enable suspension
// This allows handlers to yield without blocking threads
```
### Request Context
```cpp
struct JsonContext {
Application& app;
Resource::Charge& loadType;
Json::Value params;
beast::Journal j;
Role role; // User, Admin, Identified, etc.
};
```
### Role-Based Access
```cpp
enum class Role { GUEST, USER, ADMIN, IDENTIFIED, PROXY, FORBID };
// Handlers specify minimum required role
// Admin handlers only accessible from admin IP ranges
```
### Error Handling
```cpp
// Standard error helpers:
RPC::missing_field_error("field_name");
RPC::invalid_field_error("field_name");
RPC::make_error(rpcINVALID_PARAMS, "description");
// Errors injected into JSON response
```
### gRPC Handlers
```cpp
// Separate handler set for gRPC interface
// Defined in GRPCHandlers.h
// Use Protocol Buffer request/response types
// Convert to/from native types at boundary
```
## Common Pitfalls
- Always validate parameters before accessing them
- Check user Role before executing privileged operations
- Use coroutine suspension for any operation that might block
- Never return internal data structures directly - always convert to JSON
- Handler functions are in `handlers/` directory - one file per command or group
- gRPC handlers must convert proto types to native types at the boundary
## Key Files
- `src/xrpld/rpc/RPCHandler.h` - Command dispatcher
- `src/xrpld/rpc/Context.h` - RPC context/state
- `src/xrpld/rpc/Status.h` - RPC status codes
- `src/xrpld/rpc/Role.h` - User role/permissions
- `src/xrpld/rpc/GRPCHandlers.h` - gRPC integration
- `src/xrpld/rpc/handlers/` - Individual command handlers (40+)
- `src/xrpld/rpc/README.md` - Coroutine documentation

View File

@@ -0,0 +1,11 @@
# RPC Detail Module Best Practices
## Description
Use when working with RPC implementation details in `src/xrpld/rpc/detail/`. Internal helpers for the RPC module.
## Responsibility
Internal implementation details for RPC handling, including request parsing, response formatting, coroutine machinery, and middleware.
## Common Pitfalls
- Coroutine state must be carefully managed to prevent leaks
- Never include detail headers from outside rpc/

View File

@@ -0,0 +1,74 @@
# RPC Handlers Module Best Practices
## Description
Use when adding or modifying RPC command handlers in `src/xrpld/rpc/handlers/`. Contains 40+ individual RPC command implementations.
## Responsibility
Individual RPC command handler implementations. Each file implements one or more related RPC commands following the standard handler pattern.
## Key Patterns
### Handler Function Signature
```cpp
// Standard handler pattern
Json::Value doMyCommand(RPC::JsonContext& context) {
// 1. Validate parameters
if (!context.params.isMember("required_field"))
return RPC::missing_field_error("required_field");
// 2. Check permissions
// (Role already verified by dispatcher based on handler metadata)
// 3. Access application services
auto& app = context.app;
auto& ledger = context.ledgerMaster.getValidatedLedger();
// 4. Execute logic
// ...
// 5. Build and return response
Json::Value result(Json::objectValue);
result["status"] = "success";
return result;
}
```
### Parameter Validation
```cpp
// Use standard error helpers
RPC::missing_field_error("field_name"); // Required field missing
RPC::invalid_field_error("field_name"); // Field has wrong type/value
RPC::make_error(rpcINVALID_PARAMS, "description"); // Generic error
```
### Adding a New Handler
1. Create a new .cpp file in `handlers/`
2. Implement the handler function following the pattern above
3. Register the command in the handler dispatch table
4. Document the command parameters and response format
### Common Handler Files
```
AccountInfo.cpp - account_info command
AccountLines.cpp - account_lines (trust lines)
AccountOffers.cpp - account_offers
Submit.cpp - submit (transaction submission)
Subscribe.cpp - subscribe (event streaming)
LedgerData.cpp - ledger_data
ServerInfo.cpp - server_info
Fee1.cpp - fee command
Tx.cpp - tx (transaction lookup)
BookOffers.cpp - book_offers (order book)
```
## Common Pitfalls
- Always validate ALL parameters before using them
- Never return internal data structures - convert to JSON at the boundary
- Respect Role-based access control - admin handlers must check role
- Handlers should be stateless - all state comes from context
- Use coroutine suspension for any blocking operation (DB queries, network)
- Error responses must follow the standard error format
## Key Files
- `src/xrpld/rpc/handlers/` - All handler implementations
- `src/xrpld/rpc/RPCHandler.h` - Dispatch table and registration

View File

@@ -0,0 +1,32 @@
# SHAMap (xrpld) Module Best Practices
## Description
Use when working with application-level SHAMap operations in `src/xrpld/shamap/`. Covers NodeFamily and application integration with the Merkle tree.
## Responsibility
Application-level integration of the SHAMap (Merkle radix tree) with the rippled server. Provides NodeFamily for managing tree node relationships and connecting the generic SHAMap to the node store.
## Key Patterns
### NodeFamily
```cpp
// NodeFamily connects SHAMap to the persistent NodeStore
// Provides: database access, tree node creation, hash verification
// Each SHAMap references a Family for storage operations
```
### Relationship to libxrpl/shamap
```cpp
// libxrpl/shamap: Generic Merkle tree implementation
// xrpld/shamap: Application-specific integration (NodeFamily, storage)
// The generic tree doesn't know about databases - NodeFamily bridges the gap
```
## Common Pitfalls
- Always use NodeFamily to create SHAMap instances connected to storage
- The libxrpl SHAMap is the implementation - this module is the glue layer
- Don't duplicate SHAMap logic here - extend via NodeFamily only
## Key Files
- `src/xrpld/shamap/NodeFamily.h` - Family relationship management
- `src/xrpld/shamap/NodeFamily.cpp` - Implementation

247
.cmake-format.yaml Normal file
View File

@@ -0,0 +1,247 @@
_help_parse: Options affecting listfile parsing
parse:
_help_additional_commands:
- Specify structure for custom cmake functions
additional_commands:
target_protobuf_sources:
pargs:
- target
- prefix
kwargs:
PROTOS: "*"
LANGUAGE: cpp
IMPORT_DIRS: "*"
GENERATE_EXTENSIONS: "*"
PLUGIN: "*"
_help_override_spec:
- Override configurations per-command where available
override_spec: {}
_help_vartags:
- Specify variable tags.
vartags: []
_help_proptags:
- Specify property tags.
proptags: []
_help_format: Options affecting formatting.
format:
_help_disable:
- Disable formatting entirely, making cmake-format a no-op
disable: false
_help_line_width:
- How wide to allow formatted cmake files
line_width: 120
_help_tab_size:
- How many spaces to tab for indent
tab_size: 4
_help_use_tabchars:
- If true, lines are indented using tab characters (utf-8
- 0x09) instead of <tab_size> space characters (utf-8 0x20).
- In cases where the layout would require a fractional tab
- character, the behavior of the fractional indentation is
- governed by <fractional_tab_policy>
use_tabchars: false
_help_fractional_tab_policy:
- If <use_tabchars> is True, then the value of this variable
- indicates how fractional indentions are handled during
- whitespace replacement. If set to 'use-space', fractional
- indentation is left as spaces (utf-8 0x20). If set to
- "`round-up` fractional indentation is replaced with a single"
- tab character (utf-8 0x09) effectively shifting the column
- to the next tabstop
fractional_tab_policy: use-space
_help_max_subgroups_hwrap:
- If an argument group contains more than this many sub-groups
- (parg or kwarg groups) then force it to a vertical layout.
max_subgroups_hwrap: 4
_help_max_pargs_hwrap:
- If a positional argument group contains more than this many
- arguments, then force it to a vertical layout.
max_pargs_hwrap: 5
_help_max_rows_cmdline:
- If a cmdline positional group consumes more than this many
- lines without nesting, then invalidate the layout (and nest)
max_rows_cmdline: 2
_help_separate_ctrl_name_with_space:
- If true, separate flow control names from their parentheses
- with a space
separate_ctrl_name_with_space: true
_help_separate_fn_name_with_space:
- If true, separate function names from parentheses with a
- space
separate_fn_name_with_space: false
_help_dangle_parens:
- If a statement is wrapped to more than one line, than dangle
- the closing parenthesis on its own line.
dangle_parens: false
_help_dangle_align:
- If the trailing parenthesis must be 'dangled' on its on
- "line, then align it to this reference: `prefix`: the start"
- "of the statement, `prefix-indent`: the start of the"
- "statement, plus one indentation level, `child`: align to"
- the column of the arguments
dangle_align: prefix
_help_min_prefix_chars:
- If the statement spelling length (including space and
- parenthesis) is smaller than this amount, then force reject
- nested layouts.
min_prefix_chars: 18
_help_max_prefix_chars:
- If the statement spelling length (including space and
- parenthesis) is larger than the tab width by more than this
- amount, then force reject un-nested layouts.
max_prefix_chars: 10
_help_max_lines_hwrap:
- If a candidate layout is wrapped horizontally but it exceeds
- this many lines, then reject the layout.
max_lines_hwrap: 2
_help_line_ending:
- What style line endings to use in the output.
line_ending: unix
_help_command_case:
- Format command names consistently as 'lower' or 'upper' case
command_case: canonical
_help_keyword_case:
- Format keywords consistently as 'lower' or 'upper' case
keyword_case: unchanged
_help_always_wrap:
- A list of command names which should always be wrapped
always_wrap: []
_help_enable_sort:
- If true, the argument lists which are known to be sortable
- will be sorted lexicographicall
enable_sort: true
_help_autosort:
- If true, the parsers may infer whether or not an argument
- list is sortable (without annotation).
autosort: true
_help_require_valid_layout:
- By default, if cmake-format cannot successfully fit
- everything into the desired linewidth it will apply the
- last, most aggressive attempt that it made. If this flag is
- True, however, cmake-format will print error, exit with non-
- zero status code, and write-out nothing
require_valid_layout: false
_help_layout_passes:
- A dictionary mapping layout nodes to a list of wrap
- decisions. See the documentation for more information.
layout_passes: {}
_help_markup: Options affecting comment reflow and formatting.
markup:
_help_bullet_char:
- What character to use for bulleted lists
bullet_char: "-"
_help_enum_char:
- What character to use as punctuation after numerals in an
- enumerated list
enum_char: .
_help_first_comment_is_literal:
- If comment markup is enabled, don't reflow the first comment
- block in each listfile. Use this to preserve formatting of
- your copyright/license statements.
first_comment_is_literal: false
_help_literal_comment_pattern:
- If comment markup is enabled, don't reflow any comment block
- which matches this (regex) pattern. Default is `None`
- (disabled).
literal_comment_pattern: null
_help_fence_pattern:
- Regular expression to match preformat fences in comments
- default= ``r'^\s*([`~]{3}[`~]*)(.*)$'``
fence_pattern: ^\s*([`~]{3}[`~]*)(.*)$
_help_ruler_pattern:
- Regular expression to match rulers in comments default=
- '``r''^\s*[^\w\s]{3}.*[^\w\s]{3}$''``'
ruler_pattern: ^\s*[^\w\s]{3}.*[^\w\s]{3}$
_help_explicit_trailing_pattern:
- If a comment line matches starts with this pattern then it
- is explicitly a trailing comment for the preceding
- argument. Default is '#<'
explicit_trailing_pattern: "#<"
_help_hashruler_min_length:
- If a comment line starts with at least this many consecutive
- hash characters, then don't lstrip() them off. This allows
- for lazy hash rulers where the first hash char is not
- separated by space
hashruler_min_length: 10
_help_canonicalize_hashrulers:
- If true, then insert a space between the first hash char and
- remaining hash chars in a hash ruler, and normalize its
- length to fill the column
canonicalize_hashrulers: true
_help_enable_markup:
- enable comment markup parsing and reflow
enable_markup: false
_help_lint: Options affecting the linter
lint:
_help_disabled_codes:
- a list of lint codes to disable
disabled_codes: []
_help_function_pattern:
- regular expression pattern describing valid function names
function_pattern: "[0-9a-z_]+"
_help_macro_pattern:
- regular expression pattern describing valid macro names
macro_pattern: "[0-9A-Z_]+"
_help_global_var_pattern:
- regular expression pattern describing valid names for
- variables with global (cache) scope
global_var_pattern: "[A-Z][0-9A-Z_]+"
_help_internal_var_pattern:
- regular expression pattern describing valid names for
- variables with global scope (but internal semantic)
internal_var_pattern: _[A-Z][0-9A-Z_]+
_help_local_var_pattern:
- regular expression pattern describing valid names for
- variables with local scope
local_var_pattern: "[a-z][a-z0-9_]+"
_help_private_var_pattern:
- regular expression pattern describing valid names for
- privatedirectory variables
private_var_pattern: _[0-9a-z_]+
_help_public_var_pattern:
- regular expression pattern describing valid names for public
- directory variables
public_var_pattern: "[A-Z][0-9A-Z_]+"
_help_argument_var_pattern:
- regular expression pattern describing valid names for
- function/macro arguments and loop variables.
argument_var_pattern: "[a-z][a-z0-9_]+"
_help_keyword_pattern:
- regular expression pattern describing valid names for
- keywords used in functions or macros
keyword_pattern: "[A-Z][0-9A-Z_]+"
_help_max_conditionals_custom_parser:
- In the heuristic for C0201, how many conditionals to match
- within a loop in before considering the loop a parser.
max_conditionals_custom_parser: 2
_help_min_statement_spacing:
- Require at least this many newlines between statements
min_statement_spacing: 1
_help_max_statement_spacing:
- Require no more than this many newlines between statements
max_statement_spacing: 2
max_returns: 6
max_branches: 12
max_arguments: 5
max_localvars: 15
max_statements: 50
_help_encode: Options affecting file encoding
encode:
_help_emit_byteorder_mark:
- If true, emit the unicode byte-order mark (BOM) at the start
- of the file
emit_byteorder_mark: false
_help_input_encoding:
- Specify the encoding of the input file. Defaults to utf-8
input_encoding: utf-8
_help_output_encoding:
- Specify the encoding of the output file. Defaults to utf-8.
- Note that cmake only claims to support utf-8 so be careful
- when using anything else
output_encoding: utf-8
_help_misc: Miscellaneous configurations options.
misc:
_help_per_command:
- A dictionary containing any per-command configuration
- overrides. Currently only `command_case` is supported.
per_command: {}

290
.config/cspell.config.yaml Normal file
View File

@@ -0,0 +1,290 @@
ignorePaths:
- build/**
- src/libxrpl/crypto
- src/test/** # Will be removed in the future
- CMakeUserPresets.json
- Doxyfile
- docs/**/*.puml
- cmake/**
- LICENSE.md
language: en
allowCompoundWords: true
ignoreRandomStrings: true
minWordLength: 5
dictionaries:
- cpp
- en_US
- en_GB
ignoreRegExpList:
- /[rs][1-9A-HJ-NP-Za-km-z]{25,34}/g # addresses and seeds
- /(XRPL|BEAST)_[A-Z_0-9]+_H_INCLUDED+/g # include guards
- /(XRPL|BEAST)_[A-Z_0-9]+_H+/g # include guards
- /::[a-z:_]+/g # things from other namespaces
- /lib[a-z]+/g # libraries
- /[0-9]{4}-[0-9]{2}-[0-9]{2}[,:][A-Za-zÀ-ÖØ-öø-ÿ.\s]+/g # copyright dates
- /[0-9]{4}[,:]?\s*[A-Za-zÀ-ÖØ-öø-ÿ.\s]+/g # copyright years
- /\[[A-Za-z0-9-]+\]\(https:\/\/github.com\/[A-Za-z0-9-]+\)/g # Github usernames
- /-[DWw][a-zA-Z0-9_-]+=/g # compile flags
- /[\['"`]-[DWw][a-zA-Z0-9_-]+['"`\]]/g # compile flags
suggestWords:
- xprl->xrpl
- xprld->xrpld
- unsynched->unsynced
- synched->synced
- synch->sync
words:
- abempty
- AMMID
- amt
- amts
- asnode
- asynchrony
- attestation
- authorises
- autobridge
- autobridged
- autobridging
- bimap
- bindir
- bookdir
- Bougalis
- Britto
- Btrfs
- canonicality
- checkme
- choco
- chrono
- citardauq
- clawback
- clawbacks
- coeffs
- coldwallet
- compr
- conanfile
- conanrun
- confs
- connectability
- coro
- coros
- cowid
- cryptocondition
- cryptoconditional
- cryptoconditions
- csprng
- ctest
- ctid
- currenttxhash
- daria
- dcmake
- dearmor
- deleteme
- demultiplexer
- deserializaton
- desync
- desynced
- determ
- distro
- doxyfile
- dxrpl
- endmacro
- exceptioned
- Falco
- finalizers
- firewalled
- fmtdur
- fsanitize
- funclets
- gcov
- gcovr
- ghead
- Gnutella
- gpgcheck
- gpgkey
- hotwallet
- hwrap
- ifndef
- inequation
- insuf
- insuff
- iou
- ious
- isrdc
- itype
- jemalloc
- jlog
- keylet
- keylets
- keyvadb
- kwarg
- kwargs
- ledgerentry
- ledgerhash
- ledgerindex
- leftw
- legleux
- levelization
- levelized
- libpb
- libxrpl
- llection
- LOCALGOOD
- logwstream
- lseq
- lsmf
- ltype
- mcmodel
- MEMORYSTATUSEX
- Merkle
- Metafuncton
- misprediction
- mptbalance
- mptflags
- mptid
- mptissuance
- mptissuanceid
- mptoken
- mptokenid
- mptokenissuance
- mptokens
- mpts
- multisig
- multisign
- multisigned
- Nakamoto
- nftid
- nftoffer
- nftoken
- nftokenid
- nftokenpages
- nftokens
- nftpage
- nikb
- nonxrp
- noripple
- nudb
- nullptr
- nunl
- Nyffenegger
- ostr
- pargs
- partitioner
- paychan
- paychans
- permdex
- perminute
- permissioned
- pointee
- preauth
- preauthorization
- preauthorize
- preauthorizes
- preclaim
- protobuf
- protos
- ptrs
- pyenv
- qalloc
- queuable
- Raphson
- replayer
- rerere
- retriable
- RIPD
- ripdtop
- rippleci
- rippled
- ripplerpc
- rippletest
- RLUSD
- rngfill
- rocksdb
- Rohrs
- roundings
- sahyadri
- Satoshi
- scons
- secp
- sendq
- seqit
- sf
- SFIELD
- shamap
- shamapitem
- sidechain
- SIGGOOD
- sle
- sles
- soci
- socidb
- sslws
- statsd
- STATSDCOLLECTOR
- stissue
- stnum
- stobj
- stobject
- stpath
- stpathset
- sttx
- stvar
- stvector
- stxchainattestations
- superpeer
- superpeers
- takergets
- takerpays
- ters
- TMEndpointv2
- trixie
- tx
- txid
- txids
- txjson
- txn
- txns
- txs
- UBSAN
- ubsan
- umant
- unacquired
- unambiguity
- unauthorizes
- unauthorizing
- unergonomic
- unfetched
- unflatten
- unfund
- unimpair
- unroutable
- unscalable
- unserviced
- unshareable
- unshares
- unsquelch
- unsquelched
- unsquelching
- unvalidated
- unveto
- unvetoed
- upvotes
- USDB
- variadics
- venv
- vfalco
- vinnie
- wextra
- wptr
- writeme
- wsrch
- wthread
- xbridge
- xchain
- ximinez
- EXPECT_STREQ
- XMACRO
- xrpkuwait
- xrpl
- xrpld
- xrplf
- xxhash
- xxhasher

5
.gitattributes vendored
View File

@@ -1,9 +1,6 @@
# Set default behaviour, in case users don't have core.autocrlf set.
#* text=auto
# These annoying files
rippled.1 binary
LICENSE binary
# cspell: disable
# Visual Studio
*.sln text eol=crlf

8
.github/CODEOWNERS vendored
View File

@@ -1,8 +0,0 @@
# Allow anyone to review any change by default.
*
# Require the rpc-reviewers team to review changes to the rpc code.
include/xrpl/protocol/ @xrplf/rpc-reviewers
src/libxrpl/protocol/ @xrplf/rpc-reviewers
src/xrpld/rpc/ @xrplf/rpc-reviewers
src/xrpld/app/misc/ @xrplf/rpc-reviewers

View File

@@ -1,7 +1,7 @@
---
name: Bug Report
about: Create a report to help us improve rippled
title: "[Title with short description] (Version: [rippled version])"
about: Create a report to help us improve xrpld
title: "[Title with short description] (Version: [xrpld version])"
labels: ""
assignees: ""
---
@@ -27,7 +27,7 @@ assignees: ""
## Environment
<!--Please describe your environment setup (such as Ubuntu 18.04 with Boost 1.70).-->
<!-- If you are using a formal release, please use the version returned by './rippled --version' as the version number-->
<!-- If you are using a formal release, please use the version returned by './xrpld --version' as the version number-->
<!-- If you are working off of develop, please add the git hash via 'git rev-parse HEAD'-->
## Supporting Files

View File

@@ -4,16 +4,24 @@ description: "Install Conan dependencies, optionally forcing a rebuild of all de
# Note that actions do not support 'type' and all inputs are strings, see
# https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax#inputs.
inputs:
build_dir:
description: "The directory where to build."
required: true
build_type:
description: 'The build type to use ("Debug", "Release").'
required: true
build_nproc:
description: "The number of processors to use for building."
required: true
force_build:
description: 'Force building of all dependencies ("true", "false").'
required: false
default: "false"
log_verbosity:
description: "The logging verbosity."
required: false
default: "verbose"
sanitizers:
description: "The sanitizers to enable."
required: false
default: ""
runs:
using: composite
@@ -21,17 +29,20 @@ runs:
- name: Install Conan dependencies
shell: bash
env:
BUILD_DIR: ${{ inputs.build_dir }}
BUILD_NPROC: ${{ inputs.build_nproc }}
BUILD_OPTION: ${{ inputs.force_build == 'true' && '*' || 'missing' }}
BUILD_TYPE: ${{ inputs.build_type }}
LOG_VERBOSITY: ${{ inputs.log_verbosity }}
SANITIZERS: ${{ inputs.sanitizers }}
run: |
echo 'Installing dependencies.'
mkdir -p '${{ env.BUILD_DIR }}'
cd '${{ env.BUILD_DIR }}'
conan install \
--output-folder . \
--build=${{ env.BUILD_OPTION }} \
--profile ci \
--build="${BUILD_OPTION}" \
--options:host='&:tests=True' \
--options:host='&:xrpld=True' \
--settings:all build_type='${{ env.BUILD_TYPE }}' \
..
--settings:all build_type="${BUILD_TYPE}" \
--conf:all tools.build:jobs=${BUILD_NPROC} \
--conf:all tools.build:verbosity="${LOG_VERBOSITY}" \
--conf:all tools.compilation:verbosity="${LOG_VERBOSITY}" \
.

View File

@@ -0,0 +1,44 @@
name: Generate build version number
description: "Generate build version number."
outputs:
version:
description: "The generated build version number."
value: ${{ steps.version.outputs.version }}
runs:
using: composite
steps:
# When a tag is pushed, the version is used as-is.
- name: Generate version for tag event
if: ${{ github.event_name == 'tag' }}
shell: bash
env:
VERSION: ${{ github.ref_name }}
run: echo "VERSION=${VERSION}" >> "${GITHUB_ENV}"
# When a tag is not pushed, then the version (e.g. 1.2.3-b0) is extracted
# from the BuildInfo.cpp file and the shortened commit hash appended to it.
# We use a plus sign instead of a hyphen because Conan recipe versions do
# not support two hyphens.
- name: Generate version for non-tag event
if: ${{ github.event_name != 'tag' }}
shell: bash
run: |
echo 'Extracting version from BuildInfo.cpp.'
VERSION="$(cat src/libxrpl/protocol/BuildInfo.cpp | grep "versionString =" | awk -F '"' '{print $2}')"
if [[ -z "${VERSION}" ]]; then
echo 'Unable to extract version from BuildInfo.cpp.'
exit 1
fi
echo 'Appending shortened commit hash to version.'
SHA='${{ github.sha }}'
VERSION="${VERSION}+${SHA:0:7}"
echo "VERSION=${VERSION}" >> "${GITHUB_ENV}"
- name: Output version
id: version
shell: bash
run: echo "version=${VERSION}" >> "${GITHUB_OUTPUT}"

View File

@@ -11,12 +11,6 @@ runs:
echo 'Checking environment variables.'
set
echo 'Checking CMake version.'
cmake --version
echo 'Checking Conan version.'
conan --version
- name: Check configuration (Linux and macOS)
if: ${{ runner.os == 'Linux' || runner.os == 'macOS' }}
shell: bash
@@ -27,17 +21,23 @@ runs:
echo 'Checking environment variables.'
env | sort
echo 'Checking CMake version.'
cmake --version
echo 'Checking compiler version.'
${{ runner.os == 'Linux' && '${CC}' || 'clang' }} --version
echo 'Checking Conan version.'
conan --version
echo 'Checking Ninja version.'
ninja --version
echo 'Checking nproc version.'
nproc --version
- name: Check configuration (all)
shell: bash
run: |
echo 'Checking Ccache version.'
ccache --version
echo 'Checking CMake version.'
cmake --version
echo 'Checking Conan version.'
conan --version

View File

@@ -2,11 +2,11 @@ name: Setup Conan
description: "Set up Conan configuration, profile, and remote."
inputs:
conan_remote_name:
remote_name:
description: "The name of the Conan remote to use."
required: false
default: xrplf
conan_remote_url:
remote_url:
description: "The URL of the Conan endpoint to use."
required: false
default: https://conan.ripplex.io
@@ -28,19 +28,19 @@ runs:
shell: bash
run: |
echo 'Installing profile.'
conan config install conan/profiles/default -tf $(conan config home)/profiles/
conan config install conan/profiles/ -tf $(conan config home)/profiles/
echo 'Conan profile:'
conan profile show
conan profile show --profile ci
- name: Set up Conan remote
shell: bash
env:
CONAN_REMOTE_NAME: ${{ inputs.conan_remote_name }}
CONAN_REMOTE_URL: ${{ inputs.conan_remote_url }}
REMOTE_NAME: ${{ inputs.remote_name }}
REMOTE_URL: ${{ inputs.remote_url }}
run: |
echo "Adding Conan remote '${{ env.CONAN_REMOTE_NAME }}' at '${{ env.CONAN_REMOTE_URL }}'."
conan remote add --index 0 --force '${{ env.CONAN_REMOTE_NAME }}' '${{ env.CONAN_REMOTE_URL }}'
echo "Adding Conan remote '${REMOTE_NAME}' at '${REMOTE_URL}'."
conan remote add --index 0 --force "${REMOTE_NAME}" "${REMOTE_URL}"
echo 'Listing Conan remotes.'
conan remote list

View File

@@ -3,21 +3,26 @@
Levelization is the term used to describe efforts to prevent rippled from
having or creating cyclic dependencies.
rippled code is organized into directories under `src/rippled` (and
rippled code is organized into directories under `src/xrpld`, `src/libxrpl` (and
`src/test`) representing modules. The modules are intended to be
organized into "tiers" or "levels" such that a module from one level can
only include code from lower levels. Additionally, a module
in one level should never include code in an `impl` folder of any level
in one level should never include code in an `impl` or `detail` folder of any level
other than it's own.
The codebase is split into two main areas:
- **libxrpl** (`src/libxrpl`, `include/xrpl`): Reusable library modules with public interfaces
- **xrpld** (`src/xrpld`): Application-specific implementation code
Unfortunately, over time, enforcement of levelization has been
inconsistent, so the current state of the code doesn't necessarily
reflect these rules. Whenever possible, developers should refactor any
levelization violations they find (by moving files or individual
classes). At the very least, don't make things worse.
The table below summarizes the _desired_ division of modules, based on the
state of the rippled code when it was created. The levels are numbered from
The table below summarizes the _desired_ division of modules, based on the current
state of the rippled code. The levels are numbered from
the bottom up with the lower level, lower numbered, more independent
modules listed first, and the higher level, higher numbered modules with
more dependencies listed later.
@@ -25,18 +30,33 @@ more dependencies listed later.
**tl;dr:** The modules listed first are more independent than the modules
listed later.
## libxrpl Modules (Reusable Libraries)
| Level / Tier | Module(s) |
| ------------ | ----------------------------------- |
| 01 | xrpl/beast |
| 02 | xrpl/basics |
| 03 | xrpl/json xrpl/crypto |
| 04 | xrpl/protocol |
| 05 | xrpl/core xrpl/resource xrpl/server |
| 06 | xrpl/ledger xrpl/nodestore xrpl/net |
| 07 | xrpl/shamap |
## xrpld Modules (Application Implementation)
| Level / Tier | Module(s) |
| ------------ | -------------------------------- |
| 05 | xrpld/conditions xrpld/consensus |
| 06 | xrpld/core xrpld/peerfinder |
| 07 | xrpld/shamap xrpld/overlay |
| 08 | xrpld/app |
| 09 | xrpld/rpc |
| 10 | xrpld/perflog |
## Test Modules
| Level / Tier | Module(s) |
| ------------ | -------------------------------------------------------------------------------------------------------- |
| 01 | ripple/beast ripple/unity |
| 02 | ripple/basics |
| 03 | ripple/json ripple/crypto |
| 04 | ripple/protocol |
| 05 | ripple/core ripple/conditions ripple/consensus ripple/resource ripple/server |
| 06 | ripple/peerfinder ripple/ledger ripple/nodestore ripple/net |
| 07 | ripple/shamap ripple/overlay |
| 08 | ripple/app |
| 09 | ripple/rpc |
| 10 | ripple/perflog |
| 11 | test/jtx test/beast test/csf |
| 12 | test/unit_test |
| 13 | test/crypto test/conditions test/json test/resource test/shamap test/peerfinder test/basics test/overlay |
@@ -45,8 +65,8 @@ listed later.
| 16 | test/rpc test/app |
(Note that `test` levelization is _much_ less important and _much_ less
strictly enforced than `ripple` levelization, other than the requirement
that `test` code should _never_ be included in `ripple` code.)
strictly enforced than `xrpl`/`xrpld` levelization, other than the requirement
that `test` code should _never_ be included in `xrpl` or `xrpld` code.)
## Validation
@@ -61,10 +81,10 @@ It generates many files of [results](results):
- `rawincludes.txt`: The raw dump of the `#includes`
- `paths.txt`: A second dump grouping the source module
to the destination module, deduped, and with frequency counts.
to the destination module, de-duped, and with frequency counts.
- `includes/`: A directory where each file represents a module and
contains a list of modules and counts that the module _includes_.
- `includedby/`: Similar to `includes/`, but the other way around. Each
- `included_by/`: Similar to `includes/`, but the other way around. Each
file represents a module and contains a list of modules and counts
that _include_ the module.
- [`loops.txt`](results/loops.txt): A list of direct loops detected

View File

@@ -29,7 +29,7 @@ pushd results
oldifs=${IFS}
IFS=:
mkdir includes
mkdir includedby
mkdir included_by
echo Build levelization paths
exec 3< ${includes} # open rawincludes.txt for input
while read -r -u 3 file include
@@ -59,7 +59,7 @@ do
echo $level $includelevel | tee -a paths.txt
fi
done
echo Sort and dedup paths
echo Sort and deduplicate paths
sort -ds paths.txt | uniq -c | tee sortedpaths.txt
mv sortedpaths.txt paths.txt
exec 3>&- #close fd 3
@@ -71,7 +71,7 @@ exec 4<paths.txt # open paths.txt for input
while read -r -u 4 count level include
do
echo ${include} ${count} | tee -a includes/${level}
echo ${level} ${count} | tee -a includedby/${include}
echo ${level} ${count} | tee -a included_by/${include}
done
exec 4>&- #close fd 4

View File

@@ -17,14 +17,8 @@ Loop: xrpld.app xrpld.rpc
xrpld.rpc > xrpld.app
Loop: xrpld.app xrpld.shamap
xrpld.app > xrpld.shamap
Loop: xrpld.core xrpld.perflog
xrpld.perflog == xrpld.core
xrpld.shamap ~= xrpld.app
Loop: xrpld.overlay xrpld.rpc
xrpld.rpc ~= xrpld.overlay
Loop: xrpld.perflog xrpld.rpc
xrpld.rpc ~= xrpld.perflog

View File

@@ -1,4 +1,6 @@
libxrpl.basics > xrpl.basics
libxrpl.core > xrpl.basics
libxrpl.core > xrpl.core
libxrpl.crypto > xrpl.basics
libxrpl.json > xrpl.basics
libxrpl.json > xrpl.json
@@ -8,6 +10,10 @@ libxrpl.ledger > xrpl.ledger
libxrpl.ledger > xrpl.protocol
libxrpl.net > xrpl.basics
libxrpl.net > xrpl.net
libxrpl.nodestore > xrpl.basics
libxrpl.nodestore > xrpl.json
libxrpl.nodestore > xrpl.nodestore
libxrpl.nodestore > xrpl.protocol
libxrpl.protocol > xrpl.basics
libxrpl.protocol > xrpl.json
libxrpl.protocol > xrpl.protocol
@@ -18,24 +24,28 @@ libxrpl.server > xrpl.basics
libxrpl.server > xrpl.json
libxrpl.server > xrpl.protocol
libxrpl.server > xrpl.server
libxrpl.shamap > xrpl.basics
libxrpl.shamap > xrpl.protocol
libxrpl.shamap > xrpl.shamap
test.app > test.jtx
test.app > test.rpc
test.app > test.toplevel
test.app > test.unit_test
test.app > xrpl.basics
test.app > xrpl.core
test.app > xrpld.app
test.app > xrpld.core
test.app > xrpld.nodestore
test.app > xrpld.overlay
test.app > xrpld.rpc
test.app > xrpl.json
test.app > xrpl.ledger
test.app > xrpl.nodestore
test.app > xrpl.protocol
test.app > xrpl.resource
test.basics > test.jtx
test.basics > test.unit_test
test.basics > xrpl.basics
test.basics > xrpld.perflog
test.basics > xrpl.core
test.basics > xrpld.rpc
test.basics > xrpl.json
test.basics > xrpl.protocol
@@ -54,8 +64,8 @@ test.core > test.jtx
test.core > test.toplevel
test.core > test.unit_test
test.core > xrpl.basics
test.core > xrpl.core
test.core > xrpld.core
test.core > xrpld.perflog
test.core > xrpl.json
test.core > xrpl.server
test.csf > xrpl.basics
@@ -86,8 +96,7 @@ test.nodestore > test.toplevel
test.nodestore > test.unit_test
test.nodestore > xrpl.basics
test.nodestore > xrpld.core
test.nodestore > xrpld.nodestore
test.nodestore > xrpld.unity
test.nodestore > xrpl.nodestore
test.overlay > test.jtx
test.overlay > test.toplevel
test.overlay > test.unit_test
@@ -95,8 +104,9 @@ test.overlay > xrpl.basics
test.overlay > xrpld.app
test.overlay > xrpld.overlay
test.overlay > xrpld.peerfinder
test.overlay > xrpld.shamap
test.overlay > xrpl.nodestore
test.overlay > xrpl.protocol
test.overlay > xrpl.shamap
test.peerfinder > test.beast
test.peerfinder > test.unit_test
test.peerfinder > xrpl.basics
@@ -113,6 +123,7 @@ test.resource > xrpl.resource
test.rpc > test.jtx
test.rpc > test.toplevel
test.rpc > xrpl.basics
test.rpc > xrpl.core
test.rpc > xrpld.app
test.rpc > xrpld.core
test.rpc > xrpld.overlay
@@ -131,18 +142,24 @@ test.server > xrpl.json
test.server > xrpl.server
test.shamap > test.unit_test
test.shamap > xrpl.basics
test.shamap > xrpld.nodestore
test.shamap > xrpld.shamap
test.shamap > xrpl.nodestore
test.shamap > xrpl.protocol
test.shamap > xrpl.shamap
test.toplevel > test.csf
test.toplevel > xrpl.json
test.unit_test > xrpl.basics
tests.libxrpl > xrpl.basics
tests.libxrpl > xrpl.json
tests.libxrpl > xrpl.net
xrpl.core > xrpl.basics
xrpl.core > xrpl.json
xrpl.core > xrpl.ledger
xrpl.json > xrpl.basics
xrpl.ledger > xrpl.basics
xrpl.ledger > xrpl.protocol
xrpl.net > xrpl.basics
xrpl.nodestore > xrpl.basics
xrpl.nodestore > xrpl.protocol
xrpl.protocol > xrpl.basics
xrpl.protocol > xrpl.json
xrpl.resource > xrpl.basics
@@ -151,35 +168,35 @@ xrpl.resource > xrpl.protocol
xrpl.server > xrpl.basics
xrpl.server > xrpl.json
xrpl.server > xrpl.protocol
xrpl.shamap > xrpl.basics
xrpl.shamap > xrpl.nodestore
xrpl.shamap > xrpl.protocol
xrpld.app > test.unit_test
xrpld.app > xrpl.basics
xrpld.app > xrpl.core
xrpld.app > xrpld.conditions
xrpld.app > xrpld.consensus
xrpld.app > xrpld.nodestore
xrpld.app > xrpld.perflog
xrpld.app > xrpl.json
xrpld.app > xrpl.ledger
xrpld.app > xrpl.net
xrpld.app > xrpl.nodestore
xrpld.app > xrpl.protocol
xrpld.app > xrpl.resource
xrpld.app > xrpl.shamap
xrpld.conditions > xrpl.basics
xrpld.conditions > xrpl.protocol
xrpld.consensus > xrpl.basics
xrpld.consensus > xrpl.json
xrpld.consensus > xrpl.protocol
xrpld.core > xrpl.basics
xrpld.core > xrpl.core
xrpld.core > xrpl.json
xrpld.core > xrpl.net
xrpld.core > xrpl.protocol
xrpld.nodestore > xrpl.basics
xrpld.nodestore > xrpld.core
xrpld.nodestore > xrpld.unity
xrpld.nodestore > xrpl.json
xrpld.nodestore > xrpl.protocol
xrpld.overlay > xrpl.basics
xrpld.overlay > xrpl.core
xrpld.overlay > xrpld.core
xrpld.overlay > xrpld.peerfinder
xrpld.overlay > xrpld.perflog
xrpld.overlay > xrpl.json
xrpld.overlay > xrpl.protocol
xrpld.overlay > xrpl.resource
@@ -188,16 +205,17 @@ xrpld.peerfinder > xrpl.basics
xrpld.peerfinder > xrpld.core
xrpld.peerfinder > xrpl.protocol
xrpld.perflog > xrpl.basics
xrpld.perflog > xrpl.core
xrpld.perflog > xrpld.rpc
xrpld.perflog > xrpl.json
xrpld.rpc > xrpl.basics
xrpld.rpc > xrpl.core
xrpld.rpc > xrpld.core
xrpld.rpc > xrpld.nodestore
xrpld.rpc > xrpl.json
xrpld.rpc > xrpl.ledger
xrpld.rpc > xrpl.net
xrpld.rpc > xrpl.nodestore
xrpld.rpc > xrpl.protocol
xrpld.rpc > xrpl.resource
xrpld.rpc > xrpl.server
xrpld.shamap > xrpl.basics
xrpld.shamap > xrpld.nodestore
xrpld.shamap > xrpl.protocol
xrpld.shamap > xrpl.shamap

47
.github/scripts/rename/README.md vendored Normal file
View File

@@ -0,0 +1,47 @@
## Renaming ripple(d) to xrpl(d)
In the initial phases of development of the XRPL, the open source codebase was
called "rippled" and it remains with that name even today. Today, over 1000
nodes run the application, and code contributions have been submitted by
developers located around the world. The XRPL community is larger than ever.
In light of the decentralized and diversified nature of XRPL, we will rename any
references to `ripple` and `rippled` to `xrpl` and `xrpld`, when appropriate.
See [here](https://xls.xrpl.org/xls/XLS-0095-rename-rippled-to-xrpld.html) for
more information.
### Scripts
To facilitate this transition, there will be multiple scripts that developers
can run on their own PRs and forks to minimize conflicts. Each script should be
run from the repository root.
1. `.github/scripts/rename/definitions.sh`: This script will rename all
definitions, such as include guards, from `RIPPLE_XXX` and `RIPPLED_XXX` to
`XRPL_XXX`.
2. `.github/scripts/rename/copyright.sh`: This script will remove superfluous
copyright notices.
3. `.github/scripts/rename/cmake.sh`: This script will rename all CMake files
from `RippleXXX.cmake` or `RippledXXX.cmake` to `XrplXXX.cmake`, and any
references to `ripple` and `rippled` (with or without capital letters) to
`xrpl` and `xrpld`, respectively. The name of the binary will remain as-is,
and will only be renamed to `xrpld` by a later script.
4. `.github/scripts/rename/binary.sh`: This script will rename the binary from
`rippled` to `xrpld`, and reverses the symlink so that `rippled` points to
the `xrpld` binary.
5. `.github/scripts/rename/namespace.sh`: This script will rename the C++
namespaces from `ripple` to `xrpl`.
6. `.github/scripts/rename/config.sh`: This script will rename the config from
`rippled.cfg` to `xrpld.cfg`, and updating the code accordingly. The old
filename will still be accepted.
You can run all these scripts from the repository root as follows:
```shell
./.github/scripts/rename/definitions.sh .
./.github/scripts/rename/copyright.sh .
./.github/scripts/rename/cmake.sh .
./.github/scripts/rename/binary.sh .
./.github/scripts/rename/namespace.sh .
./.github/scripts/rename/config.sh .
```

54
.github/scripts/rename/binary.sh vendored Executable file
View File

@@ -0,0 +1,54 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# On MacOS, ensure that GNU sed is installed and available as `gsed`.
SED_COMMAND=sed
if [[ "${OSTYPE}" == 'darwin'* ]]; then
if ! command -v gsed &> /dev/null; then
echo "Error: gsed is not installed. Please install it using 'brew install gnu-sed'."
exit 1
fi
SED_COMMAND=gsed
fi
# This script changes the binary name from `rippled` to `xrpld`, and reverses
# the symlink that currently points from `xrpld` to `rippled` so that it points
# from `rippled` to `xrpld` instead.
# Usage: .github/scripts/rename/binary.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
pushd ${DIRECTORY}
# Remove the binary name override added by the cmake.sh script.
${SED_COMMAND} -z -i -E 's@\s+# For the time being.+"rippled"\)@@' cmake/XrplCore.cmake
# Reverse the symlink.
${SED_COMMAND} -i -E 's@create_symbolic_link\(rippled@create_symbolic_link(xrpld@' cmake/XrplInstall.cmake
${SED_COMMAND} -i -E 's@/xrpld\$\{suffix\}@/rippled${suffix}@' cmake/XrplInstall.cmake
# Rename references to the binary.
${SED_COMMAND} -i -E 's@rippled@xrpld@g' BUILD.md
${SED_COMMAND} -i -E 's@rippled@xrpld@g' CONTRIBUTING.md
${SED_COMMAND} -i -E 's@rippled@xrpld@g' .github/ISSUE_TEMPLATE/bug_report.md
# Restore and/or fix certain renames. The pre-commit hook will update the
# formatting upon saving/committing.
${SED_COMMAND} -i -E 's@ripple/xrpld@XRPLF/rippled@g' BUILD.md
${SED_COMMAND} -i -E 's@XRPLF/xrpld@XRPLF/rippled@g' BUILD.md
${SED_COMMAND} -i -E 's@xrpld \(`xrpld`\)@xrpld@g' BUILD.md
${SED_COMMAND} -i -E 's@XRPLF/xrpld@XRPLF/rippled@g' CONTRIBUTING.md
popd
echo "Processing complete."

92
.github/scripts/rename/cmake.sh vendored Executable file
View File

@@ -0,0 +1,92 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# On MacOS, ensure that GNU sed and head are installed and available as `gsed`
# and `ghead`, respectively.
SED_COMMAND=sed
HEAD_COMMAND=head
if [[ "${OSTYPE}" == 'darwin'* ]]; then
if ! command -v gsed &> /dev/null; then
echo "Error: gsed is not installed. Please install it using 'brew install gnu-sed'."
exit 1
fi
SED_COMMAND=gsed
if ! command -v ghead &> /dev/null; then
echo "Error: ghead is not installed. Please install it using 'brew install coreutils'."
exit 1
fi
HEAD_COMMAND=ghead
fi
# This script renames CMake files from `RippleXXX.cmake` or `RippledXXX.cmake`
# to `XrplXXX.cmake`, and any references to `ripple` and `rippled` (with or
# without capital letters) to `xrpl` and `xrpld`, respectively. The name of the
# binary will remain as-is, and will only be renamed to `xrpld` in a different
# script, but the proto file will be renamed.
# Usage: .github/scripts/rename/cmake.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
pushd ${DIRECTORY}
# Rename the files.
find cmake -type f -name 'Rippled*.cmake' -exec bash -c 'mv "${1}" "${1/Rippled/Xrpl}"' - {} \;
find cmake -type f -name 'Ripple*.cmake' -exec bash -c 'mv "${1}" "${1/Ripple/Xrpl}"' - {} \;
if [ -e cmake/xrpl_add_test.cmake ]; then
mv cmake/xrpl_add_test.cmake cmake/XrplAddTest.cmake
fi
if [ -e include/xrpl/proto/ripple.proto ]; then
mv include/xrpl/proto/ripple.proto include/xrpl/proto/xrpl.proto
fi
# Rename inside the files.
find cmake -type f -name '*.cmake' | while read -r FILE; do
echo "Processing file: ${FILE}"
${SED_COMMAND} -i 's/Rippled/Xrpld/g' "${FILE}"
${SED_COMMAND} -i 's/Ripple/Xrpl/g' "${FILE}"
${SED_COMMAND} -i 's/rippled/xrpld/g' "${FILE}"
${SED_COMMAND} -i 's/ripple/xrpl/g' "${FILE}"
done
${SED_COMMAND} -i -E 's/Rippled?/Xrpl/g' CMakeLists.txt
${SED_COMMAND} -i 's/ripple/xrpl/g' CMakeLists.txt
${SED_COMMAND} -i 's/include(xrpl_add_test)/include(XrplAddTest)/' src/tests/libxrpl/CMakeLists.txt
${SED_COMMAND} -i 's/ripple.pb.h/xrpl.pb.h/' include/xrpl/protocol/messages.h
${SED_COMMAND} -i 's/ripple.pb.h/xrpl.pb.h/' BUILD.md
${SED_COMMAND} -i 's/ripple.pb.h/xrpl.pb.h/' BUILD.md
# Restore the name of the validator keys repository.
${SED_COMMAND} -i 's@xrpl/validator-keys-tool@ripple/validator-keys-tool@' cmake/XrplValidatorKeys.cmake
# Ensure the name of the binary and config remain 'rippled' for now.
${SED_COMMAND} -i -E 's/xrpld(-example)?\.cfg/rippled\1.cfg/g' cmake/XrplInstall.cmake
if grep -q '"xrpld"' cmake/XrplCore.cmake; then
# The script has been rerun, so just restore the name of the binary.
${SED_COMMAND} -i 's/"xrpld"/"rippled"/' cmake/XrplCore.cmake
elif ! grep -q '"rippled"' cmake/XrplCore.cmake; then
${HEAD_COMMAND} -n -1 cmake/XrplCore.cmake > cmake.tmp
echo ' # For the time being, we will keep the name of the binary as it was.' >> cmake.tmp
echo ' set_target_properties(xrpld PROPERTIES OUTPUT_NAME "rippled")' >> cmake.tmp
tail -1 cmake/XrplCore.cmake >> cmake.tmp
mv cmake.tmp cmake/XrplCore.cmake
fi
# Restore the symlink from 'xrpld' to 'rippled'.
${SED_COMMAND} -i -E 's@create_symbolic_link\(xrpld@create_symbolic_link(rippled@' cmake/XrplInstall.cmake
# Remove the symlink that previously pointed from 'ripple' to 'xrpl' but now is
# no longer needed.
${SED_COMMAND} -z -i -E 's@install\(CODE.+CMAKE_INSTALL_INCLUDEDIR}/xrpl\)\n"\)\n+@@' cmake/XrplInstall.cmake
popd
echo "Renaming complete."

72
.github/scripts/rename/config.sh vendored Executable file
View File

@@ -0,0 +1,72 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# On MacOS, ensure that GNU sed is installed and available as `gsed`.
SED_COMMAND=sed
if [[ "${OSTYPE}" == 'darwin'* ]]; then
if ! command -v gsed &> /dev/null; then
echo "Error: gsed is not installed. Please install it using 'brew install gnu-sed'."
exit 1
fi
SED_COMMAND=gsed
fi
# This script renames the config from `rippled.cfg` to `xrpld.cfg`, and updates
# the code accordingly. The old filename will still be accepted.
# Usage: .github/scripts/rename/config.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
pushd ${DIRECTORY}
# Add the xrpld.cfg to the .gitignore.
if ! grep -q 'xrpld.cfg' .gitignore; then
${SED_COMMAND} -i '/rippled.cfg/a\
/xrpld.cfg' .gitignore
fi
# Rename the files.
if [ -e rippled.cfg ]; then
mv rippled.cfg xrpld.cfg
fi
if [ -e cfg/rippled-example.cfg ]; then
mv cfg/rippled-example.cfg cfg/xrpld-example.cfg
fi
# Rename inside the files.
DIRECTORIES=("cfg" "cmake" "include" "src")
for DIRECTORY in "${DIRECTORIES[@]}"; do
echo "Processing directory: ${DIRECTORY}"
find "${DIRECTORY}" -type f \( -name "*.h" -o -name "*.hpp" -o -name "*.ipp" -o -name "*.cpp" -o -name "*.cmake" -o -name "*.txt" -o -name "*.cfg" -o -name "*.md" \) | while read -r FILE; do
echo "Processing file: ${FILE}"
${SED_COMMAND} -i -E 's/rippled(-example)?[ .]cfg/xrpld\1.cfg/g' "${FILE}"
done
done
${SED_COMMAND} -i 's/rippled/xrpld/g' cfg/xrpld-example.cfg
${SED_COMMAND} -i 's/rippled/xrpld/g' src/test/core/Config_test.cpp
${SED_COMMAND} -i 's/ripplevalidators/xrplvalidators/g' src/test/core/Config_test.cpp # cspell: disable-line
${SED_COMMAND} -i 's/rippleConfig/xrpldConfig/g' src/test/core/Config_test.cpp
${SED_COMMAND} -i 's@ripple/@xrpld/@g' src/test/core/Config_test.cpp
${SED_COMMAND} -i 's/Rippled/File/g' src/test/core/Config_test.cpp
# Restore the old config file name in the code that maintains support for now.
${SED_COMMAND} -i 's/configLegacyName = "xrpld.cfg"/configLegacyName = "rippled.cfg"/g' src/xrpld/core/detail/Config.cpp
# Restore an URL.
${SED_COMMAND} -i 's/connect-your-xrpld-to-the-xrp-test-net.html/connect-your-rippled-to-the-xrp-test-net.html/g' cfg/xrpld-example.cfg
popd
echo "Renaming complete."

103
.github/scripts/rename/copyright.sh vendored Executable file
View File

@@ -0,0 +1,103 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# On MacOS, ensure that GNU sed is installed and available as `gsed`.
SED_COMMAND=sed
if [[ "${OSTYPE}" == 'darwin'* ]]; then
if ! command -v gsed &> /dev/null; then
echo "Error: gsed is not installed. Please install it using 'brew install gnu-sed'."
exit 1
fi
SED_COMMAND=gsed
fi
# This script removes superfluous copyright notices in source and header files
# in this project. Specifically, it removes all notices referencing Ripple,
# XRPLF, and certain individual contributors upon mutual agreement, so the one
# in the LICENSE.md file applies throughout. Copyright notices referencing
# external contributions, e.g. from Bitcoin, remain as-is.
# Usage: .github/scripts/rename/copyright.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
pushd ${DIRECTORY}
# Prevent sed and echo from removing newlines and tabs in string literals by
# temporarily replacing them with placeholders. This only affects one file.
PLACEHOLDER_NEWLINE="__NEWLINE__"
PLACEHOLDER_TAB="__TAB__"
${SED_COMMAND} -i -E "s@\\\n@${PLACEHOLDER_NEWLINE}@g" src/test/rpc/ValidatorInfo_test.cpp
${SED_COMMAND} -i -E "s@\\\t@${PLACEHOLDER_TAB}@g" src/test/rpc/ValidatorInfo_test.cpp
# Process the include/ and src/ directories.
DIRECTORIES=("include" "src")
for DIRECTORY in "${DIRECTORIES[@]}"; do
echo "Processing directory: ${DIRECTORY}"
find "${DIRECTORY}" -type f \( -name "*.h" -o -name "*.hpp" -o -name "*.ipp" -o -name "*.cpp" -o -name "*.macro" \) | while read -r FILE; do
echo "Processing file: ${FILE}"
# Handle the cases where the copyright notice is enclosed in /* ... */
# and usually surrounded by //---- and //======.
${SED_COMMAND} -z -i -E 's@^//-------+\n+@@' "${FILE}"
${SED_COMMAND} -z -i -E 's@^.*Copyright.+(Ripple|Bougalis|Falco|Hinnant|Null|Ritchford|XRPLF).+PERFORMANCE OF THIS SOFTWARE\.\n\*/\n+@@' "${FILE}" # cspell: ignore Bougalis Falco Hinnant Ritchford
${SED_COMMAND} -z -i -E 's@^//=======+\n+@@' "${FILE}"
# Handle the cases where the copyright notice is commented out with //.
${SED_COMMAND} -z -i -E 's@^//\n// Copyright.+Falco \(vinnie dot falco at gmail dot com\)\n//\n+@@' "${FILE}" # cspell: ignore Vinnie Falco
done
done
# Restore copyright notices that were removed from specific files, without
# restoring the verbiage that is already present in LICENSE.md. Ensure that if
# the script is run multiple times, duplicate notices are not added.
if ! grep -q 'Raw Material Software' include/xrpl/beast/core/CurrentThreadName.h; then
echo -e "// Portions of this file are from JUCE (http://www.juce.com).\n// Copyright (c) 2013 - Raw Material Software Ltd.\n// Please visit http://www.juce.com\n\n$(cat include/xrpl/beast/core/CurrentThreadName.h)" > include/xrpl/beast/core/CurrentThreadName.h
fi
if ! grep -q 'Dev Null' src/test/app/NetworkID_test.cpp; then
echo -e "// Copyright (c) 2020 Dev Null Productions\n\n$(cat src/test/app/NetworkID_test.cpp)" > src/test/app/NetworkID_test.cpp
fi
if ! grep -q 'Dev Null' src/test/app/tx/apply_test.cpp; then
echo -e "// Copyright (c) 2020 Dev Null Productions\n\n$(cat src/test/app/tx/apply_test.cpp)" > src/test/app/tx/apply_test.cpp
fi
if ! grep -q 'Dev Null' src/test/rpc/ManifestRPC_test.cpp; then
echo -e "// Copyright (c) 2020 Dev Null Productions\n\n$(cat src/test/rpc/ManifestRPC_test.cpp)" > src/test/rpc/ManifestRPC_test.cpp
fi
if ! grep -q 'Dev Null' src/test/rpc/ValidatorInfo_test.cpp; then
echo -e "// Copyright (c) 2020 Dev Null Productions\n\n$(cat src/test/rpc/ValidatorInfo_test.cpp)" > src/test/rpc/ValidatorInfo_test.cpp
fi
if ! grep -q 'Dev Null' src/xrpld/rpc/handlers/DoManifest.cpp; then
echo -e "// Copyright (c) 2019 Dev Null Productions\n\n$(cat src/xrpld/rpc/handlers/DoManifest.cpp)" > src/xrpld/rpc/handlers/DoManifest.cpp
fi
if ! grep -q 'Dev Null' src/xrpld/rpc/handlers/ValidatorInfo.cpp; then
echo -e "// Copyright (c) 2019 Dev Null Productions\n\n$(cat src/xrpld/rpc/handlers/ValidatorInfo.cpp)" > src/xrpld/rpc/handlers/ValidatorInfo.cpp
fi
if ! grep -q 'Bougalis' include/xrpl/basics/SlabAllocator.h; then
echo -e "// Copyright (c) 2022, Nikolaos D. Bougalis <nikb@bougalis.net>\n\n$(cat include/xrpl/basics/SlabAllocator.h)" > include/xrpl/basics/SlabAllocator.h # cspell: ignore Nikolaos Bougalis nikb
fi
if ! grep -q 'Bougalis' include/xrpl/basics/spinlock.h; then
echo -e "// Copyright (c) 2022, Nikolaos D. Bougalis <nikb@bougalis.net>\n\n$(cat include/xrpl/basics/spinlock.h)" > include/xrpl/basics/spinlock.h # cspell: ignore Nikolaos Bougalis nikb
fi
if ! grep -q 'Bougalis' include/xrpl/basics/tagged_integer.h; then
echo -e "// Copyright (c) 2014, Nikolaos D. Bougalis <nikb@bougalis.net>\n\n$(cat include/xrpl/basics/tagged_integer.h)" > include/xrpl/basics/tagged_integer.h # cspell: ignore Nikolaos Bougalis nikb
fi
if ! grep -q 'Ritchford' include/xrpl/beast/utility/Zero.h; then
echo -e "// Copyright (c) 2014, Tom Ritchford <tom@swirly.com>\n\n$(cat include/xrpl/beast/utility/Zero.h)" > include/xrpl/beast/utility/Zero.h # cspell: ignore Ritchford
fi
# Restore newlines and tabs in string literals in the affected file.
${SED_COMMAND} -i -E "s@${PLACEHOLDER_NEWLINE}@\\\n@g" src/test/rpc/ValidatorInfo_test.cpp
${SED_COMMAND} -i -E "s@${PLACEHOLDER_TAB}@\\\t@g" src/test/rpc/ValidatorInfo_test.cpp
popd
echo "Removal complete."

42
.github/scripts/rename/definitions.sh vendored Executable file
View File

@@ -0,0 +1,42 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# On MacOS, ensure that GNU sed is installed and available as `gsed`.
SED_COMMAND=sed
if [[ "${OSTYPE}" == 'darwin'* ]]; then
if ! command -v gsed &> /dev/null; then
echo "Error: gsed is not installed. Please install it using 'brew install gnu-sed'."
exit 1
fi
SED_COMMAND=gsed
fi
# This script renames definitions, such as include guards, in this project.
# Specifically, it renames "RIPPLED_XXX" and "RIPPLE_XXX" to "XRPL_XXX" by
# scanning all cmake, header, and source files in the specified directory and
# its subdirectories.
# Usage: .github/scripts/rename/definitions.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
find "${DIRECTORY}" -type f \( -name "*.h" -o -name "*.hpp" -o -name "*.ipp" -o -name "*.cpp" \) | while read -r FILE; do
echo "Processing file: ${FILE}"
${SED_COMMAND} -i -E 's@#(define|endif|if|ifdef|ifndef)(.*)(RIPPLED_|RIPPLE_)([A-Z0-9_]+)@#\1\2XRPL_\4@g' "${FILE}"
done
find "${DIRECTORY}" -type f \( -name "*.cmake" -o -name "*.txt" \) | while read -r FILE; do
echo "Processing file: ${FILE}"
${SED_COMMAND} -i -E 's@(RIPPLED_|RIPPLE_)([A-Z0-9_]+)@XRPL_\2@g' "${FILE}"
done
echo "Renaming complete."

30
.github/scripts/rename/include.sh vendored Executable file
View File

@@ -0,0 +1,30 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# This script checks whether there are no new include guards introduced by a new
# PR, as header files should use "#pragma once" instead. The script assumes any
# include guards will use "XRPL_" as prefix.
# Usage: .github/scripts/rename/include.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
find "${DIRECTORY}" -type f \( -name "*.h" -o -name "*.hpp" -o -name "*.ipp" \) | while read -r FILE; do
echo "Processing file: ${FILE}"
if grep -q "#ifndef XRPL_" "${FILE}"; then
echo "Please replace all include guards by #pragma once."
exit 1
fi
done
echo "Checking complete."

58
.github/scripts/rename/namespace.sh vendored Executable file
View File

@@ -0,0 +1,58 @@
#!/bin/bash
# Exit the script as soon as an error occurs.
set -e
# On MacOS, ensure that GNU sed is installed and available as `gsed`.
SED_COMMAND=sed
if [[ "${OSTYPE}" == 'darwin'* ]]; then
if ! command -v gsed &> /dev/null; then
echo "Error: gsed is not installed. Please install it using 'brew install gnu-sed'."
exit 1
fi
SED_COMMAND=gsed
fi
# This script renames the `ripple` namespace to `xrpl` in this project.
# Specifically, it renames all occurrences of `namespace ripple` and `ripple::`
# to `namespace xrpl` and `xrpl::`, respectively, by scanning all header and
# source files in the specified directory and its subdirectories, as well as any
# occurrences in the documentation. It also renames them in the test suites.
# Usage: .github/scripts/rename/namespace.sh <repository directory>
if [ "$#" -ne 1 ]; then
echo "Usage: $0 <repository directory>"
exit 1
fi
DIRECTORY=$1
echo "Processing directory: ${DIRECTORY}"
if [ ! -d "${DIRECTORY}" ]; then
echo "Error: Directory '${DIRECTORY}' does not exist."
exit 1
fi
pushd ${DIRECTORY}
DIRECTORIES=("include" "src" "tests")
for DIRECTORY in "${DIRECTORIES[@]}"; do
echo "Processing directory: ${DIRECTORY}"
find "${DIRECTORY}" -type f \( -name "*.h" -o -name "*.hpp" -o -name "*.ipp" -o -name "*.cpp" \) | while read -r FILE; do
echo "Processing file: ${FILE}"
${SED_COMMAND} -i 's/namespace ripple/namespace xrpl/g' "${FILE}"
${SED_COMMAND} -i 's/ripple::/xrpl::/g' "${FILE}"
${SED_COMMAND} -i -E 's/(BEAST_DEFINE_TESTSUITE.+)ripple(.+)/\1xrpl\2/g' "${FILE}"
done
done
# Special case for NuDBFactory that has ripple twice in the test suite name.
${SED_COMMAND} -i -E 's/(BEAST_DEFINE_TESTSUITE.+)ripple(.+)/\1xrpl\2/g' src/test/nodestore/NuDBFactory_test.cpp
DIRECTORY=$1
find "${DIRECTORY}" -type f -name "*.md" | while read -r FILE; do
echo "Processing file: ${FILE}"
${SED_COMMAND} -i 's/ripple::/xrpl::/g' "${FILE}"
done
popd
echo "Renaming complete."

View File

@@ -2,11 +2,12 @@
import argparse
import itertools
import json
from pathlib import Path
from dataclasses import dataclass
from pathlib import Path
THIS_DIR = Path(__file__).parent.resolve()
@dataclass
class Config:
architecture: list[dict]
@@ -14,12 +15,13 @@ class Config:
build_type: list[str]
cmake_args: list[str]
'''
"""
Generate a strategy matrix for GitHub Actions CI.
On each PR commit we will build a selection of Debian, RHEL, Ubuntu, MacOS, and
Windows configurations, while upon merge into the develop, release, or master
branches, we will build all configurations, and test most of them.
Windows configurations, while upon merge into the develop or release branches,
we will build all configurations, and test most of them.
We will further set additional CMake arguments as follows:
- All builds will have the `tests`, `werr`, and `xrpld` options.
@@ -27,171 +29,305 @@ We will further set additional CMake arguments as follows:
- All release builds will have the `assert` option.
- Certain Debian Bookworm configurations will change the reference fee, enable
codecov, and enable voidstar in PRs.
'''
"""
def generate_strategy_matrix(all: bool, config: Config) -> list:
configurations = []
for architecture, os, build_type, cmake_args in itertools.product(config.architecture, config.os, config.build_type, config.cmake_args):
for architecture, os, build_type, cmake_args in itertools.product(
config.architecture, config.os, config.build_type, config.cmake_args
):
# The default CMake target is 'all' for Linux and MacOS and 'install'
# for Windows, but it can get overridden for certain configurations.
cmake_target = 'install' if os["distro_name"] == 'windows' else 'all'
cmake_target = "install" if os["distro_name"] == "windows" else "all"
# We build and test all configurations by default, except for Windows in
# Debug, because it is too slow, as well as when code coverage is
# enabled as that mode already runs the tests.
build_only = False
if os['distro_name'] == 'windows' and build_type == 'Debug':
if os["distro_name"] == "windows" and build_type == "Debug":
build_only = True
# Only generate a subset of configurations in PRs.
if not all:
# Debian:
# - Bookworm using GCC 13: Release and Unity on linux/amd64, set
# the reference fee to 500.
# - Bookworm using GCC 15: Debug and no Unity on linux/amd64, enable
# code coverage (which will be done below).
# - Bookworm using Clang 16: Debug and no Unity on linux/arm64,
# enable voidstar.
# - Bookworm using Clang 17: Release and no Unity on linux/amd64,
# set the reference fee to 1000.
# - Bookworm using Clang 20: Debug and Unity on linux/amd64.
if os['distro_name'] == 'debian':
# - Bookworm using GCC 13: Release on linux/amd64, set the reference
# fee to 500.
# - Bookworm using GCC 15: Debug on linux/amd64, enable code
# coverage (which will be done below).
# - Bookworm using Clang 16: Debug on linux/arm64, enable voidstar.
# - Bookworm using Clang 17: Release on linux/amd64, set the
# reference fee to 1000.
# - Bookworm using Clang 20: Debug on linux/amd64.
if os["distro_name"] == "debian":
skip = True
if os['distro_version'] == 'bookworm':
if f'{os['compiler_name']}-{os['compiler_version']}' == 'gcc-13' and build_type == 'Release' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'linux/amd64':
cmake_args = f'-DUNIT_TEST_REFERENCE_FEE=500 {cmake_args}'
if os["distro_version"] == "bookworm":
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-13"
and build_type == "Release"
and architecture["platform"] == "linux/amd64"
):
cmake_args = f"-DUNIT_TEST_REFERENCE_FEE=500 {cmake_args}"
skip = False
if f'{os['compiler_name']}-{os['compiler_version']}' == 'gcc-15' and build_type == 'Debug' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'linux/amd64':
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-15"
and build_type == "Debug"
and architecture["platform"] == "linux/amd64"
):
skip = False
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-16' and build_type == 'Debug' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'linux/arm64':
cmake_args = f'-Dvoidstar=ON {cmake_args}'
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-16"
and build_type == "Debug"
and architecture["platform"] == "linux/arm64"
):
cmake_args = f"-Dvoidstar=ON {cmake_args}"
skip = False
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-17' and build_type == 'Release' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'linux/amd64':
cmake_args = f'-DUNIT_TEST_REFERENCE_FEE=1000 {cmake_args}'
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-17"
and build_type == "Release"
and architecture["platform"] == "linux/amd64"
):
cmake_args = f"-DUNIT_TEST_REFERENCE_FEE=1000 {cmake_args}"
skip = False
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-20' and build_type == 'Debug' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'linux/amd64':
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-20"
and build_type == "Debug"
and architecture["platform"] == "linux/amd64"
):
skip = False
if skip:
continue
# RHEL:
# - 9.4 using GCC 12: Debug and Unity on linux/amd64.
# - 9.6 using Clang: Release and no Unity on linux/amd64.
if os['distro_name'] == 'rhel':
# - 9 using GCC 12: Debug on linux/amd64.
# - 10 using Clang: Release on linux/amd64.
if os["distro_name"] == "rhel":
skip = True
if os['distro_version'] == '9.4':
if f'{os['compiler_name']}-{os['compiler_version']}' == 'gcc-12' and build_type == 'Debug' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'linux/amd64':
if os["distro_version"] == "9":
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-12"
and build_type == "Debug"
and architecture["platform"] == "linux/amd64"
):
skip = False
elif os['distro_version'] == '9.6':
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-any' and build_type == 'Release' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'linux/amd64':
elif os["distro_version"] == "10":
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-any"
and build_type == "Release"
and architecture["platform"] == "linux/amd64"
):
skip = False
if skip:
continue
# Ubuntu:
# - Jammy using GCC 12: Debug and no Unity on linux/arm64.
# - Noble using GCC 14: Release and Unity on linux/amd64.
# - Noble using Clang 18: Debug and no Unity on linux/amd64.
# - Noble using Clang 19: Release and Unity on linux/arm64.
if os['distro_name'] == 'ubuntu':
# - Jammy using GCC 12: Debug on linux/arm64.
# - Noble using GCC 14: Release on linux/amd64.
# - Noble using Clang 18: Debug on linux/amd64.
# - Noble using Clang 19: Release on linux/arm64.
if os["distro_name"] == "ubuntu":
skip = True
if os['distro_version'] == 'jammy':
if f'{os['compiler_name']}-{os['compiler_version']}' == 'gcc-12' and build_type == 'Debug' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'linux/arm64':
if os["distro_version"] == "jammy":
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-12"
and build_type == "Debug"
and architecture["platform"] == "linux/arm64"
):
skip = False
elif os['distro_version'] == 'noble':
if f'{os['compiler_name']}-{os['compiler_version']}' == 'gcc-14' and build_type == 'Release' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'linux/amd64':
elif os["distro_version"] == "noble":
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-14"
and build_type == "Release"
and architecture["platform"] == "linux/amd64"
):
skip = False
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-18' and build_type == 'Debug' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'linux/amd64':
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-18"
and build_type == "Debug"
and architecture["platform"] == "linux/amd64"
):
skip = False
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-19' and build_type == 'Release' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'linux/arm64':
if (
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-19"
and build_type == "Release"
and architecture["platform"] == "linux/arm64"
):
skip = False
if skip:
continue
# MacOS:
# - Debug and no Unity on macos/arm64.
if os['distro_name'] == 'macos' and not (build_type == 'Debug' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'macos/arm64'):
# - Debug on macos/arm64.
if os["distro_name"] == "macos" and not (
build_type == "Debug" and architecture["platform"] == "macos/arm64"
):
continue
# Windows:
# - Release and Unity on windows/amd64.
if os['distro_name'] == 'windows' and not (build_type == 'Release' and '-Dunity=ON' in cmake_args and architecture['platform'] == 'windows/amd64'):
# - Release on windows/amd64.
if os["distro_name"] == "windows" and not (
build_type == "Release" and architecture["platform"] == "windows/amd64"
):
continue
# Additional CMake arguments.
cmake_args = f'{cmake_args} -Dtests=ON -Dwerr=ON -Dxrpld=ON'
if not f'{os['compiler_name']}-{os['compiler_version']}' in ['gcc-12', 'clang-16']:
cmake_args = f'{cmake_args} -Dwextra=ON'
if build_type == 'Release':
cmake_args = f'{cmake_args} -Dassert=ON'
cmake_args = f"{cmake_args} -Dtests=ON -Dwerr=ON -Dxrpld=ON"
if not f"{os['compiler_name']}-{os['compiler_version']}" in [
"gcc-12",
"clang-16",
]:
cmake_args = f"{cmake_args} -Dwextra=ON"
if build_type == "Release":
cmake_args = f"{cmake_args} -Dassert=ON"
# We skip all RHEL on arm64 due to a build failure that needs further
# investigation.
if os['distro_name'] == 'rhel' and architecture['platform'] == 'linux/arm64':
if os["distro_name"] == "rhel" and architecture["platform"] == "linux/arm64":
continue
# We skip all clang-20 on arm64 due to boost 1.86 build error
if f'{os['compiler_name']}-{os['compiler_version']}' == 'clang-20' and architecture['platform'] == 'linux/arm64':
# We skip all clang 20+ on arm64 due to Boost build error.
if (
f"{os['compiler_name']}-{os['compiler_version']}"
in ["clang-20", "clang-21"]
and architecture["platform"] == "linux/arm64"
):
continue
# Enable code coverage for Debian Bookworm using GCC 15 in Debug and no
# Unity on linux/amd64
if f'{os['compiler_name']}-{os['compiler_version']}' == 'gcc-15' and build_type == 'Debug' and '-Dunity=OFF' in cmake_args and architecture['platform'] == 'linux/amd64':
cmake_args = f'-Dcoverage=ON -Dcoverage_format=xml -DCODE_COVERAGE_VERBOSE=ON -DCMAKE_C_FLAGS=-O0 -DCMAKE_CXX_FLAGS=-O0 {cmake_args}'
cmake_target = 'coverage'
build_only = True
# Enable code coverage for Debian Bookworm using GCC 15 in Debug on
# linux/amd64
if (
f"{os['distro_name']}-{os['distro_version']}" == "debian-bookworm"
and f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-15"
and build_type == "Debug"
and architecture["platform"] == "linux/amd64"
):
cmake_args = f"{cmake_args} -Dcoverage=ON -Dcoverage_format=xml -DCODE_COVERAGE_VERBOSE=ON -DCMAKE_C_FLAGS=-O0 -DCMAKE_CXX_FLAGS=-O0"
# Enable unity build for Ubuntu Jammy using GCC 12 in Debug on
# linux/amd64.
if (
f"{os['distro_name']}-{os['distro_version']}" == "ubuntu-jammy"
and f"{os['compiler_name']}-{os['compiler_version']}" == "gcc-12"
and build_type == "Debug"
and architecture["platform"] == "linux/amd64"
):
cmake_args = f"{cmake_args} -Dunity=ON"
# Generate a unique name for the configuration, e.g. macos-arm64-debug
# or debian-bookworm-gcc-12-amd64-release-unity.
config_name = os['distro_name']
if (n := os['distro_version']) != '':
config_name += f'-{n}'
if (n := os['compiler_name']) != '':
config_name += f'-{n}'
if (n := os['compiler_version']) != '':
config_name += f'-{n}'
config_name += f'-{architecture['platform'][architecture['platform'].find('/')+1:]}'
config_name += f'-{build_type.lower()}'
if '-Dunity=ON' in cmake_args:
config_name += '-unity'
# or debian-bookworm-gcc-12-amd64-release.
config_name = os["distro_name"]
if (n := os["distro_version"]) != "":
config_name += f"-{n}"
if (n := os["compiler_name"]) != "":
config_name += f"-{n}"
if (n := os["compiler_version"]) != "":
config_name += f"-{n}"
config_name += (
f"-{architecture['platform'][architecture['platform'].find('/')+1:]}"
)
config_name += f"-{build_type.lower()}"
if "-Dcoverage=ON" in cmake_args:
config_name += "-coverage"
if "-Dunity=ON" in cmake_args:
config_name += "-unity"
# Add the configuration to the list, with the most unique fields first,
# so that they are easier to identify in the GitHub Actions UI, as long
# names get truncated.
configurations.append({
'config_name': config_name,
'cmake_args': cmake_args,
'cmake_target': cmake_target,
'build_only': build_only,
'build_type': build_type,
'os': os,
'architecture': architecture,
})
# Add Address and Thread (both coupled with UB) sanitizers for specific bookworm distros.
# GCC-Asan rippled-embedded tests are failing because of https://github.com/google/sanitizers/issues/856
if (
os["distro_version"] == "bookworm"
and f"{os['compiler_name']}-{os['compiler_version']}" == "clang-20"
):
# Add ASAN + UBSAN configuration.
configurations.append(
{
"config_name": config_name + "-asan-ubsan",
"cmake_args": cmake_args,
"cmake_target": cmake_target,
"build_only": build_only,
"build_type": build_type,
"os": os,
"architecture": architecture,
"sanitizers": "address,undefinedbehavior",
}
)
# TSAN is deactivated due to seg faults with latest compilers.
activate_tsan = False
if activate_tsan:
configurations.append(
{
"config_name": config_name + "-tsan-ubsan",
"cmake_args": cmake_args,
"cmake_target": cmake_target,
"build_only": build_only,
"build_type": build_type,
"os": os,
"architecture": architecture,
"sanitizers": "thread,undefinedbehavior",
}
)
else:
configurations.append(
{
"config_name": config_name,
"cmake_args": cmake_args,
"cmake_target": cmake_target,
"build_only": build_only,
"build_type": build_type,
"os": os,
"architecture": architecture,
"sanitizers": "",
}
)
return configurations
def read_config(file: Path) -> Config:
config = json.loads(file.read_text())
if config['architecture'] is None or config['os'] is None or config['build_type'] is None or config['cmake_args'] is None:
raise Exception('Invalid configuration file.')
if (
config["architecture"] is None
or config["os"] is None
or config["build_type"] is None
or config["cmake_args"] is None
):
raise Exception("Invalid configuration file.")
return Config(**config)
if __name__ == '__main__':
if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument('-a', '--all', help='Set to generate all configurations (generally used when merging a PR) or leave unset to generate a subset of configurations (generally used when committing to a PR).', action="store_true")
parser.add_argument('-c', '--config', help='Path to the JSON file containing the strategy matrix configurations.', required=False, type=Path)
parser.add_argument(
"-a",
"--all",
help="Set to generate all configurations (generally used when merging a PR) or leave unset to generate a subset of configurations (generally used when committing to a PR).",
action="store_true",
)
parser.add_argument(
"-c",
"--config",
help="Path to the JSON file containing the strategy matrix configurations.",
required=False,
type=Path,
)
args = parser.parse_args()
matrix = []
if args.config is None or args.config == '':
matrix += generate_strategy_matrix(args.all, read_config(THIS_DIR / "linux.json"))
matrix += generate_strategy_matrix(args.all, read_config(THIS_DIR / "macos.json"))
matrix += generate_strategy_matrix(args.all, read_config(THIS_DIR / "windows.json"))
if args.config is None or args.config == "":
matrix += generate_strategy_matrix(
args.all, read_config(THIS_DIR / "linux.json")
)
matrix += generate_strategy_matrix(
args.all, read_config(THIS_DIR / "macos.json")
)
matrix += generate_strategy_matrix(
args.all, read_config(THIS_DIR / "windows.json")
)
else:
matrix += generate_strategy_matrix(args.all, read_config(args.config))
# Generate the strategy matrix.
print(f'matrix={json.dumps({"include": matrix})}')
print(f"matrix={json.dumps({'include': matrix})}")

View File

@@ -14,141 +14,199 @@
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "gcc",
"compiler_version": "12"
"compiler_version": "12",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "gcc",
"compiler_version": "13"
"compiler_version": "13",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "gcc",
"compiler_version": "14"
"compiler_version": "14",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "gcc",
"compiler_version": "15"
"compiler_version": "15",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "clang",
"compiler_version": "16"
"compiler_version": "16",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "clang",
"compiler_version": "17"
"compiler_version": "17",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "clang",
"compiler_version": "18"
"compiler_version": "18",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "clang",
"compiler_version": "19"
"compiler_version": "19",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "bookworm",
"compiler_name": "clang",
"compiler_version": "20"
"compiler_version": "20",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9.4",
"distro_name": "debian",
"distro_version": "trixie",
"compiler_name": "gcc",
"compiler_version": "12"
"compiler_version": "14",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9.4",
"distro_name": "debian",
"distro_version": "trixie",
"compiler_name": "gcc",
"compiler_version": "13"
"compiler_version": "15",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9.4",
"compiler_name": "gcc",
"compiler_version": "14"
},
{
"distro_name": "rhel",
"distro_version": "9.6",
"compiler_name": "gcc",
"compiler_version": "13"
},
{
"distro_name": "rhel",
"distro_version": "9.6",
"compiler_name": "gcc",
"compiler_version": "14"
},
{
"distro_name": "rhel",
"distro_version": "9.4",
"distro_name": "debian",
"distro_version": "trixie",
"compiler_name": "clang",
"compiler_version": "any"
"compiler_version": "20",
"image_sha": "ab4d1f0"
},
{
"distro_name": "debian",
"distro_version": "trixie",
"compiler_name": "clang",
"compiler_version": "21",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9.6",
"distro_version": "8",
"compiler_name": "gcc",
"compiler_version": "14",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "8",
"compiler_name": "clang",
"compiler_version": "any"
"compiler_version": "any",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9",
"compiler_name": "gcc",
"compiler_version": "12",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9",
"compiler_name": "gcc",
"compiler_version": "13",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9",
"compiler_name": "gcc",
"compiler_version": "14",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "9",
"compiler_name": "clang",
"compiler_version": "any",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "10",
"compiler_name": "gcc",
"compiler_version": "14",
"image_sha": "ab4d1f0"
},
{
"distro_name": "rhel",
"distro_version": "10",
"compiler_name": "clang",
"compiler_version": "any",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "jammy",
"compiler_name": "gcc",
"compiler_version": "12"
"compiler_version": "12",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "noble",
"compiler_name": "gcc",
"compiler_version": "13"
"compiler_version": "13",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "noble",
"compiler_name": "gcc",
"compiler_version": "14"
"compiler_version": "14",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "noble",
"compiler_name": "clang",
"compiler_version": "16"
"compiler_version": "16",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "noble",
"compiler_name": "clang",
"compiler_version": "17"
"compiler_version": "17",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "noble",
"compiler_name": "clang",
"compiler_version": "18"
"compiler_version": "18",
"image_sha": "ab4d1f0"
},
{
"distro_name": "ubuntu",
"distro_version": "noble",
"compiler_name": "clang",
"compiler_version": "19"
"compiler_version": "19",
"image_sha": "ab4d1f0"
}
],
"build_type": ["Debug", "Release"],
"cmake_args": ["-Dunity=OFF", "-Dunity=ON"]
"cmake_args": [""]
}

View File

@@ -10,12 +10,10 @@
"distro_name": "macos",
"distro_version": "",
"compiler_name": "",
"compiler_version": ""
"compiler_version": "",
"image_sha": ""
}
],
"build_type": ["Debug", "Release"],
"cmake_args": [
"-Dunity=OFF -DCMAKE_POLICY_VERSION_MINIMUM=3.5",
"-Dunity=ON -DCMAKE_POLICY_VERSION_MINIMUM=3.5"
]
"cmake_args": ["-DCMAKE_POLICY_VERSION_MINIMUM=3.5"]
}

View File

@@ -10,9 +10,10 @@
"distro_name": "windows",
"distro_version": "",
"compiler_name": "",
"compiler_version": ""
"compiler_version": "",
"image_sha": ""
}
],
"build_type": ["Debug", "Release"],
"cmake_args": ["-Dunity=OFF", "-Dunity=ON"]
"cmake_args": [""]
}

View File

@@ -1,7 +1,8 @@
# This workflow runs all workflows to check, build and test the project on
# various Linux flavors, as well as on MacOS and Windows, on every push to a
# user branch. However, it will not run if the pull request is a draft unless it
# has the 'DraftRunCI' label.
# has the 'DraftRunCI' label. For commits to PRs that target a release branch,
# it also uploads the libxrpl recipe to the Conan remote.
name: PR
on:
@@ -50,13 +51,15 @@ jobs:
files: |
# These paths are unique to `on-pr.yml`.
.github/scripts/levelization/**
.github/scripts/rename/**
.github/workflows/reusable-check-levelization.yml
.github/workflows/reusable-notify-clio.yml
.github/workflows/reusable-check-rename.yml
.github/workflows/on-pr.yml
# Keep the paths below in sync with those in `on-trigger.yml`.
.github/actions/build-deps/**
.github/actions/build-test/**
.github/actions/generate-version/**
.github/actions/setup-conan/**
.github/scripts/strategy-matrix/**
.github/workflows/reusable-build.yml
@@ -64,6 +67,7 @@ jobs:
.github/workflows/reusable-build-test.yml
.github/workflows/reusable-strategy-matrix.yml
.github/workflows/reusable-test.yml
.github/workflows/reusable-upload-recipe.yml
.codecov.yml
cmake/**
conan/**
@@ -98,34 +102,63 @@ jobs:
if: ${{ needs.should-run.outputs.go == 'true' }}
uses: ./.github/workflows/reusable-check-levelization.yml
check-rename:
needs: should-run
if: ${{ needs.should-run.outputs.go == 'true' }}
uses: ./.github/workflows/reusable-check-rename.yml
build-test:
needs: should-run
if: ${{ needs.should-run.outputs.go == 'true' }}
uses: ./.github/workflows/reusable-build-test.yml
strategy:
fail-fast: false
matrix:
os: [linux, macos, windows]
with:
# Enable ccache only for events targeting the XRPLF repository, since
# other accounts will not have access to our remote cache storage.
ccache_enabled: ${{ github.repository_owner == 'XRPLF' }}
os: ${{ matrix.os }}
secrets:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
notify-clio:
upload-recipe:
needs:
- should-run
- build-test
if: ${{ needs.should-run.outputs.go == 'true' && contains(fromJSON('["release", "master"]'), github.ref_name) }}
uses: ./.github/workflows/reusable-notify-clio.yml
# Only run when committing to a PR that targets a release branch in the
# XRPLF repository.
if: ${{ github.repository_owner == 'XRPLF' && needs.should-run.outputs.go == 'true' && startsWith(github.ref, 'refs/heads/release') }}
uses: ./.github/workflows/reusable-upload-recipe.yml
secrets:
clio_notify_token: ${{ secrets.CLIO_NOTIFY_TOKEN }}
conan_remote_username: ${{ secrets.CONAN_REMOTE_USERNAME }}
conan_remote_password: ${{ secrets.CONAN_REMOTE_PASSWORD }}
remote_username: ${{ secrets.CONAN_REMOTE_USERNAME }}
remote_password: ${{ secrets.CONAN_REMOTE_PASSWORD }}
notify-clio:
needs: upload-recipe
runs-on: ubuntu-latest
steps:
# Notify the Clio repository about the newly proposed release version, so
# it can be checked for compatibility before the release is actually made.
- name: Notify Clio
env:
GH_TOKEN: ${{ secrets.CLIO_NOTIFY_TOKEN }}
PR_URL: ${{ github.event.pull_request.html_url }}
run: |
gh api --method POST -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" \
/repos/xrplf/clio/dispatches -f "event_type=check_libxrpl" \
-F "client_payload[ref]=${{ needs.upload-recipe.outputs.recipe_ref }}" \
-F "client_payload[pr_url]=${PR_URL}"
passed:
if: failure() || cancelled()
needs:
- build-test
- check-levelization
- check-rename
- build-test
- upload-recipe
- notify-clio
runs-on: ubuntu-latest
steps:
- name: Fail

25
.github/workflows/on-tag.yml vendored Normal file
View File

@@ -0,0 +1,25 @@
# This workflow uploads the libxrpl recipe to the Conan remote when a versioned
# tag is pushed.
name: Tag
on:
push:
tags:
- "v*"
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
defaults:
run:
shell: bash
jobs:
upload-recipe:
# Only run when a tag is pushed to the XRPLF repository.
if: ${{ github.repository_owner == 'XRPLF' }}
uses: ./.github/workflows/reusable-upload-recipe.yml
secrets:
remote_username: ${{ secrets.CONAN_REMOTE_USERNAME }}
remote_password: ${{ secrets.CONAN_REMOTE_PASSWORD }}

View File

@@ -1,26 +1,22 @@
# This workflow runs all workflows to build the dependencies required for the
# project on various Linux flavors, as well as on MacOS and Windows, on a
# scheduled basis, on merge into the 'develop', 'release', or 'master' branches,
# or manually. The missing commits check is only run when the code is merged
# into the 'develop' or 'release' branches, and the documentation is built when
# the code is merged into the 'develop' branch.
# This workflow runs all workflows to build and test the code on various Linux
# flavors, as well as on MacOS and Windows, on a scheduled basis, on merge into
# the 'develop' or 'release*' branches, or when requested manually. Upon pushes
# to the develop branch it also uploads the libxrpl recipe to the Conan remote.
name: Trigger
on:
push:
branches:
- develop
- release
- master
- "develop"
- "release*"
paths:
# These paths are unique to `on-trigger.yml`.
- ".github/workflows/reusable-check-missing-commits.yml"
- ".github/workflows/on-trigger.yml"
- ".github/workflows/publish-docs.yml"
# Keep the paths below in sync with those in `on-pr.yml`.
- ".github/actions/build-deps/**"
- ".github/actions/build-test/**"
- ".github/actions/generate-version/**"
- ".github/actions/setup-conan/**"
- ".github/scripts/strategy-matrix/**"
- ".github/workflows/reusable-build.yml"
@@ -28,6 +24,7 @@ on:
- ".github/workflows/reusable-build-test.yml"
- ".github/workflows/reusable-strategy-matrix.yml"
- ".github/workflows/reusable-test.yml"
- ".github/workflows/reusable-upload-recipe.yml"
- ".codecov.yml"
- "cmake/**"
- "conan/**"
@@ -50,7 +47,12 @@ on:
workflow_dispatch:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
# When a PR is merged into the develop branch it will be assigned a unique
# group identifier, so execution will continue even if another PR is merged
# while it is still running. In all other cases the group identifier is shared
# per branch, so that any in-progress runs are cancelled when a new commit is
# pushed.
group: ${{ github.workflow }}-${{ github.event_name == 'push' && github.ref == 'refs/heads/develop' && github.sha || github.ref }}
cancel-in-progress: true
defaults:
@@ -58,17 +60,29 @@ defaults:
shell: bash
jobs:
check-missing-commits:
if: ${{ github.event_name == 'push' && github.ref_type == 'branch' && contains(fromJSON('["develop", "release"]'), github.ref_name) }}
uses: ./.github/workflows/reusable-check-missing-commits.yml
build-test:
uses: ./.github/workflows/reusable-build-test.yml
strategy:
fail-fast: ${{ github.event_name == 'merge_group' }}
matrix:
os: [linux, macos, windows]
with:
# Enable ccache only for events targeting the XRPLF repository, since
# other accounts will not have access to our remote cache storage.
# However, we do not enable ccache for events targeting a release branch,
# to protect against the rare case that the output produced by ccache is
# not identical to a regular compilation.
ccache_enabled: ${{ github.repository_owner == 'XRPLF' && !startsWith(github.ref, 'refs/heads/release') }}
os: ${{ matrix.os }}
strategy_matrix: ${{ github.event_name == 'schedule' && 'all' || 'minimal' }}
secrets:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
upload-recipe:
needs: build-test
# Only run when pushing to the develop branch in the XRPLF repository.
if: ${{ github.repository_owner == 'XRPLF' && github.event_name == 'push' && github.ref == 'refs/heads/develop' }}
uses: ./.github/workflows/reusable-upload-recipe.yml
secrets:
remote_username: ${{ secrets.CONAN_REMOTE_USERNAME }}
remote_password: ${{ secrets.CONAN_REMOTE_PASSWORD }}

View File

@@ -3,13 +3,15 @@ name: Run pre-commit hooks
on:
pull_request:
push:
branches: [develop, release, master]
branches:
- "develop"
- "release*"
workflow_dispatch:
jobs:
# Call the workflow in the XRPLF/actions repo that runs the pre-commit hooks.
run-hooks:
uses: XRPLF/actions/.github/workflows/pre-commit.yml@af1b0f0d764cda2e5435f5ac97b240d4bd4d95d3
uses: XRPLF/actions/.github/workflows/pre-commit.yml@320be44621ca2a080f05aeb15817c44b84518108
with:
runs_on: ubuntu-latest
container: '{ "image": "ghcr.io/xrplf/ci/tools-rippled-pre-commit:sha-d1496b8" }'
container: '{ "image": "ghcr.io/xrplf/ci/tools-rippled-pre-commit:sha-ab4d1f0" }'

View File

@@ -22,17 +22,25 @@ defaults:
shell: bash
env:
BUILD_DIR: .build
BUILD_DIR: build
NPROC_SUBTRACT: 2
jobs:
publish:
runs-on: ubuntu-latest
container: ghcr.io/xrplf/ci/tools-rippled-documentation:sha-d1496b8
container: ghcr.io/xrplf/ci/tools-rippled-documentation:sha-a8c7be1
permissions:
contents: write
steps:
- name: Checkout repository
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
- name: Get number of processors
uses: XRPLF/actions/get-nproc@cf0433aa74563aead044a1e395610c96d65a37cf
id: nproc
with:
subtract: ${{ env.NPROC_SUBTRACT }}
- name: Check configuration
run: |
echo 'Checking path.'
@@ -46,12 +54,16 @@ jobs:
echo 'Checking Doxygen version.'
doxygen --version
- name: Build documentation
env:
BUILD_NPROC: ${{ steps.nproc.outputs.nproc }}
run: |
mkdir -p ${{ env.BUILD_DIR }}
cd ${{ env.BUILD_DIR }}
mkdir -p "${BUILD_DIR}"
cd "${BUILD_DIR}"
cmake -Donly_docs=ON ..
cmake --build . --target docs --parallel $(nproc)
cmake --build . --target docs --parallel ${BUILD_NPROC}
- name: Publish documentation
if: ${{ github.ref_type == 'branch' && github.ref_name == github.event.repository.default_branch }}
uses: peaceiris/actions-gh-pages@4f9cc6602d3f66b9c108549d475ec49e8ef4d45e # v4.0.0

View File

@@ -3,32 +3,38 @@ name: Build and test configuration
on:
workflow_call:
inputs:
build_dir:
description: "The directory where to build."
required: true
type: string
build_only:
description: 'Whether to only build or to build and test the code ("true", "false").'
required: true
type: boolean
build_type:
description: 'The build type to use ("Debug", "Release").'
type: string
required: true
type: string
ccache_enabled:
description: "Whether to enable ccache."
required: false
type: boolean
default: false
cmake_args:
description: "Additional arguments to pass to CMake."
required: false
type: string
default: ""
cmake_target:
description: "The CMake target to build."
type: string
required: true
type: string
runs_on:
description: Runner to run the job on as a JSON string
required: true
type: string
image:
description: "The image to run in (leave empty to run natively)"
required: true
@@ -39,31 +45,221 @@ on:
required: true
type: string
nproc_subtract:
description: "The number of processors to subtract when calculating parallelism."
required: false
type: number
default: 2
sanitizers:
description: "The sanitizers to enable."
required: false
type: string
default: ""
secrets:
CODECOV_TOKEN:
description: "The Codecov token to use for uploading coverage reports."
required: true
jobs:
build:
uses: ./.github/workflows/reusable-build.yml
with:
build_dir: ${{ inputs.build_dir }}
build_type: ${{ inputs.build_type }}
cmake_args: ${{ inputs.cmake_args }}
cmake_target: ${{ inputs.cmake_target }}
runs_on: ${{ inputs.runs_on }}
image: ${{ inputs.image }}
config_name: ${{ inputs.config_name }}
secrets:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
defaults:
run:
shell: bash
test:
needs: build
uses: ./.github/workflows/reusable-test.yml
with:
run_tests: ${{ !inputs.build_only }}
verify_voidstar: ${{ contains(inputs.cmake_args, '-Dvoidstar=ON') }}
runs_on: ${{ inputs.runs_on }}
image: ${{ inputs.image }}
config_name: ${{ inputs.config_name }}
env:
# Conan installs the generators in the build/generators directory, see the
# layout() method in conanfile.py. We then run CMake from the build directory.
BUILD_DIR: build
jobs:
build-and-test:
name: ${{ inputs.config_name }}
runs-on: ${{ fromJSON(inputs.runs_on) }}
container: ${{ inputs.image != '' && inputs.image || null }}
timeout-minutes: 60
env:
# Use a namespace to keep the objects separate for each configuration.
CCACHE_NAMESPACE: ${{ inputs.config_name }}
# Ccache supports both Redis and HTTP endpoints.
# * For Redis, use the following format: redis://ip:port, see
# https://github.com/ccache/ccache/wiki/Redis-storage. Note that TLS is
# not directly supported by ccache, and requires use of a proxy.
# * For HTTP use the following format: http://ip:port/cache when using
# nginx as backend or http://ip:port|layout=bazel when using Bazel
# Remote Cache, see https://github.com/ccache/ccache/wiki/HTTP-storage.
# Note that HTTPS is not directly supported by ccache.
CCACHE_REMOTE_ONLY: true
CCACHE_REMOTE_STORAGE: http://cache.dev.ripplex.io:8080|layout=bazel
# Ignore the creation and modification timestamps on files, since the
# header files are copied into separate directories by CMake, which will
# otherwise result in cache misses.
CCACHE_SLOPPINESS: include_file_ctime,include_file_mtime
# Determine if coverage and voidstar should be enabled.
COVERAGE_ENABLED: ${{ contains(inputs.cmake_args, '-Dcoverage=ON') }}
VOIDSTAR_ENABLED: ${{ contains(inputs.cmake_args, '-Dvoidstar=ON') }}
SANITIZERS_ENABLED: ${{ inputs.sanitizers != '' }}
steps:
- name: Cleanup workspace (macOS and Windows)
if: ${{ runner.os == 'macOS' || runner.os == 'Windows' }}
uses: XRPLF/actions/cleanup-workspace@cf0433aa74563aead044a1e395610c96d65a37cf
- name: Checkout repository
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
- name: Prepare runner
uses: XRPLF/actions/prepare-runner@2cbf481018d930656e9276fcc20dc0e3a0be5b6d
with:
enable_ccache: ${{ inputs.ccache_enabled }}
- name: Set ccache log file
if: ${{ inputs.ccache_enabled && runner.debug == '1' }}
run: echo "CCACHE_LOGFILE=${{ runner.temp }}/ccache.log" >> "${GITHUB_ENV}"
- name: Print build environment
uses: ./.github/actions/print-env
- name: Get number of processors
uses: XRPLF/actions/get-nproc@cf0433aa74563aead044a1e395610c96d65a37cf
id: nproc
with:
subtract: ${{ inputs.nproc_subtract }}
- name: Setup Conan
env:
SANITIZERS: ${{ inputs.sanitizers }}
uses: ./.github/actions/setup-conan
- name: Build dependencies
uses: ./.github/actions/build-deps
with:
build_nproc: ${{ steps.nproc.outputs.nproc }}
build_type: ${{ inputs.build_type }}
# Set the verbosity to "quiet" for Windows to avoid an excessive
# amount of logs. For other OSes, the "verbose" logs are more useful.
log_verbosity: ${{ runner.os == 'Windows' && 'quiet' || 'verbose' }}
sanitizers: ${{ inputs.sanitizers }}
- name: Configure CMake
working-directory: ${{ env.BUILD_DIR }}
env:
BUILD_TYPE: ${{ inputs.build_type }}
SANITIZERS: ${{ inputs.sanitizers }}
CMAKE_ARGS: ${{ inputs.cmake_args }}
run: |
cmake \
-G '${{ runner.os == 'Windows' && 'Visual Studio 17 2022' || 'Ninja' }}' \
-DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake \
-DCMAKE_BUILD_TYPE="${BUILD_TYPE}" \
${CMAKE_ARGS} \
..
- name: Build the binary
working-directory: ${{ env.BUILD_DIR }}
env:
BUILD_NPROC: ${{ steps.nproc.outputs.nproc }}
BUILD_TYPE: ${{ inputs.build_type }}
CMAKE_TARGET: ${{ inputs.cmake_target }}
run: |
cmake \
--build . \
--config "${BUILD_TYPE}" \
--parallel "${BUILD_NPROC}" \
--target "${CMAKE_TARGET}"
- name: Show ccache statistics
if: ${{ inputs.ccache_enabled }}
run: |
ccache --show-stats -vv
if [ '${{ runner.debug }}' = '1' ]; then
cat "${CCACHE_LOGFILE}"
curl ${CCACHE_REMOTE_STORAGE%|*}/status || true
fi
- name: Upload the binary (Linux)
if: ${{ github.repository_owner == 'XRPLF' && runner.os == 'Linux' }}
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: xrpld-${{ inputs.config_name }}
path: ${{ env.BUILD_DIR }}/xrpld
retention-days: 3
if-no-files-found: error
- name: Check linking (Linux)
if: ${{ runner.os == 'Linux' && env.SANITIZERS_ENABLED == 'false' }}
working-directory: ${{ env.BUILD_DIR }}
run: |
ldd ./xrpld
if [ "$(ldd ./xrpld | grep -E '(libstdc\+\+|libgcc)' | wc -l)" -eq 0 ]; then
echo 'The binary is statically linked.'
else
echo 'The binary is dynamically linked.'
exit 1
fi
- name: Verify presence of instrumentation (Linux)
if: ${{ runner.os == 'Linux' && env.VOIDSTAR_ENABLED == 'true' }}
working-directory: ${{ env.BUILD_DIR }}
run: |
./xrpld --version | grep libvoidstar
- name: Set sanitizer options
if: ${{ !inputs.build_only && env.SANITIZERS_ENABLED == 'true' }}
run: |
echo "ASAN_OPTIONS=print_stacktrace=1:detect_container_overflow=0:suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/asan.supp" >> ${GITHUB_ENV}
echo "TSAN_OPTIONS=second_deadlock_stack=1:halt_on_error=0:suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/tsan.supp" >> ${GITHUB_ENV}
echo "UBSAN_OPTIONS=suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/ubsan.supp" >> ${GITHUB_ENV}
echo "LSAN_OPTIONS=suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/lsan.supp" >> ${GITHUB_ENV}
- name: Run the separate tests
if: ${{ !inputs.build_only }}
working-directory: ${{ env.BUILD_DIR }}
# Windows locks some of the build files while running tests, and parallel jobs can collide
env:
BUILD_TYPE: ${{ inputs.build_type }}
PARALLELISM: ${{ runner.os == 'Windows' && '1' || steps.nproc.outputs.nproc }}
run: |
ctest \
--output-on-failure \
-C "${BUILD_TYPE}" \
-j "${PARALLELISM}"
- name: Run the embedded tests
if: ${{ !inputs.build_only }}
working-directory: ${{ runner.os == 'Windows' && format('{0}/{1}', env.BUILD_DIR, inputs.build_type) || env.BUILD_DIR }}
env:
BUILD_NPROC: ${{ steps.nproc.outputs.nproc }}
run: |
./xrpld --unittest --unittest-jobs "${BUILD_NPROC}"
- name: Debug failure (Linux)
if: ${{ failure() && runner.os == 'Linux' && !inputs.build_only }}
run: |
echo "IPv4 local port range:"
cat /proc/sys/net/ipv4/ip_local_port_range
echo "Netstat:"
netstat -an
- name: Prepare coverage report
if: ${{ !inputs.build_only && env.COVERAGE_ENABLED == 'true' }}
working-directory: ${{ env.BUILD_DIR }}
env:
BUILD_NPROC: ${{ steps.nproc.outputs.nproc }}
BUILD_TYPE: ${{ inputs.build_type }}
run: |
cmake \
--build . \
--config "${BUILD_TYPE}" \
--parallel "${BUILD_NPROC}" \
--target coverage
- name: Upload coverage report
if: ${{ github.repository_owner == 'XRPLF' && !inputs.build_only && env.COVERAGE_ENABLED == 'true' }}
uses: codecov/codecov-action@18283e04ce6e62d37312384ff67231eb8fd56d24 # v5.4.3
with:
disable_search: true
disable_telem: true
fail_ci_if_error: true
files: ${{ env.BUILD_DIR }}/coverage.xml
plugins: noop
token: ${{ secrets.CODECOV_TOKEN }}
verbose: true

View File

@@ -8,21 +8,24 @@ name: Build and test
on:
workflow_call:
inputs:
build_dir:
description: "The directory where to build."
ccache_enabled:
description: "Whether to enable ccache."
required: false
type: string
default: ".build"
type: boolean
default: false
os:
description: 'The operating system to use for the build ("linux", "macos", "windows").'
required: true
type: string
strategy_matrix:
# TODO: Support additional strategies, e.g. "ubuntu" for generating all Ubuntu configurations.
description: 'The strategy matrix to use for generating the configurations ("minimal", "all").'
required: false
type: string
default: "minimal"
secrets:
CODECOV_TOKEN:
description: "The Codecov token to use for uploading coverage reports."
@@ -42,17 +45,18 @@ jobs:
- generate-matrix
uses: ./.github/workflows/reusable-build-test-config.yml
strategy:
fail-fast: false
fail-fast: ${{ github.event_name == 'merge_group' }}
matrix: ${{ fromJson(needs.generate-matrix.outputs.matrix) }}
max-parallel: 10
with:
build_dir: ${{ inputs.build_dir }}
build_only: ${{ matrix.build_only }}
build_type: ${{ matrix.build_type }}
ccache_enabled: ${{ inputs.ccache_enabled }}
cmake_args: ${{ matrix.cmake_args }}
cmake_target: ${{ matrix.cmake_target }}
runs_on: ${{ toJSON(matrix.architecture.runner) }}
image: ${{ contains(matrix.architecture.platform, 'linux') && format('ghcr.io/xrplf/ci/{0}-{1}:{2}-{3}-sha-5dd7158', matrix.os.distro_name, matrix.os.distro_version, matrix.os.compiler_name, matrix.os.compiler_version) || '' }}
image: ${{ contains(matrix.architecture.platform, 'linux') && format('ghcr.io/xrplf/ci/{0}-{1}:{2}-{3}-sha-{4}', matrix.os.distro_name, matrix.os.distro_version, matrix.os.compiler_name, matrix.os.compiler_version, matrix.os.image_sha) || '' }}
config_name: ${{ matrix.config_name }}
sanitizers: ${{ matrix.sanitizers }}
secrets:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}

View File

@@ -1,121 +0,0 @@
name: Build rippled
on:
workflow_call:
inputs:
build_dir:
description: "The directory where to build."
required: true
type: string
build_type:
description: 'The build type to use ("Debug", "Release").'
required: true
type: string
cmake_args:
description: "Additional arguments to pass to CMake."
required: true
type: string
cmake_target:
description: "The CMake target to build."
required: true
type: string
runs_on:
description: Runner to run the job on as a JSON string
required: true
type: string
image:
description: "The image to run in (leave empty to run natively)"
required: true
type: string
config_name:
description: "The name of the configuration."
required: true
type: string
secrets:
CODECOV_TOKEN:
description: "The Codecov token to use for uploading coverage reports."
required: true
defaults:
run:
shell: bash
jobs:
build:
name: Build ${{ inputs.config_name }}
runs-on: ${{ fromJSON(inputs.runs_on) }}
container: ${{ inputs.image != '' && inputs.image || null }}
steps:
- name: Cleanup workspace
if: ${{ runner.os == 'macOS' }}
uses: XRPLF/actions/.github/actions/cleanup-workspace@3f044c7478548e3c32ff68980eeb36ece02b364e
- name: Checkout repository
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
- name: Prepare runner
uses: XRPLF/actions/.github/actions/prepare-runner@638e0dc11ea230f91bd26622fb542116bb5254d5
with:
disable_ccache: false
- name: Print build environment
uses: ./.github/actions/print-env
- name: Setup Conan
uses: ./.github/actions/setup-conan
- name: Build dependencies
uses: ./.github/actions/build-deps
with:
build_dir: ${{ inputs.build_dir }}
build_type: ${{ inputs.build_type }}
- name: Configure CMake
shell: bash
working-directory: ${{ inputs.build_dir }}
env:
BUILD_TYPE: ${{ inputs.build_type }}
CMAKE_ARGS: ${{ inputs.cmake_args }}
run: |
cmake \
-G '${{ runner.os == 'Windows' && 'Visual Studio 17 2022' || 'Ninja' }}' \
-DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake \
-DCMAKE_BUILD_TYPE=${{ env.BUILD_TYPE }} \
${{ env.CMAKE_ARGS }} \
..
- name: Build the binary
shell: bash
working-directory: ${{ inputs.build_dir }}
env:
BUILD_TYPE: ${{ inputs.build_type }}
CMAKE_TARGET: ${{ inputs.cmake_target }}
run: |
cmake \
--build . \
--config ${{ env.BUILD_TYPE }} \
--parallel $(nproc) \
--target ${{ env.CMAKE_TARGET }}
- name: Upload rippled artifact
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: rippled-${{ inputs.config_name }}
path: ${{ inputs.build_dir }}/${{ runner.os == 'Windows' && inputs.build_type || '' }}/rippled${{ runner.os == 'Windows' && '.exe' || '' }}
retention-days: 3
if-no-files-found: error
- name: Upload coverage report
if: ${{ inputs.cmake_target == 'coverage' }}
uses: codecov/codecov-action@18283e04ce6e62d37312384ff67231eb8fd56d24 # v5.4.3
with:
disable_search: true
disable_telem: true
fail_ci_if_error: true
files: ${{ inputs.build_dir }}/coverage.xml
plugins: noop
token: ${{ secrets.CODECOV_TOKEN }}
verbose: true

Some files were not shown because too many files have changed in this diff Show More