mirror of
https://github.com/XRPLF/rippled.git
synced 2026-03-23 05:02:30 +00:00
Compare commits
3 Commits
dependabot
...
dangell7/a
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
9d1c83b1cc | ||
|
|
38850e1180 | ||
|
|
b418b416b0 |
@@ -37,7 +37,7 @@ BinPackParameters: false
|
||||
BreakBeforeBinaryOperators: false
|
||||
BreakBeforeTernaryOperators: true
|
||||
BreakConstructorInitializersBeforeComma: true
|
||||
ColumnLimit: 100
|
||||
ColumnLimit: 120
|
||||
CommentPragmas: "^ IWYU pragma:"
|
||||
ConstructorInitializerAllOnOneLineOrOnePerLine: true
|
||||
ConstructorInitializerIndentWidth: 4
|
||||
|
||||
199
.clang-tidy
199
.clang-tidy
@@ -1,199 +0,0 @@
|
||||
---
|
||||
Checks: "-*,
|
||||
bugprone-argument-comment,
|
||||
bugprone-assert-side-effect,
|
||||
bugprone-bad-signal-to-kill-thread,
|
||||
bugprone-bool-pointer-implicit-conversion,
|
||||
bugprone-casting-through-void,
|
||||
bugprone-chained-comparison,
|
||||
bugprone-compare-pointer-to-member-virtual-function,
|
||||
bugprone-copy-constructor-init,
|
||||
bugprone-crtp-constructor-accessibility,
|
||||
bugprone-dangling-handle,
|
||||
bugprone-dynamic-static-initializers,
|
||||
bugprone-empty-catch,
|
||||
bugprone-fold-init-type,
|
||||
bugprone-forward-declaration-namespace,
|
||||
bugprone-inaccurate-erase,
|
||||
bugprone-inc-dec-in-conditions,
|
||||
bugprone-incorrect-enable-if,
|
||||
bugprone-incorrect-roundings,
|
||||
bugprone-infinite-loop,
|
||||
bugprone-integer-division,
|
||||
bugprone-lambda-function-name,
|
||||
bugprone-macro-parentheses,
|
||||
bugprone-macro-repeated-side-effects,
|
||||
bugprone-misplaced-operator-in-strlen-in-alloc,
|
||||
bugprone-misplaced-pointer-arithmetic-in-alloc,
|
||||
bugprone-misplaced-widening-cast,
|
||||
bugprone-move-forwarding-reference,
|
||||
bugprone-multi-level-implicit-pointer-conversion,
|
||||
bugprone-multiple-new-in-one-expression,
|
||||
bugprone-multiple-statement-macro,
|
||||
bugprone-no-escape,
|
||||
bugprone-non-zero-enum-to-bool-conversion,
|
||||
bugprone-optional-value-conversion,
|
||||
bugprone-parent-virtual-call,
|
||||
bugprone-pointer-arithmetic-on-polymorphic-object,
|
||||
bugprone-posix-return,
|
||||
bugprone-redundant-branch-condition,
|
||||
bugprone-reserved-identifier,
|
||||
bugprone-return-const-ref-from-parameter,
|
||||
bugprone-shared-ptr-array-mismatch,
|
||||
bugprone-signal-handler,
|
||||
bugprone-signed-char-misuse,
|
||||
bugprone-sizeof-container,
|
||||
bugprone-sizeof-expression,
|
||||
bugprone-spuriously-wake-up-functions,
|
||||
bugprone-standalone-empty,
|
||||
bugprone-string-constructor,
|
||||
bugprone-string-integer-assignment,
|
||||
bugprone-string-literal-with-embedded-nul,
|
||||
bugprone-stringview-nullptr,
|
||||
bugprone-suspicious-enum-usage,
|
||||
bugprone-suspicious-include,
|
||||
bugprone-suspicious-memory-comparison,
|
||||
bugprone-suspicious-memset-usage,
|
||||
bugprone-suspicious-missing-comma,
|
||||
bugprone-suspicious-realloc-usage,
|
||||
bugprone-suspicious-semicolon,
|
||||
bugprone-suspicious-string-compare,
|
||||
bugprone-suspicious-stringview-data-usage,
|
||||
bugprone-swapped-arguments,
|
||||
bugprone-switch-missing-default-case,
|
||||
bugprone-terminating-continue,
|
||||
bugprone-throw-keyword-missing,
|
||||
bugprone-too-small-loop-variable,
|
||||
# bugprone-unchecked-optional-access, # see https://github.com/XRPLF/rippled/pull/6502
|
||||
bugprone-undefined-memory-manipulation,
|
||||
bugprone-undelegated-constructor,
|
||||
bugprone-unhandled-exception-at-new,
|
||||
bugprone-unhandled-self-assignment,
|
||||
bugprone-unique-ptr-array-mismatch,
|
||||
bugprone-unsafe-functions,
|
||||
bugprone-use-after-move,
|
||||
bugprone-unused-raii,
|
||||
bugprone-unused-return-value,
|
||||
bugprone-unused-local-non-trivial-variable,
|
||||
bugprone-virtual-near-miss,
|
||||
cppcoreguidelines-init-variables,
|
||||
cppcoreguidelines-misleading-capture-default-by-value,
|
||||
cppcoreguidelines-no-suspend-with-lock,
|
||||
cppcoreguidelines-pro-type-member-init,
|
||||
cppcoreguidelines-pro-type-static-cast-downcast,
|
||||
cppcoreguidelines-rvalue-reference-param-not-moved,
|
||||
cppcoreguidelines-use-default-member-init,
|
||||
cppcoreguidelines-virtual-class-destructor,
|
||||
hicpp-ignored-remove-result,
|
||||
misc-definitions-in-headers,
|
||||
misc-header-include-cycle,
|
||||
misc-misplaced-const,
|
||||
misc-static-assert,
|
||||
misc-throw-by-value-catch-by-reference,
|
||||
misc-unused-alias-decls,
|
||||
misc-unused-using-decls,
|
||||
modernize-deprecated-headers,
|
||||
modernize-make-shared,
|
||||
modernize-make-unique,
|
||||
performance-implicit-conversion-in-loop,
|
||||
performance-move-constructor-init,
|
||||
performance-trivially-destructible,
|
||||
readability-avoid-nested-conditional-operator,
|
||||
readability-avoid-return-with-void-value,
|
||||
readability-braces-around-statements,
|
||||
readability-const-return-type,
|
||||
readability-container-contains,
|
||||
readability-container-size-empty,
|
||||
readability-duplicate-include,
|
||||
readability-else-after-return,
|
||||
readability-enum-initial-value,
|
||||
readability-make-member-function-const,
|
||||
readability-misleading-indentation,
|
||||
readability-non-const-parameter,
|
||||
readability-redundant-casting,
|
||||
readability-redundant-declaration,
|
||||
readability-redundant-inline-specifier,
|
||||
readability-redundant-member-init,
|
||||
readability-redundant-string-init,
|
||||
readability-reference-to-constructed-temporary,
|
||||
readability-static-definition-in-anonymous-namespace,
|
||||
readability-use-std-min-max
|
||||
"
|
||||
# ---
|
||||
# checks that have some issues that need to be resolved:
|
||||
#
|
||||
# llvm-namespace-comment,
|
||||
# misc-const-correctness,
|
||||
# misc-include-cleaner,
|
||||
# misc-redundant-expression,
|
||||
#
|
||||
# readability-convert-member-functions-to-static,
|
||||
# readability-implicit-bool-conversion,
|
||||
# readability-inconsistent-declaration-parameter-name,
|
||||
# readability-identifier-naming,
|
||||
# readability-math-missing-parentheses,
|
||||
# readability-simplify-boolean-expr,
|
||||
# readability-suspicious-call-argument,
|
||||
# readability-static-accessed-through-instance,
|
||||
#
|
||||
# modernize-concat-nested-namespaces,
|
||||
# modernize-pass-by-value,
|
||||
# modernize-type-traits,
|
||||
# modernize-use-designated-initializers,
|
||||
# modernize-use-emplace,
|
||||
# modernize-use-equals-default,
|
||||
# modernize-use-equals-delete,
|
||||
# modernize-use-override,
|
||||
# modernize-use-ranges,
|
||||
# modernize-use-starts-ends-with,
|
||||
# modernize-use-std-numbers,
|
||||
# modernize-use-using,
|
||||
#
|
||||
# performance-faster-string-find,
|
||||
# performance-for-range-copy,
|
||||
# performance-inefficient-vector-operation,
|
||||
# performance-move-const-arg,
|
||||
# performance-no-automatic-move,
|
||||
# ---
|
||||
#
|
||||
CheckOptions:
|
||||
readability-braces-around-statements.ShortStatementLines: 2
|
||||
# readability-identifier-naming.MacroDefinitionCase: UPPER_CASE
|
||||
# readability-identifier-naming.ClassCase: CamelCase
|
||||
# readability-identifier-naming.StructCase: CamelCase
|
||||
# readability-identifier-naming.UnionCase: CamelCase
|
||||
# readability-identifier-naming.EnumCase: CamelCase
|
||||
# readability-identifier-naming.EnumConstantCase: CamelCase
|
||||
# readability-identifier-naming.ScopedEnumConstantCase: CamelCase
|
||||
# readability-identifier-naming.GlobalConstantCase: UPPER_CASE
|
||||
# readability-identifier-naming.GlobalConstantPrefix: "k"
|
||||
# readability-identifier-naming.GlobalVariableCase: CamelCase
|
||||
# readability-identifier-naming.GlobalVariablePrefix: "g"
|
||||
# readability-identifier-naming.ConstexprFunctionCase: camelBack
|
||||
# readability-identifier-naming.ConstexprMethodCase: camelBack
|
||||
# readability-identifier-naming.ClassMethodCase: camelBack
|
||||
# readability-identifier-naming.ClassMemberCase: camelBack
|
||||
# readability-identifier-naming.ClassConstantCase: UPPER_CASE
|
||||
# readability-identifier-naming.ClassConstantPrefix: "k"
|
||||
# readability-identifier-naming.StaticConstantCase: UPPER_CASE
|
||||
# readability-identifier-naming.StaticConstantPrefix: "k"
|
||||
# readability-identifier-naming.StaticVariableCase: UPPER_CASE
|
||||
# readability-identifier-naming.StaticVariablePrefix: "k"
|
||||
# readability-identifier-naming.ConstexprVariableCase: UPPER_CASE
|
||||
# readability-identifier-naming.ConstexprVariablePrefix: "k"
|
||||
# readability-identifier-naming.LocalConstantCase: camelBack
|
||||
# readability-identifier-naming.LocalVariableCase: camelBack
|
||||
# readability-identifier-naming.TemplateParameterCase: CamelCase
|
||||
# readability-identifier-naming.ParameterCase: camelBack
|
||||
# readability-identifier-naming.FunctionCase: camelBack
|
||||
# readability-identifier-naming.MemberCase: camelBack
|
||||
# readability-identifier-naming.PrivateMemberSuffix: _
|
||||
# readability-identifier-naming.ProtectedMemberSuffix: _
|
||||
# readability-identifier-naming.PublicMemberSuffix: ""
|
||||
# readability-identifier-naming.FunctionIgnoredRegexp: ".*tag_invoke.*"
|
||||
bugprone-unsafe-functions.ReportMoreUnsafeFunctions: true
|
||||
bugprone-unused-return-value.CheckedReturnTypes: ::std::error_code;::std::error_condition;::std::errc
|
||||
# misc-include-cleaner.IgnoreHeaders: '.*/(detail|impl)/.*;.*(expected|unexpected).*;.*ranges_lower_bound\.h;time.h;stdlib.h;__chrono/.*;fmt/chrono.h;boost/uuid/uuid_hash.hpp'
|
||||
#
|
||||
# HeaderFilterRegex: '^.*/(src|tests)/.*\.(h|hpp)$'
|
||||
WarningsAsErrors: "*"
|
||||
54
.claude/CLAUDE.md
Normal file
54
.claude/CLAUDE.md
Normal 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
530
.claude/skills/amendment.md
Normal 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
99
.claude/skills/index.md
Normal 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`
|
||||
79
.claude/skills/libxrpl/basics.md
Normal file
79
.claude/skills/libxrpl/basics.md
Normal 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
|
||||
62
.claude/skills/libxrpl/beast.md
Normal file
62
.claude/skills/libxrpl/beast.md
Normal 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
|
||||
33
.claude/skills/libxrpl/beast/clock.md
Normal file
33
.claude/skills/libxrpl/beast/clock.md
Normal 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
|
||||
29
.claude/skills/libxrpl/beast/core.md
Normal file
29
.claude/skills/libxrpl/beast/core.md
Normal 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
|
||||
41
.claude/skills/libxrpl/beast/insight.md
Normal file
41
.claude/skills/libxrpl/beast/insight.md
Normal 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
|
||||
46
.claude/skills/libxrpl/beast/net.md
Normal file
46
.claude/skills/libxrpl/beast/net.md
Normal 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
|
||||
47
.claude/skills/libxrpl/beast/utility.md
Normal file
47
.claude/skills/libxrpl/beast/utility.md
Normal 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
|
||||
63
.claude/skills/libxrpl/conditions.md
Normal file
63
.claude/skills/libxrpl/conditions.md
Normal 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
|
||||
61
.claude/skills/libxrpl/core.md
Normal file
61
.claude/skills/libxrpl/core.md
Normal 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
|
||||
32
.claude/skills/libxrpl/core/detail.md
Normal file
32
.claude/skills/libxrpl/core/detail.md
Normal 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
|
||||
51
.claude/skills/libxrpl/crypto.md
Normal file
51
.claude/skills/libxrpl/crypto.md
Normal 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
|
||||
68
.claude/skills/libxrpl/json.md
Normal file
68
.claude/skills/libxrpl/json.md
Normal 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
|
||||
84
.claude/skills/libxrpl/ledger.md
Normal file
84
.claude/skills/libxrpl/ledger.md
Normal 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
|
||||
58
.claude/skills/libxrpl/net.md
Normal file
58
.claude/skills/libxrpl/net.md
Normal 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
|
||||
24
.claude/skills/libxrpl/net/images.md
Normal file
24
.claude/skills/libxrpl/net/images.md
Normal 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
|
||||
68
.claude/skills/libxrpl/nodestore.md
Normal file
68
.claude/skills/libxrpl/nodestore.md
Normal 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
|
||||
66
.claude/skills/libxrpl/nodestore/backend.md
Normal file
66
.claude/skills/libxrpl/nodestore/backend.md
Normal 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)
|
||||
35
.claude/skills/libxrpl/proto.md
Normal file
35
.claude/skills/libxrpl/proto.md
Normal 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
|
||||
123
.claude/skills/libxrpl/protocol.md
Normal file
123
.claude/skills/libxrpl/protocol.md
Normal 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
|
||||
60
.claude/skills/libxrpl/rdb.md
Normal file
60
.claude/skills/libxrpl/rdb.md
Normal 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
|
||||
64
.claude/skills/libxrpl/resource.md
Normal file
64
.claude/skills/libxrpl/resource.md
Normal 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
|
||||
68
.claude/skills/libxrpl/server.md
Normal file
68
.claude/skills/libxrpl/server.md
Normal 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
|
||||
83
.claude/skills/libxrpl/shamap.md
Normal file
83
.claude/skills/libxrpl/shamap.md
Normal 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
|
||||
137
.claude/skills/libxrpl/tx.md
Normal file
137
.claude/skills/libxrpl/tx.md
Normal 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
|
||||
72
.claude/skills/libxrpl/tx/paths.md
Normal file
72
.claude/skills/libxrpl/tx/paths.md
Normal 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
|
||||
164
.claude/skills/libxrpl/tx/transactors.md
Normal file
164
.claude/skills/libxrpl/tx/transactors.md
Normal 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
|
||||
68
.claude/skills/libxrpl/tx/transactors/AMM.md
Normal file
68
.claude/skills/libxrpl/tx/transactors/AMM.md
Normal 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
|
||||
44
.claude/skills/libxrpl/tx/transactors/Check.md
Normal file
44
.claude/skills/libxrpl/tx/transactors/Check.md
Normal 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
|
||||
43
.claude/skills/libxrpl/tx/transactors/Delegate.md
Normal file
43
.claude/skills/libxrpl/tx/transactors/Delegate.md
Normal 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
|
||||
69
.claude/skills/libxrpl/tx/transactors/Lending.md
Normal file
69
.claude/skills/libxrpl/tx/transactors/Lending.md
Normal 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)
|
||||
53
.claude/skills/libxrpl/tx/transactors/MPT.md
Normal file
53
.claude/skills/libxrpl/tx/transactors/MPT.md
Normal 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
|
||||
76
.claude/skills/libxrpl/tx/transactors/NFT.md
Normal file
76
.claude/skills/libxrpl/tx/transactors/NFT.md
Normal 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)
|
||||
56
.claude/skills/libxrpl/tx/transactors/Offer.md
Normal file
56
.claude/skills/libxrpl/tx/transactors/Offer.md
Normal 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
|
||||
36
.claude/skills/libxrpl/tx/transactors/PermissionedDomain.md
Normal file
36
.claude/skills/libxrpl/tx/transactors/PermissionedDomain.md
Normal 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
|
||||
61
.claude/skills/libxrpl/tx/transactors/Vault.md
Normal file
61
.claude/skills/libxrpl/tx/transactors/Vault.md
Normal 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
|
||||
228
.claude/skills/merge-conflicts.md
Normal file
228
.claude/skills/merge-conflicts.md
Normal file
@@ -0,0 +1,228 @@
|
||||
# Merge Conflict Resolution Guide
|
||||
|
||||
## Description
|
||||
Use when resolving merge conflicts after merging `develop` into a feature branch. Covers the key files that commonly conflict, field number allocation, namespace conventions, and the correct resolution strategy for each file type.
|
||||
|
||||
## General Principles
|
||||
|
||||
### Namespace
|
||||
- All code uses `namespace xrpl { }` (not `ripple`). If a conflict shows `namespace ripple`, take the `xrpl` version.
|
||||
- Qualified references: `xrpl::sign(...)`, `xrpl::sha256_hasher`, etc. Never `ripple::`.
|
||||
|
||||
### Header Guards
|
||||
- Always `#pragma once`. Never `#ifndef` include guards. If a conflict shows old-style guards, take the `#pragma once` version.
|
||||
|
||||
### Copyright Headers
|
||||
- The `develop` branch has removed copyright/license comment blocks from source files. If a conflict is just about the copyright header, take `develop`'s version (no header).
|
||||
|
||||
### File Moves
|
||||
- Many files have been moved from `src/xrpld/` to `src/libxrpl/` or from `src/xrpld/` headers to `include/xrpl/`. If git shows a file as "deleted in develop" but it exists at a new path, delete the old-path file (`git rm`) and keep the new-path version.
|
||||
- Common moves:
|
||||
- `src/xrpld/app/tx/detail/*.h` → `include/xrpl/tx/transactors/*.h`
|
||||
- `src/xrpld/app/tx/detail/*.cpp` → `src/libxrpl/tx/*.cpp` or `src/libxrpl/tx/transactors/*.cpp`
|
||||
- `src/xrpld/app/tx/detail/InvariantCheck.cpp` → `src/libxrpl/tx/invariants/InvariantCheck.cpp`
|
||||
|
||||
### Transactor Migration
|
||||
When merging transactors from `src/xrpld/app/tx/detail/` into `develop`, they must be fully migrated to the new libxrpl structure:
|
||||
|
||||
**File locations:**
|
||||
- Header: `src/xrpld/app/tx/detail/Foo.h` → `include/xrpl/tx/transactors/Foo.h`
|
||||
- Source: `src/xrpld/app/tx/detail/Foo.cpp` → `src/libxrpl/tx/transactors/Foo.cpp`
|
||||
- Delete the old `.cpp` (both `src/xrpld/` and `src/libxrpl/` are GLOB_RECURSE discovered — duplicates cause linker errors)
|
||||
- Optionally leave a forwarding header at the old `.h` location: `#include <xrpl/tx/transactors/Foo.h>`
|
||||
|
||||
**Header changes:**
|
||||
- `#pragma once` (not `#ifndef` guards)
|
||||
- `namespace xrpl` (not `ripple`)
|
||||
- `#include <xrpl/tx/Transactor.h>` (not `<xrpld/app/tx/detail/Transactor.h>`)
|
||||
|
||||
**Source changes:**
|
||||
- `namespace xrpl` (not `ripple`)
|
||||
- `#include <xrpl/tx/transactors/Foo.h>` (not `<xrpld/app/tx/detail/Foo.h>`)
|
||||
- `#include <xrpl/ledger/ApplyView.h>` (not `<xrpld/ledger/ApplyView.h>`)
|
||||
- `#include <xrpl/ledger/View.h>` for `describeOwnerDir`
|
||||
|
||||
**API changes in the new Transactor:**
|
||||
- `preflight1()` and `preflight2()` are **private** — transactor `preflight()` must NOT call them. The framework calls them automatically.
|
||||
- Flag checking (`tfUniversalMask`) is handled by the framework via `getFlagsMask()`. Override `getFlagsMask()` only if custom flag handling is needed; otherwise the default handles `tfUniversalMask`.
|
||||
- A simple `preflight()` that only did flag checks + preflight1/preflight2 should just `return tesSUCCESS;`
|
||||
- `ctx_.app.journal(...)` → `ctx_.registry.journal(...)`
|
||||
- `ctx_.app` does not exist in the new `ApplyContext`; use `ctx_.registry` for service access
|
||||
|
||||
**transactions.macro entry:**
|
||||
Every transactor must have a `#if TRANSACTION_INCLUDE` block:
|
||||
```cpp
|
||||
#if TRANSACTION_INCLUDE
|
||||
# include <xrpl/tx/transactors/Foo.h>
|
||||
#endif
|
||||
TRANSACTION(ttFOO, <number>, Foo, ...)
|
||||
```
|
||||
|
||||
### Include Paths
|
||||
- `develop` uses the new macro-based transactor include system via `transactions.macro` with `TRANSACTION_INCLUDE`. Old-style explicit `#include <xrpld/app/tx/detail/*.h>` lists should be replaced with the macro approach.
|
||||
|
||||
## File-Specific Resolution Rules
|
||||
|
||||
### `include/xrpl/protocol/detail/features.macro`
|
||||
|
||||
New feature amendments go **at the top** of the active list (below the macro guard checks and `// clang-format off`), in reverse chronological order.
|
||||
|
||||
```
|
||||
// Add new amendments to the top of this list.
|
||||
// Keep it sorted in reverse chronological order.
|
||||
|
||||
XRPL_FEATURE(MyNewFeature, Supported::yes, VoteBehavior::DefaultNo)
|
||||
XRPL_FIX (ExistingFix, Supported::yes, VoteBehavior::DefaultNo)
|
||||
...
|
||||
```
|
||||
|
||||
Resolution: Keep both sides' new amendments. Place your feature branch's new amendments at the very top.
|
||||
|
||||
### `include/xrpl/protocol/detail/sfields.macro`
|
||||
|
||||
Fields are grouped by type (UINT32, UINT64, UINT128, etc.) with common and uncommon sections. Each field has a unique **type + field number** pair.
|
||||
|
||||
**Resolution strategy:**
|
||||
1. Keep both sides' new fields.
|
||||
2. Check for field number collisions within each type. Use the next available number for your feature's fields.
|
||||
3. Common fields come first, uncommon fields after (there's a comment separator).
|
||||
|
||||
To find the next available field number for a type:
|
||||
```bash
|
||||
grep "TYPED_SFIELD.*UINT32" include/xrpl/protocol/detail/sfields.macro | sed 's/.*UINT32, *//;s/).*//' | sort -n
|
||||
```
|
||||
|
||||
Similarly for OBJECT and ARRAY types (using `UNTYPED_SFIELD`):
|
||||
```bash
|
||||
grep "UNTYPED_SFIELD.*OBJECT" include/xrpl/protocol/detail/sfields.macro | sed 's/.*OBJECT, *//;s/).*//' | sort -n
|
||||
grep "UNTYPED_SFIELD.*ARRAY" include/xrpl/protocol/detail/sfields.macro | sed 's/.*ARRAY, *//;s/).*//' | sort -n
|
||||
```
|
||||
|
||||
### `include/xrpl/protocol/detail/transactions.macro`
|
||||
|
||||
Transaction types have a unique **transaction type number**. New feature transactions go **at the bottom** of the active transaction list (before the system transactions starting at 100+).
|
||||
|
||||
**Resolution strategy:**
|
||||
1. Keep all of `develop`'s transactions.
|
||||
2. Add your feature's transactions at the bottom with the next available number.
|
||||
3. Use the new 7-argument `TRANSACTION` macro format:
|
||||
|
||||
```cpp
|
||||
/** Description of the transaction */
|
||||
#if TRANSACTION_INCLUDE
|
||||
# include <xrpl/tx/transactors/MyTransactor.h>
|
||||
#endif
|
||||
TRANSACTION(ttMY_TX, <next_number>, MyTx,
|
||||
Delegation::delegable,
|
||||
featureMyFeature,
|
||||
noPriv, ({
|
||||
{sfSomeField, soeREQUIRED},
|
||||
}))
|
||||
```
|
||||
|
||||
To find the next available transaction number:
|
||||
```bash
|
||||
grep "^TRANSACTION(" include/xrpl/protocol/detail/transactions.macro | sed 's/.*,\s*\([0-9]*\),.*/\1/' | sort -n
|
||||
```
|
||||
|
||||
Note: Transaction numbers 100+ are reserved for system transactions (amendments, fees, UNL).
|
||||
|
||||
### `include/xrpl/protocol/detail/ledger_entries.macro`
|
||||
|
||||
Ledger entry types have a unique **ledger type number** (hex). New entries go **at the bottom** of the active list.
|
||||
|
||||
**Resolution strategy:**
|
||||
1. Keep all of `develop`'s entries.
|
||||
2. Add your feature's entries at the bottom with the next available hex number.
|
||||
3. Check for collisions:
|
||||
|
||||
```bash
|
||||
grep "^LEDGER_ENTRY(" include/xrpl/protocol/detail/ledger_entries.macro | grep -o '0x[0-9a-fA-F]*' | sort
|
||||
```
|
||||
|
||||
### `src/libxrpl/protocol/Indexes.cpp`
|
||||
|
||||
The `LedgerNameSpace` enum assigns a unique single character to each ledger entry type for index hashing.
|
||||
|
||||
**Resolution strategy:**
|
||||
1. Keep both sides' entries.
|
||||
2. Check for character collisions. Each entry needs a unique char.
|
||||
3. Find used characters:
|
||||
|
||||
```bash
|
||||
grep -E "^\s+[A-Z_]+ = " src/libxrpl/protocol/Indexes.cpp | sed "s/.*= '//;s/'.*//" | sort | tr -d '\n'
|
||||
```
|
||||
|
||||
Also check the deprecated chars (reserved, cannot reuse):
|
||||
```bash
|
||||
grep "deprecated" src/libxrpl/protocol/Indexes.cpp | sed "s/.*= '//;s/'.*//"
|
||||
```
|
||||
|
||||
### `src/libxrpl/protocol/InnerObjectFormats.cpp`
|
||||
|
||||
Inner object formats define the fields allowed inside array elements (e.g., `sfSigners`, `sfPasskeys`).
|
||||
|
||||
**Resolution:** Keep both sides' `add(...)` calls. No numbering conflicts here — just ensure no duplicate registrations.
|
||||
|
||||
### `src/libxrpl/protocol/STTx.cpp`
|
||||
|
||||
The `singleSignHelper` function was refactored in `develop`:
|
||||
- Parameter name: `sigObject` (not `signer`)
|
||||
- Signature retrieval: `sigObject.getFieldVL(sfTxnSignature)` (not `getSignature(signer)`)
|
||||
- No `fullyCanonical` parameter — canonical sig checking was simplified
|
||||
|
||||
**Resolution:** Take `develop`'s function signatures and patterns. Adapt any feature-specific logic to match.
|
||||
|
||||
### `src/libxrpl/protocol/SecretKey.cpp`
|
||||
|
||||
**Resolution:** Use `namespace xrpl`. Keep any additional `#include` directives your feature needs (e.g., OpenSSL headers for new key types).
|
||||
|
||||
### `src/libxrpl/tx/Transactor.cpp`
|
||||
|
||||
The `checkSign` / `checkSingleSign` / `checkMultiSign` functions were refactored in `develop`:
|
||||
- `checkSingleSign` no longer takes a `Rules` parameter
|
||||
- `checkSign` has a new overload taking `PreclaimContext`
|
||||
- `checkBatchSign` uses the simplified `checkSingleSign` call
|
||||
|
||||
**Resolution:** Take `develop`'s function signatures. Add any new authentication checks (e.g., passkey verification) into `checkSingleSign` before the final `return tefBAD_AUTH`, using `view.read(...)` to check ledger state.
|
||||
|
||||
### `src/libxrpl/tx/applySteps.cpp`
|
||||
|
||||
**Resolution:** Always take `develop`'s macro-based include approach:
|
||||
```cpp
|
||||
#include <xrpl/tx/applySteps.h>
|
||||
#pragma push_macro("TRANSACTION")
|
||||
#undef TRANSACTION
|
||||
|
||||
#define TRANSACTION(...)
|
||||
#define TRANSACTION_INCLUDE 1
|
||||
|
||||
#include <xrpl/protocol/detail/transactions.macro>
|
||||
|
||||
#undef TRANSACTION
|
||||
#pragma pop_macro("TRANSACTION")
|
||||
```
|
||||
|
||||
Never use the old explicit `#include <xrpld/app/tx/detail/*.h>` list.
|
||||
|
||||
### `src/test/jtx/impl/utility.cpp`
|
||||
|
||||
The `sign` function was refactored in `develop`:
|
||||
- Takes `sigObject` parameter: `sign(Json::Value& jv, Account const& account, Json::Value& sigObject)`
|
||||
- Has an overload: `sign(Json::Value& jv, Account const& account)` that calls `sign(jv, account, jv)`
|
||||
- Uses `xrpl::sign(...)` not `ripple::sign(...)`
|
||||
|
||||
**Resolution:** Take `develop`'s function signatures. Adapt feature-specific signing logic to the new pattern.
|
||||
|
||||
## Conflict Resolution Checklist
|
||||
|
||||
1. List all conflicted files: `git diff --name-only --diff-filter=U`
|
||||
2. Check which have actual conflict markers vs just unmerged: `grep -l "<<<<<<< HEAD" <file>`
|
||||
3. For files without markers: stage them or `git rm` if they were moved
|
||||
4. For each file with markers:
|
||||
- Take `develop`'s structural changes (namespace, function signatures, macro formats)
|
||||
- Preserve your feature's additions (new fields, entries, transactions, logic)
|
||||
- Resolve any numbering collisions by incrementing to the next available number
|
||||
5. Stage resolved files: `git add <file>`
|
||||
6. Verify no remaining markers: `grep -r "<<<<<<< " --include="*.cpp" --include="*.h" --include="*.macro"`
|
||||
7. Verify no remaining unmerged: `git diff --name-only --diff-filter=U`
|
||||
57
.claude/skills/xrpld/app.md
Normal file
57
.claude/skills/xrpld/app.md
Normal 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
|
||||
47
.claude/skills/xrpld/app/consensus.md
Normal file
47
.claude/skills/xrpld/app/consensus.md
Normal 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
|
||||
67
.claude/skills/xrpld/app/ledger.md
Normal file
67
.claude/skills/xrpld/app/ledger.md
Normal 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
|
||||
18
.claude/skills/xrpld/app/ledger/detail.md
Normal file
18
.claude/skills/xrpld/app/ledger/detail.md
Normal 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
|
||||
54
.claude/skills/xrpld/app/main.md
Normal file
54
.claude/skills/xrpld/app/main.md
Normal 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
|
||||
75
.claude/skills/xrpld/app/misc.md
Normal file
75
.claude/skills/xrpld/app/misc.md
Normal 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
|
||||
18
.claude/skills/xrpld/app/misc/detail.md
Normal file
18
.claude/skills/xrpld/app/misc/detail.md
Normal 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
|
||||
53
.claude/skills/xrpld/app/paths.md
Normal file
53
.claude/skills/xrpld/app/paths.md
Normal 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
|
||||
18
.claude/skills/xrpld/app/paths/detail.md
Normal file
18
.claude/skills/xrpld/app/paths/detail.md
Normal 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
|
||||
39
.claude/skills/xrpld/app/rdb.md
Normal file
39
.claude/skills/xrpld/app/rdb.md
Normal 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
|
||||
31
.claude/skills/xrpld/app/rdb/backend.md
Normal file
31
.claude/skills/xrpld/app/rdb/backend.md
Normal 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
|
||||
11
.claude/skills/xrpld/app/rdb/backend/detail.md
Normal file
11
.claude/skills/xrpld/app/rdb/backend/detail.md
Normal 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
|
||||
18
.claude/skills/xrpld/app/rdb/detail.md
Normal file
18
.claude/skills/xrpld/app/rdb/detail.md
Normal 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
|
||||
34
.claude/skills/xrpld/app/tx.md
Normal file
34
.claude/skills/xrpld/app/tx.md
Normal 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
|
||||
11
.claude/skills/xrpld/app/tx/detail.md
Normal file
11
.claude/skills/xrpld/app/tx/detail.md
Normal 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
|
||||
59
.claude/skills/xrpld/consensus.md
Normal file
59
.claude/skills/xrpld/consensus.md
Normal 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
|
||||
55
.claude/skills/xrpld/core.md
Normal file
55
.claude/skills/xrpld/core.md
Normal 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
|
||||
11
.claude/skills/xrpld/core/detail.md
Normal file
11
.claude/skills/xrpld/core/detail.md
Normal 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)
|
||||
74
.claude/skills/xrpld/overlay.md
Normal file
74
.claude/skills/xrpld/overlay.md
Normal 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
|
||||
27
.claude/skills/xrpld/overlay/detail.md
Normal file
27
.claude/skills/xrpld/overlay/detail.md
Normal 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
|
||||
58
.claude/skills/xrpld/peerfinder.md
Normal file
58
.claude/skills/xrpld/peerfinder.md
Normal 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
|
||||
21
.claude/skills/xrpld/peerfinder/detail.md
Normal file
21
.claude/skills/xrpld/peerfinder/detail.md
Normal 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/
|
||||
31
.claude/skills/xrpld/perflog.md
Normal file
31
.claude/skills/xrpld/perflog.md
Normal 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
|
||||
11
.claude/skills/xrpld/perflog/detail.md
Normal file
11
.claude/skills/xrpld/perflog/detail.md
Normal 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/
|
||||
91
.claude/skills/xrpld/rpc.md
Normal file
91
.claude/skills/xrpld/rpc.md
Normal 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
|
||||
11
.claude/skills/xrpld/rpc/detail.md
Normal file
11
.claude/skills/xrpld/rpc/detail.md
Normal 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/
|
||||
74
.claude/skills/xrpld/rpc/handlers.md
Normal file
74
.claude/skills/xrpld/rpc/handlers.md
Normal 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
|
||||
32
.claude/skills/xrpld/shamap.md
Normal file
32
.claude/skills/xrpld/shamap.md
Normal 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
247
.cmake-format.yaml
Normal 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: {}
|
||||
@@ -1,14 +1,14 @@
|
||||
ignorePaths:
|
||||
- build/**
|
||||
- src/libxrpl/crypto
|
||||
- src/test/** # Will be removed in the future
|
||||
- CMakeUserPresets.json
|
||||
- Doxyfile
|
||||
- docs/**/*.puml
|
||||
- cmake/**
|
||||
- LICENSE.md
|
||||
- .clang-tidy
|
||||
language: en
|
||||
allowCompoundWords: true # TODO (#6334)
|
||||
allowCompoundWords: true
|
||||
ignoreRandomStrings: true
|
||||
minWordLength: 5
|
||||
dictionaries:
|
||||
@@ -16,29 +16,20 @@ dictionaries:
|
||||
- en_US
|
||||
- en_GB
|
||||
ignoreRegExpList:
|
||||
- /\b[rs][1-9A-HJ-NP-Za-km-z]{25,34}/g # addresses and seeds
|
||||
- /\bC[A-Z0-9]{15}/g # CTIDs
|
||||
- /\b(XRPL|BEAST)_[A-Z_0-9]+_H_INCLUDED+/g # include guards
|
||||
- /\b(XRPL|BEAST)_[A-Z_0-9]+_H+/g # include guards
|
||||
- /[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
|
||||
- /\blib[a-z]+/g # libraries
|
||||
- /\b[0-9]{4}-[0-9]{2}-[0-9]{2}[,:][A-Za-zÀ-ÖØ-öø-ÿ.\s]+/g # copyright dates
|
||||
- /\b[0-9]{4}[,:]?\s*[A-Za-zÀ-ÖØ-öø-ÿ.\s]+/g # copyright years
|
||||
- /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
|
||||
- ABCDEFGHIJKLMNOPQRSTUVWXYZ
|
||||
- ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
|
||||
overrides:
|
||||
- filename: "**/*_test.cpp" # all test files
|
||||
ignoreRegExpList:
|
||||
- /"[^"]*"/g # double-quoted strings
|
||||
- /'[^']*'/g # single-quoted strings
|
||||
- /`[^`]*`/g # backtick strings
|
||||
suggestWords:
|
||||
- xprl->xrpl
|
||||
- xprld->xrpld # cspell: disable-line not sure what this problem is....
|
||||
- unsynched->unsynced # cspell: disable-line not sure what this problem is....
|
||||
- xprld->xrpld
|
||||
- unsynched->unsynced
|
||||
- synched->synced
|
||||
- synch->sync
|
||||
words:
|
||||
@@ -60,7 +51,6 @@ words:
|
||||
- Britto
|
||||
- Btrfs
|
||||
- canonicality
|
||||
- changespq
|
||||
- checkme
|
||||
- choco
|
||||
- chrono
|
||||
@@ -99,7 +89,6 @@ words:
|
||||
- endmacro
|
||||
- exceptioned
|
||||
- Falco
|
||||
- fcontext
|
||||
- finalizers
|
||||
- firewalled
|
||||
- fmtdur
|
||||
@@ -112,20 +101,17 @@ words:
|
||||
- gpgcheck
|
||||
- gpgkey
|
||||
- hotwallet
|
||||
- hwaddress
|
||||
- hwrap
|
||||
- ifndef
|
||||
- inequation
|
||||
- insuf
|
||||
- insuff
|
||||
- invasively
|
||||
- iou
|
||||
- ious
|
||||
- isrdc
|
||||
- itype
|
||||
- jemalloc
|
||||
- jlog
|
||||
- jtnofill
|
||||
- keylet
|
||||
- keylets
|
||||
- keyvadb
|
||||
@@ -152,7 +138,6 @@ words:
|
||||
- Metafuncton
|
||||
- misprediction
|
||||
- mptbalance
|
||||
- MPTDEX
|
||||
- mptflags
|
||||
- mptid
|
||||
- mptissuance
|
||||
@@ -162,7 +147,6 @@ words:
|
||||
- mptokenissuance
|
||||
- mptokens
|
||||
- mpts
|
||||
- mtgox
|
||||
- multisig
|
||||
- multisign
|
||||
- multisigned
|
||||
@@ -175,11 +159,6 @@ words:
|
||||
- nftokens
|
||||
- nftpage
|
||||
- nikb
|
||||
- nixfmt
|
||||
- nixos
|
||||
- nixpkgs
|
||||
- NOLINT
|
||||
- NOLINTNEXTLINE
|
||||
- nonxrp
|
||||
- noripple
|
||||
- nudb
|
||||
@@ -195,7 +174,6 @@ words:
|
||||
- perminute
|
||||
- permissioned
|
||||
- pointee
|
||||
- populator
|
||||
- preauth
|
||||
- preauthorization
|
||||
- preauthorize
|
||||
@@ -204,9 +182,7 @@ words:
|
||||
- protobuf
|
||||
- protos
|
||||
- ptrs
|
||||
- pushd
|
||||
- pyenv
|
||||
- pyparsing
|
||||
- qalloc
|
||||
- queuable
|
||||
- Raphson
|
||||
@@ -232,7 +208,6 @@ words:
|
||||
- seqit
|
||||
- sf
|
||||
- SFIELD
|
||||
- sfields
|
||||
- shamap
|
||||
- shamapitem
|
||||
- sidechain
|
||||
@@ -1,101 +0,0 @@
|
||||
# Custom CMake command definitions for gersemi formatting.
|
||||
# These stubs teach gersemi the signatures of project-specific commands
|
||||
# so it can format their invocations correctly.
|
||||
|
||||
function(git_branch branch_val)
|
||||
endfunction()
|
||||
|
||||
function(isolate_headers target A B scope)
|
||||
endfunction()
|
||||
|
||||
function(create_symbolic_link target link)
|
||||
endfunction()
|
||||
|
||||
function(xrpl_add_test name)
|
||||
endfunction()
|
||||
|
||||
macro(exclude_from_default target_)
|
||||
endmacro()
|
||||
|
||||
macro(exclude_if_included target_)
|
||||
endmacro()
|
||||
|
||||
function(target_protobuf_sources target prefix)
|
||||
set(options APPEND_PATH DESCRIPTORS)
|
||||
set(oneValueArgs
|
||||
LANGUAGE
|
||||
OUT_VAR
|
||||
EXPORT_MACRO
|
||||
TARGET
|
||||
PROTOC_OUT_DIR
|
||||
PLUGIN
|
||||
PLUGIN_OPTIONS
|
||||
PROTOC_EXE
|
||||
)
|
||||
set(multiValueArgs
|
||||
PROTOS
|
||||
IMPORT_DIRS
|
||||
GENERATE_EXTENSIONS
|
||||
PROTOC_OPTIONS
|
||||
DEPENDENCIES
|
||||
)
|
||||
cmake_parse_arguments(
|
||||
THIS_FUNCTION_PREFIX
|
||||
"${options}"
|
||||
"${oneValueArgs}"
|
||||
"${multiValueArgs}"
|
||||
${ARGN}
|
||||
)
|
||||
endfunction()
|
||||
|
||||
function(add_module parent name)
|
||||
endfunction()
|
||||
|
||||
function(setup_protocol_autogen)
|
||||
endfunction()
|
||||
|
||||
function(target_link_modules parent scope)
|
||||
endfunction()
|
||||
|
||||
function(setup_target_for_coverage_gcovr)
|
||||
set(options NONE)
|
||||
set(oneValueArgs BASE_DIRECTORY NAME FORMAT)
|
||||
set(multiValueArgs EXCLUDE EXECUTABLE EXECUTABLE_ARGS DEPENDENCIES)
|
||||
cmake_parse_arguments(
|
||||
THIS_FUNCTION_PREFIX
|
||||
"${options}"
|
||||
"${oneValueArgs}"
|
||||
"${multiValueArgs}"
|
||||
${ARGN}
|
||||
)
|
||||
endfunction()
|
||||
|
||||
function(add_code_coverage_to_target name scope)
|
||||
endfunction()
|
||||
|
||||
function(verbose_find_path variable name)
|
||||
set(options
|
||||
NO_CACHE
|
||||
REQUIRED
|
||||
OPTIONAL
|
||||
NO_DEFAULT_PATH
|
||||
NO_PACKAGE_ROOT_PATH
|
||||
NO_CMAKE_PATH
|
||||
NO_CMAKE_ENVIRONMENT_PATH
|
||||
NO_SYSTEM_ENVIRONMENT_PATH
|
||||
NO_CMAKE_SYSTEM_PATH
|
||||
NO_CMAKE_INSTALL_PREFIX
|
||||
CMAKE_FIND_ROOT_PATH_BOTH
|
||||
ONLY_CMAKE_FIND_ROOT_PATH
|
||||
NO_CMAKE_FIND_ROOT_PATH
|
||||
)
|
||||
set(oneValueArgs REGISTRY_VIEW VALIDATOR DOC)
|
||||
set(multiValueArgs NAMES HINTS PATHS PATH_SUFFIXES)
|
||||
cmake_parse_arguments(
|
||||
THIS_FUNCTION_PREFIX
|
||||
"${options}"
|
||||
"${oneValueArgs}"
|
||||
"${multiValueArgs}"
|
||||
${ARGN}
|
||||
)
|
||||
endfunction()
|
||||
@@ -1 +0,0 @@
|
||||
definitions: [.gersemi]
|
||||
@@ -1,79 +1,16 @@
|
||||
# This feature requires Git >= 2.24
|
||||
# To use it by default in git blame:
|
||||
# git config blame.ignoreRevsFile .git-blame-ignore-revs
|
||||
|
||||
# This file is sorted in reverse chronological order, with the most recent commits at the top.
|
||||
# The commits listed here are ignored by git blame, which is useful for formatting-only commits that would otherwise obscure the history of changes to a file.
|
||||
|
||||
# refactor: Enable remaining clang-tidy `cppcoreguidelines` checks (#6538)
|
||||
72f4cb097f626b08b02fc3efcb4aa11cb2e7adb8
|
||||
# refactor: Rename system name from 'ripple' to 'xrpld' (#6347)
|
||||
ffea3977f0b771fe8e43a8f74e4d393d63a7afd8
|
||||
# refactor: Update transaction folder structure (#6483)
|
||||
5865bd017f777491b4a956f9210be0c4161f5442
|
||||
# chore: Use gersemi instead of ancient cmake-format (#6486)
|
||||
0c74270b055133a57a497b5c9fc5a75f7647b1f4
|
||||
# chore: Apply clang-format width 100 (#6387)
|
||||
2c1fad102353e11293e3edde1c043224e7d3e983
|
||||
# chore: Set clang-format width to 100 in config file (#6387)
|
||||
25cca465538a56cce501477f9e5e2c1c7ea2d84c
|
||||
# chore: Set cmake-format width to 100 (#6386)
|
||||
469ce9f291a4480c38d4ee3baca5136b2f053cd0
|
||||
# refactor: Modularize app/tx (#6228)
|
||||
0976b2b68b64972af8e6e7c497900b5bce9fe22f
|
||||
# chore: Update clang-format to 21.1.8 (#6352)
|
||||
958d8f375453d80bb1aa4c293b5102c045a3e4b4
|
||||
# refactor: Replace include guards by '#pragma once' (#6322)
|
||||
34ef577604782ca8d6e1c17df8bd7470990a52ff
|
||||
# chore: Format all cmake files without comments (#6294)
|
||||
fe9c8d568fcf6ac21483024e01f58962dd5c8260
|
||||
# chore: Add cmake-format pre-commit hook (#6279)
|
||||
a0e09187b9370805d027c611a7e9ff5a0125282a
|
||||
# chore: Set ColumnLimit to 120 in clang-format (#6288)
|
||||
5f638f55536def0d88b970d1018a465a238e55f4
|
||||
# refactor: Fix typos in comments, configure cspell (#6164)
|
||||
3c9f5b62525cb1d6ca1153eeb10433db7d7379fd
|
||||
# refactor: Rename `rippled.cfg` to `xrpld.cfg` (#6098)
|
||||
3d1b3a49b3601a0a7037fa0b19d5df7b5e0e2fc1
|
||||
# refactor: Rename `ripple` namespace to `xrpl` (#5982)
|
||||
1eb0fdac6543706b4b9ddca57fd4102928a1f871
|
||||
# refactor: Rename `rippled` binary to `xrpld` (#5983)
|
||||
9eb84a561ef8bb066d89f098bd9b4ac71baed67c
|
||||
# refactor: Replaces secp256k1 source by Conan package (#6089)
|
||||
813bc4d9491b078bb950f8255f93b02f71320478
|
||||
# refactor: Remove unnecessary copyright notices already covered by LICENSE.md (#5929)
|
||||
1d42c4f6de6bf01d1286fc7459b17a37a5189e88
|
||||
# refactor: Rename `RIPPLE_` and `RIPPLED_` definitions to `XRPL_` (#5821)
|
||||
ada83564d894829424b0f4d922b0e737e07abbf7
|
||||
# refactor: Modularize shamap and nodestore (#5668)
|
||||
8eb233c2ea8ad5a159be73b77f0f5e1496d547ac
|
||||
# refactor: Modularise ledger (#5493)
|
||||
dc8b37a52448b005153c13a7f046ad494128cf94
|
||||
# chore: Update clang-format and prettier with pre-commit (#5709)
|
||||
c14ce956adeabe476ad73c18d73103f347c9c613
|
||||
# chore: Fix file formatting (#5718)
|
||||
896b8c3b54a22b0497cb0d1ce95e1095f9a227ce
|
||||
# chore: Reverts formatting changes to external files, adds formatting changes to proto files (#5711)
|
||||
b13370ac0d207217354f1fc1c29aef87769fb8a1
|
||||
# chore: Run prettier on all files (#5657)
|
||||
97f0747e103f13e26e45b731731059b32f7679ac
|
||||
# Reformat code with clang-format-18
|
||||
552377c76f55b403a1c876df873a23d780fcc81c
|
||||
# Recompute loops (#4997)
|
||||
d028005aa6319338b0adae1aebf8abe113162960
|
||||
# Rewrite includes (#4997)
|
||||
1d23148e6dd53957fcb6205c07a5c6cd7b64d50c
|
||||
# Rearrange sources (#4997)
|
||||
e416ee72ca26fa0c09d2aee1b68bdfb2b7046eed
|
||||
# Move CMake directory (#4997)
|
||||
2e902dee53aab2a8f27f32971047bb81e022f94f
|
||||
# Rewrite includes
|
||||
0eebe6a5f4246fced516d52b83ec4e7f47373edd
|
||||
# Format formerly .hpp files
|
||||
760f16f56835663d9286bd29294d074de26a7ba6
|
||||
# Rename .hpp to .h
|
||||
241b9ddde9e11beb7480600fd5ed90e1ef109b21
|
||||
# Consolidate external libraries
|
||||
e2384885f5f630c8f0ffe4bf21a169b433a16858
|
||||
# Format first-party source according to .clang-format
|
||||
50760c693510894ca368e90369b0cc2dabfd07f3
|
||||
e2384885f5f630c8f0ffe4bf21a169b433a16858
|
||||
241b9ddde9e11beb7480600fd5ed90e1ef109b21
|
||||
760f16f56835663d9286bd29294d074de26a7ba6
|
||||
0eebe6a5f4246fced516d52b83ec4e7f47373edd
|
||||
2189cc950c0cebb89e4e2fa3b2d8817205bf7cef
|
||||
b9d007813378ad0ff45660dc07285b823c7e9855
|
||||
fe9a5365b8a52d4acc42eb27369247e6f238a4f9
|
||||
9a93577314e6a8d4b4a8368cc9d2b15a5d8303e8
|
||||
552377c76f55b403a1c876df873a23d780fcc81c
|
||||
97f0747e103f13e26e45b731731059b32f7679ac
|
||||
b13370ac0d207217354f1fc1c29aef87769fb8a1
|
||||
896b8c3b54a22b0497cb0d1ce95e1095f9a227ce
|
||||
|
||||
4
.github/actions/generate-version/action.yml
vendored
4
.github/actions/generate-version/action.yml
vendored
@@ -11,7 +11,7 @@ runs:
|
||||
steps:
|
||||
# When a tag is pushed, the version is used as-is.
|
||||
- name: Generate version for tag event
|
||||
if: ${{ startsWith(github.ref, 'refs/tags/') }}
|
||||
if: ${{ github.event_name == 'tag' }}
|
||||
shell: bash
|
||||
env:
|
||||
VERSION: ${{ github.ref_name }}
|
||||
@@ -22,7 +22,7 @@ runs:
|
||||
# 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: ${{ !startsWith(github.ref, 'refs/tags/') }}
|
||||
if: ${{ github.event_name != 'tag' }}
|
||||
shell: bash
|
||||
run: |
|
||||
echo 'Extracting version from BuildInfo.cpp.'
|
||||
|
||||
56
.github/dependabot.yml
vendored
56
.github/dependabot.yml
vendored
@@ -1,56 +0,0 @@
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: github-actions
|
||||
directory: /
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
time: "04:00"
|
||||
timezone: Etc/GMT
|
||||
commit-message:
|
||||
prefix: "ci: [DEPENDABOT] "
|
||||
target-branch: develop
|
||||
|
||||
- package-ecosystem: github-actions
|
||||
directory: .github/actions/build-deps/
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
time: "04:00"
|
||||
timezone: Etc/GMT
|
||||
commit-message:
|
||||
prefix: "ci: [DEPENDABOT] "
|
||||
target-branch: develop
|
||||
|
||||
- package-ecosystem: github-actions
|
||||
directory: .github/actions/generate-version/
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
time: "04:00"
|
||||
timezone: Etc/GMT
|
||||
commit-message:
|
||||
prefix: "ci: [DEPENDABOT] "
|
||||
target-branch: develop
|
||||
|
||||
- package-ecosystem: github-actions
|
||||
directory: .github/actions/print-env/
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
time: "04:00"
|
||||
timezone: Etc/GMT
|
||||
commit-message:
|
||||
prefix: "ci: [DEPENDABOT] "
|
||||
target-branch: develop
|
||||
|
||||
- package-ecosystem: github-actions
|
||||
directory: .github/actions/setup-conan/
|
||||
schedule:
|
||||
interval: weekly
|
||||
day: monday
|
||||
time: "04:00"
|
||||
timezone: Etc/GMT
|
||||
commit-message:
|
||||
prefix: "ci: [DEPENDABOT] "
|
||||
target-branch: develop
|
||||
16
.github/pull_request_template.md
vendored
16
.github/pull_request_template.md
vendored
@@ -29,6 +29,22 @@ If a refactor, how is this better than the previous implementation?
|
||||
If there is a spec or design document for this feature, please link it here.
|
||||
-->
|
||||
|
||||
### Type of Change
|
||||
|
||||
<!--
|
||||
Please check [x] relevant options, delete irrelevant ones.
|
||||
-->
|
||||
|
||||
- [ ] Bug fix (non-breaking change which fixes an issue)
|
||||
- [ ] New feature (non-breaking change which adds functionality)
|
||||
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
|
||||
- [ ] Refactor (non-breaking change that only restructures code)
|
||||
- [ ] Performance (increase or change in throughput and/or latency)
|
||||
- [ ] Tests (you added tests for code that already exists, or your new feature included in this PR)
|
||||
- [ ] Documentation update
|
||||
- [ ] Chore (no impact to binary, e.g. `.gitignore`, formatting, dropping support for older tooling)
|
||||
- [ ] Release
|
||||
|
||||
### API Impact
|
||||
|
||||
<!--
|
||||
|
||||
6
.github/scripts/levelization/README.md
vendored
6
.github/scripts/levelization/README.md
vendored
@@ -70,7 +70,7 @@ that `test` code should _never_ be included in `xrpl` or `xrpld` code.)
|
||||
|
||||
## Validation
|
||||
|
||||
The [levelization](generate.py) script takes no parameters,
|
||||
The [levelization](generate.sh) script takes no parameters,
|
||||
reads no environment variables, and can be run from any directory,
|
||||
as long as it is in the expected location in the rippled repo.
|
||||
It can be run at any time from within a checked out repo, and will
|
||||
@@ -104,7 +104,7 @@ It generates many files of [results](results):
|
||||
Github Actions workflow to test that levelization loops haven't
|
||||
changed. Unfortunately, if changes are detected, it can't tell if
|
||||
they are improvements or not, so if you have resolved any issues or
|
||||
done anything else to improve levelization, run `generate.py`,
|
||||
done anything else to improve levelization, run `levelization.sh`,
|
||||
and commit the updated results.
|
||||
|
||||
The `loops.txt` and `ordering.txt` files relate the modules
|
||||
@@ -128,7 +128,7 @@ The committed files hide the detailed values intentionally, to
|
||||
prevent false alarms and merging issues, and because it's easy to
|
||||
get those details locally.
|
||||
|
||||
1. Run `generate.py`
|
||||
1. Run `levelization.sh`
|
||||
2. Grep the modules in `paths.txt`.
|
||||
- For example, if a cycle is found `A ~= B`, simply `grep -w
|
||||
A .github/scripts/levelization/results/paths.txt | grep -w B`
|
||||
|
||||
335
.github/scripts/levelization/generate.py
vendored
335
.github/scripts/levelization/generate.py
vendored
@@ -1,335 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
|
||||
"""
|
||||
Usage: generate.py
|
||||
This script takes no parameters, and can be called from any directory in the file system.
|
||||
"""
|
||||
|
||||
import os
|
||||
import re
|
||||
import subprocess
|
||||
import sys
|
||||
from collections import defaultdict
|
||||
from pathlib import Path
|
||||
from typing import Dict, List, Tuple, Set, Optional
|
||||
|
||||
# Compile regex patterns once at module level
|
||||
INCLUDE_PATTERN = re.compile(r"^\s*#include.*/.*\.h")
|
||||
INCLUDE_PATH_PATTERN = re.compile(r'[<"]([^>"]+)[>"]')
|
||||
|
||||
|
||||
def dictionary_sort_key(s: str) -> str:
|
||||
"""
|
||||
Create a sort key that mimics 'sort -d' (dictionary order).
|
||||
Dictionary order only considers blanks and alphanumeric characters.
|
||||
This means punctuation like '.' is ignored during sorting.
|
||||
"""
|
||||
# Keep only alphanumeric characters and spaces
|
||||
return "".join(c for c in s if c.isalnum() or c.isspace())
|
||||
|
||||
|
||||
def get_level(file_path: str) -> str:
|
||||
"""
|
||||
Extract the level from a file path (second and third directory components).
|
||||
Equivalent to bash: cut -d/ -f 2,3
|
||||
|
||||
Examples:
|
||||
src/xrpld/app/main.cpp -> xrpld.app
|
||||
src/libxrpl/protocol/STObject.cpp -> libxrpl.protocol
|
||||
include/xrpl/basics/base_uint.h -> xrpl.basics
|
||||
"""
|
||||
parts = file_path.split("/")
|
||||
|
||||
# Get fields 2 and 3 (indices 1 and 2 in 0-based indexing)
|
||||
if len(parts) >= 3:
|
||||
level = f"{parts[1]}/{parts[2]}"
|
||||
elif len(parts) >= 2:
|
||||
level = f"{parts[1]}/toplevel"
|
||||
else:
|
||||
level = file_path
|
||||
|
||||
# If the "level" indicates a file, cut off the filename
|
||||
if "." in level.split("/")[-1]: # Avoid Path object creation
|
||||
# Use the "toplevel" label as a workaround for `sort`
|
||||
# inconsistencies between different utility versions
|
||||
level = level.rsplit("/", 1)[0] + "/toplevel"
|
||||
|
||||
return level.replace("/", ".")
|
||||
|
||||
|
||||
def extract_include_level(include_line: str) -> Optional[str]:
|
||||
"""
|
||||
Extract the include path from an #include directive.
|
||||
Gets the first two directory components from the include path.
|
||||
Equivalent to bash: cut -d/ -f 1,2
|
||||
|
||||
Examples:
|
||||
#include <xrpl/basics/base_uint.h> -> xrpl.basics
|
||||
#include "xrpld/app/main/Application.h" -> xrpld.app
|
||||
"""
|
||||
# Remove everything before the quote or angle bracket
|
||||
match = INCLUDE_PATH_PATTERN.search(include_line)
|
||||
if not match:
|
||||
return None
|
||||
|
||||
include_path = match.group(1)
|
||||
parts = include_path.split("/")
|
||||
|
||||
# Get first two fields (indices 0 and 1)
|
||||
if len(parts) >= 2:
|
||||
include_level = f"{parts[0]}/{parts[1]}"
|
||||
else:
|
||||
include_level = include_path
|
||||
|
||||
# If the "includelevel" indicates a file, cut off the filename
|
||||
if "." in include_level.split("/")[-1]: # Avoid Path object creation
|
||||
include_level = include_level.rsplit("/", 1)[0] + "/toplevel"
|
||||
|
||||
return include_level.replace("/", ".")
|
||||
|
||||
|
||||
def find_repository_directories(
|
||||
start_path: Path, depth_limit: int = 10
|
||||
) -> Tuple[Path, List[Path]]:
|
||||
"""
|
||||
Find the repository root by looking for src or include folders.
|
||||
Walks up the directory tree from the start path.
|
||||
"""
|
||||
current = start_path.resolve()
|
||||
|
||||
# Walk up the directory tree
|
||||
for _ in range(depth_limit): # Limit search depth to prevent infinite loops
|
||||
src_path = current / "src"
|
||||
include_path = current / "include"
|
||||
# Check if this directory has src or include folders
|
||||
has_src = src_path.exists()
|
||||
has_include = include_path.exists()
|
||||
|
||||
if has_src or has_include:
|
||||
return current, [src_path, include_path]
|
||||
|
||||
# Move up one level
|
||||
parent = current.parent
|
||||
if parent == current: # Reached filesystem root
|
||||
break
|
||||
current = parent
|
||||
|
||||
# If we couldn't find it, raise an error
|
||||
raise RuntimeError(
|
||||
"Could not find repository root. "
|
||||
"Expected to find a directory containing 'src' and/or 'include' folders."
|
||||
)
|
||||
|
||||
|
||||
def main():
|
||||
# Change to the script's directory
|
||||
script_dir = Path(__file__).parent.resolve()
|
||||
os.chdir(script_dir)
|
||||
|
||||
# Clean up and create results directory.
|
||||
results_dir = script_dir / "results"
|
||||
if results_dir.exists():
|
||||
import shutil
|
||||
|
||||
shutil.rmtree(results_dir)
|
||||
results_dir.mkdir()
|
||||
|
||||
# Find the repository root by searching for src and include directories.
|
||||
try:
|
||||
repo_root, scan_dirs = find_repository_directories(script_dir)
|
||||
|
||||
print(f"Found repository root: {repo_root}")
|
||||
print(f"Scanning directories:")
|
||||
for scan_dir in scan_dirs:
|
||||
print(f" - {scan_dir.relative_to(repo_root)}")
|
||||
except RuntimeError as e:
|
||||
print(f"Error: {e}", file=sys.stderr)
|
||||
sys.exit(1)
|
||||
|
||||
print("\nScanning for raw includes...")
|
||||
# Find all #include directives
|
||||
raw_includes: List[Tuple[str, str]] = []
|
||||
rawincludes_file = results_dir / "rawincludes.txt"
|
||||
|
||||
# Write to file as we go to avoid storing everything in memory.
|
||||
with open(rawincludes_file, "w", buffering=8192) as raw_f:
|
||||
for dir_path in scan_dirs:
|
||||
print(f" Scanning {dir_path.relative_to(repo_root)}...")
|
||||
|
||||
for file_path in dir_path.rglob("*"):
|
||||
if not file_path.is_file():
|
||||
continue
|
||||
|
||||
try:
|
||||
rel_path_str = str(file_path.relative_to(repo_root))
|
||||
|
||||
# Read file with a large buffer for performance.
|
||||
with open(
|
||||
file_path,
|
||||
"r",
|
||||
encoding="utf-8",
|
||||
errors="ignore",
|
||||
buffering=8192,
|
||||
) as f:
|
||||
for line in f:
|
||||
# Quick check before regex
|
||||
if "#include" not in line or "boost" in line:
|
||||
continue
|
||||
|
||||
if INCLUDE_PATTERN.match(line):
|
||||
line_stripped = line.strip()
|
||||
entry = f"{rel_path_str}:{line_stripped}\n"
|
||||
print(entry, end="")
|
||||
raw_f.write(entry)
|
||||
raw_includes.append((rel_path_str, line_stripped))
|
||||
except Exception as e:
|
||||
print(f"Error reading {file_path}: {e}", file=sys.stderr)
|
||||
|
||||
# Build levelization paths and count directly (no need to sort first).
|
||||
print("Build levelization paths")
|
||||
path_counts: Dict[Tuple[str, str], int] = defaultdict(int)
|
||||
|
||||
for file_path, include_line in raw_includes:
|
||||
include_level = extract_include_level(include_line)
|
||||
if not include_level:
|
||||
continue
|
||||
|
||||
level = get_level(file_path)
|
||||
if level != include_level:
|
||||
path_counts[(level, include_level)] += 1
|
||||
|
||||
# Sort and deduplicate paths (using dictionary order like bash 'sort -d').
|
||||
print("Sort and deduplicate paths")
|
||||
|
||||
paths_file = results_dir / "paths.txt"
|
||||
with open(paths_file, "w") as f:
|
||||
# Sort using dictionary order: only alphanumeric and spaces matter
|
||||
sorted_items = sorted(
|
||||
path_counts.items(),
|
||||
key=lambda x: (dictionary_sort_key(x[0][0]), dictionary_sort_key(x[0][1])),
|
||||
)
|
||||
for (level, include_level), count in sorted_items:
|
||||
line = f"{count:7} {level} {include_level}\n"
|
||||
print(line.rstrip())
|
||||
f.write(line)
|
||||
|
||||
# Split into flat-file database
|
||||
print("Split into flat-file database")
|
||||
includes_dir = results_dir / "includes"
|
||||
included_by_dir = results_dir / "included_by"
|
||||
includes_dir.mkdir()
|
||||
included_by_dir.mkdir()
|
||||
|
||||
# Batch writes by grouping data first to avoid repeated file opens.
|
||||
includes_data: Dict[str, List[Tuple[str, int]]] = defaultdict(list)
|
||||
included_by_data: Dict[str, List[Tuple[str, int]]] = defaultdict(list)
|
||||
|
||||
# Process in sorted order to match bash script behaviour (dictionary order).
|
||||
sorted_items = sorted(
|
||||
path_counts.items(),
|
||||
key=lambda x: (dictionary_sort_key(x[0][0]), dictionary_sort_key(x[0][1])),
|
||||
)
|
||||
for (level, include_level), count in sorted_items:
|
||||
includes_data[level].append((include_level, count))
|
||||
included_by_data[include_level].append((level, count))
|
||||
|
||||
# Write all includes files in sorted order (dictionary order).
|
||||
for level in sorted(includes_data.keys(), key=dictionary_sort_key):
|
||||
entries = includes_data[level]
|
||||
with open(includes_dir / level, "w") as f:
|
||||
for include_level, count in entries:
|
||||
line = f"{include_level} {count}\n"
|
||||
print(line.rstrip())
|
||||
f.write(line)
|
||||
|
||||
# Write all included_by files in sorted order (dictionary order).
|
||||
for include_level in sorted(included_by_data.keys(), key=dictionary_sort_key):
|
||||
entries = included_by_data[include_level]
|
||||
with open(included_by_dir / include_level, "w") as f:
|
||||
for level, count in entries:
|
||||
line = f"{level} {count}\n"
|
||||
print(line.rstrip())
|
||||
f.write(line)
|
||||
|
||||
# Search for loops
|
||||
print("Search for loops")
|
||||
loops_file = results_dir / "loops.txt"
|
||||
ordering_file = results_dir / "ordering.txt"
|
||||
|
||||
loops_found: Set[Tuple[str, str]] = set()
|
||||
|
||||
# Pre-load all include files into memory to avoid repeated I/O.
|
||||
# This is the biggest optimisation - we were reading files repeatedly in nested loops.
|
||||
# Use list of tuples to preserve file order.
|
||||
includes_cache: Dict[str, List[Tuple[str, int]]] = {}
|
||||
includes_lookup: Dict[str, Dict[str, int]] = {} # For fast lookup
|
||||
|
||||
# Note: bash script uses 'for source in *' which uses standard glob sorting,
|
||||
# NOT dictionary order. So we use standard sorted() here, not dictionary_sort_key.
|
||||
for include_file in sorted(includes_dir.iterdir(), key=lambda p: p.name):
|
||||
if not include_file.is_file():
|
||||
continue
|
||||
|
||||
includes_cache[include_file.name] = []
|
||||
includes_lookup[include_file.name] = {}
|
||||
with open(include_file, "r") as f:
|
||||
for line in f:
|
||||
parts = line.strip().split()
|
||||
if len(parts) >= 2:
|
||||
include_name = parts[0]
|
||||
include_count = int(parts[1])
|
||||
includes_cache[include_file.name].append(
|
||||
(include_name, include_count)
|
||||
)
|
||||
includes_lookup[include_file.name][include_name] = include_count
|
||||
|
||||
with open(loops_file, "w", buffering=8192) as loops_f, open(
|
||||
ordering_file, "w", buffering=8192
|
||||
) as ordering_f:
|
||||
|
||||
# Use standard sorting to match bash glob expansion 'for source in *'.
|
||||
for source in sorted(includes_cache.keys()):
|
||||
source_includes = includes_cache[source]
|
||||
|
||||
for include, include_freq in source_includes:
|
||||
# Check if include file exists and references source
|
||||
if include not in includes_lookup:
|
||||
continue
|
||||
|
||||
source_freq = includes_lookup[include].get(source)
|
||||
|
||||
if source_freq is not None:
|
||||
# Found a loop
|
||||
loop_key = tuple(sorted([source, include]))
|
||||
if loop_key in loops_found:
|
||||
continue
|
||||
loops_found.add(loop_key)
|
||||
|
||||
loops_f.write(f"Loop: {source} {include}\n")
|
||||
|
||||
# If the counts are close, indicate that the two modules are
|
||||
# on the same level, though they shouldn't be.
|
||||
diff = include_freq - source_freq
|
||||
if diff > 3:
|
||||
loops_f.write(f" {source} > {include}\n\n")
|
||||
elif diff < -3:
|
||||
loops_f.write(f" {include} > {source}\n\n")
|
||||
elif source_freq == include_freq:
|
||||
loops_f.write(f" {include} == {source}\n\n")
|
||||
else:
|
||||
loops_f.write(f" {include} ~= {source}\n\n")
|
||||
else:
|
||||
ordering_f.write(f"{source} > {include}\n")
|
||||
|
||||
# Print results
|
||||
print("\nOrdering:")
|
||||
with open(ordering_file, "r") as f:
|
||||
print(f.read(), end="")
|
||||
|
||||
print("\nLoops:")
|
||||
with open(loops_file, "r") as f:
|
||||
print(f.read(), end="")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
130
.github/scripts/levelization/generate.sh
vendored
Executable file
130
.github/scripts/levelization/generate.sh
vendored
Executable file
@@ -0,0 +1,130 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Usage: generate.sh
|
||||
# This script takes no parameters, reads no environment variables,
|
||||
# and can be run from any directory, as long as it is in the expected
|
||||
# location in the repo.
|
||||
|
||||
pushd $( dirname $0 )
|
||||
|
||||
if [ -v PS1 ]
|
||||
then
|
||||
# if the shell is interactive, clean up any flotsam before analyzing
|
||||
git clean -ix
|
||||
fi
|
||||
|
||||
# Ensure all sorting is ASCII-order consistently across platforms.
|
||||
export LANG=C
|
||||
|
||||
rm -rfv results
|
||||
mkdir results
|
||||
includes="$( pwd )/results/rawincludes.txt"
|
||||
pushd ../../..
|
||||
echo Raw includes:
|
||||
grep -r '^[ ]*#include.*/.*\.h' include src | \
|
||||
grep -v boost | tee ${includes}
|
||||
popd
|
||||
pushd results
|
||||
|
||||
oldifs=${IFS}
|
||||
IFS=:
|
||||
mkdir includes
|
||||
mkdir included_by
|
||||
echo Build levelization paths
|
||||
exec 3< ${includes} # open rawincludes.txt for input
|
||||
while read -r -u 3 file include
|
||||
do
|
||||
level=$( echo ${file} | cut -d/ -f 2,3 )
|
||||
# If the "level" indicates a file, cut off the filename
|
||||
if [[ "${level##*.}" != "${level}" ]]
|
||||
then
|
||||
# Use the "toplevel" label as a workaround for `sort`
|
||||
# inconsistencies between different utility versions
|
||||
level="$( dirname ${level} )/toplevel"
|
||||
fi
|
||||
level=$( echo ${level} | tr '/' '.' )
|
||||
|
||||
includelevel=$( echo ${include} | sed 's/.*["<]//; s/[">].*//' | \
|
||||
cut -d/ -f 1,2 )
|
||||
if [[ "${includelevel##*.}" != "${includelevel}" ]]
|
||||
then
|
||||
# Use the "toplevel" label as a workaround for `sort`
|
||||
# inconsistencies between different utility versions
|
||||
includelevel="$( dirname ${includelevel} )/toplevel"
|
||||
fi
|
||||
includelevel=$( echo ${includelevel} | tr '/' '.' )
|
||||
|
||||
if [[ "$level" != "$includelevel" ]]
|
||||
then
|
||||
echo $level $includelevel | tee -a paths.txt
|
||||
fi
|
||||
done
|
||||
echo Sort and deduplicate paths
|
||||
sort -ds paths.txt | uniq -c | tee sortedpaths.txt
|
||||
mv sortedpaths.txt paths.txt
|
||||
exec 3>&- #close fd 3
|
||||
IFS=${oldifs}
|
||||
unset oldifs
|
||||
|
||||
echo Split into flat-file database
|
||||
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 included_by/${include}
|
||||
done
|
||||
exec 4>&- #close fd 4
|
||||
|
||||
loops="$( pwd )/loops.txt"
|
||||
ordering="$( pwd )/ordering.txt"
|
||||
pushd includes
|
||||
echo Search for loops
|
||||
# Redirect stdout to a file
|
||||
exec 4>&1
|
||||
exec 1>"${loops}"
|
||||
for source in *
|
||||
do
|
||||
if [[ -f "$source" ]]
|
||||
then
|
||||
exec 5<"${source}" # open for input
|
||||
while read -r -u 5 include includefreq
|
||||
do
|
||||
if [[ -f $include ]]
|
||||
then
|
||||
if grep -q -w $source $include
|
||||
then
|
||||
if grep -q -w "Loop: $include $source" "${loops}"
|
||||
then
|
||||
continue
|
||||
fi
|
||||
sourcefreq=$( grep -w $source $include | cut -d\ -f2 )
|
||||
echo "Loop: $source $include"
|
||||
# If the counts are close, indicate that the two modules are
|
||||
# on the same level, though they shouldn't be
|
||||
if [[ $(( $includefreq - $sourcefreq )) -gt 3 ]]
|
||||
then
|
||||
echo -e " $source > $include\n"
|
||||
elif [[ $(( $sourcefreq - $includefreq )) -gt 3 ]]
|
||||
then
|
||||
echo -e " $include > $source\n"
|
||||
elif [[ $sourcefreq -eq $includefreq ]]
|
||||
then
|
||||
echo -e " $include == $source\n"
|
||||
else
|
||||
echo -e " $include ~= $source\n"
|
||||
fi
|
||||
else
|
||||
echo "$source > $include" >> "${ordering}"
|
||||
fi
|
||||
fi
|
||||
done
|
||||
exec 5>&- #close fd 5
|
||||
fi
|
||||
done
|
||||
exec 1>&4 #close fd 1
|
||||
exec 4>&- #close fd 4
|
||||
cat "${ordering}"
|
||||
cat "${loops}"
|
||||
popd
|
||||
popd
|
||||
popd
|
||||
@@ -4,11 +4,14 @@ Loop: test.jtx test.toplevel
|
||||
Loop: test.jtx test.unit_test
|
||||
test.unit_test == test.jtx
|
||||
|
||||
Loop: xrpld.app xrpld.core
|
||||
xrpld.app > xrpld.core
|
||||
|
||||
Loop: xrpld.app xrpld.overlay
|
||||
xrpld.overlay ~= xrpld.app
|
||||
xrpld.overlay > xrpld.app
|
||||
|
||||
Loop: xrpld.app xrpld.peerfinder
|
||||
xrpld.peerfinder == xrpld.app
|
||||
xrpld.peerfinder ~= xrpld.app
|
||||
|
||||
Loop: xrpld.app xrpld.rpc
|
||||
xrpld.rpc > xrpld.app
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
libxrpl.basics > xrpl.basics
|
||||
libxrpl.conditions > xrpl.basics
|
||||
libxrpl.conditions > xrpl.conditions
|
||||
libxrpl.core > xrpl.basics
|
||||
libxrpl.core > xrpl.core
|
||||
libxrpl.crypto > xrpl.basics
|
||||
@@ -19,28 +17,16 @@ libxrpl.nodestore > xrpl.protocol
|
||||
libxrpl.protocol > xrpl.basics
|
||||
libxrpl.protocol > xrpl.json
|
||||
libxrpl.protocol > xrpl.protocol
|
||||
libxrpl.protocol_autogen > xrpl.protocol_autogen
|
||||
libxrpl.rdb > xrpl.basics
|
||||
libxrpl.rdb > xrpl.rdb
|
||||
libxrpl.resource > xrpl.basics
|
||||
libxrpl.resource > xrpl.json
|
||||
libxrpl.resource > xrpl.resource
|
||||
libxrpl.server > xrpl.basics
|
||||
libxrpl.server > xrpl.json
|
||||
libxrpl.server > xrpl.protocol
|
||||
libxrpl.server > xrpl.rdb
|
||||
libxrpl.server > xrpl.server
|
||||
libxrpl.shamap > xrpl.basics
|
||||
libxrpl.shamap > xrpl.protocol
|
||||
libxrpl.shamap > xrpl.shamap
|
||||
libxrpl.tx > xrpl.basics
|
||||
libxrpl.tx > xrpl.conditions
|
||||
libxrpl.tx > xrpl.core
|
||||
libxrpl.tx > xrpl.json
|
||||
libxrpl.tx > xrpl.ledger
|
||||
libxrpl.tx > xrpl.protocol
|
||||
libxrpl.tx > xrpl.server
|
||||
libxrpl.tx > xrpl.tx
|
||||
test.app > test.jtx
|
||||
test.app > test.rpc
|
||||
test.app > test.toplevel
|
||||
@@ -55,10 +41,7 @@ test.app > xrpl.json
|
||||
test.app > xrpl.ledger
|
||||
test.app > xrpl.nodestore
|
||||
test.app > xrpl.protocol
|
||||
test.app > xrpl.rdb
|
||||
test.app > xrpl.resource
|
||||
test.app > xrpl.server
|
||||
test.app > xrpl.tx
|
||||
test.basics > test.jtx
|
||||
test.basics > test.unit_test
|
||||
test.basics > xrpl.basics
|
||||
@@ -68,7 +51,7 @@ test.basics > xrpl.json
|
||||
test.basics > xrpl.protocol
|
||||
test.beast > xrpl.basics
|
||||
test.conditions > xrpl.basics
|
||||
test.conditions > xrpl.conditions
|
||||
test.conditions > xrpld.conditions
|
||||
test.consensus > test.csf
|
||||
test.consensus > test.toplevel
|
||||
test.consensus > test.unit_test
|
||||
@@ -77,7 +60,6 @@ test.consensus > xrpld.app
|
||||
test.consensus > xrpld.consensus
|
||||
test.consensus > xrpl.json
|
||||
test.consensus > xrpl.ledger
|
||||
test.consensus > xrpl.tx
|
||||
test.core > test.jtx
|
||||
test.core > test.toplevel
|
||||
test.core > test.unit_test
|
||||
@@ -85,7 +67,6 @@ test.core > xrpl.basics
|
||||
test.core > xrpl.core
|
||||
test.core > xrpld.core
|
||||
test.core > xrpl.json
|
||||
test.core > xrpl.rdb
|
||||
test.core > xrpl.server
|
||||
test.csf > xrpl.basics
|
||||
test.csf > xrpld.consensus
|
||||
@@ -94,7 +75,6 @@ test.csf > xrpl.protocol
|
||||
test.json > test.jtx
|
||||
test.json > xrpl.json
|
||||
test.jtx > xrpl.basics
|
||||
test.jtx > xrpl.core
|
||||
test.jtx > xrpld.app
|
||||
test.jtx > xrpld.core
|
||||
test.jtx > xrpld.rpc
|
||||
@@ -104,7 +84,6 @@ test.jtx > xrpl.net
|
||||
test.jtx > xrpl.protocol
|
||||
test.jtx > xrpl.resource
|
||||
test.jtx > xrpl.server
|
||||
test.jtx > xrpl.tx
|
||||
test.ledger > test.jtx
|
||||
test.ledger > test.toplevel
|
||||
test.ledger > xrpl.basics
|
||||
@@ -116,8 +95,8 @@ test.nodestore > test.jtx
|
||||
test.nodestore > test.toplevel
|
||||
test.nodestore > test.unit_test
|
||||
test.nodestore > xrpl.basics
|
||||
test.nodestore > xrpld.core
|
||||
test.nodestore > xrpl.nodestore
|
||||
test.nodestore > xrpl.rdb
|
||||
test.overlay > test.jtx
|
||||
test.overlay > test.toplevel
|
||||
test.overlay > test.unit_test
|
||||
@@ -135,7 +114,6 @@ test.peerfinder > xrpld.core
|
||||
test.peerfinder > xrpld.peerfinder
|
||||
test.peerfinder > xrpl.protocol
|
||||
test.protocol > test.toplevel
|
||||
test.protocol > test.unit_test
|
||||
test.protocol > xrpl.basics
|
||||
test.protocol > xrpl.json
|
||||
test.protocol > xrpl.protocol
|
||||
@@ -151,11 +129,8 @@ test.rpc > xrpld.core
|
||||
test.rpc > xrpld.overlay
|
||||
test.rpc > xrpld.rpc
|
||||
test.rpc > xrpl.json
|
||||
test.rpc > xrpl.ledger
|
||||
test.rpc > xrpl.protocol
|
||||
test.rpc > xrpl.resource
|
||||
test.rpc > xrpl.server
|
||||
test.rpc > xrpl.tx
|
||||
test.server > test.jtx
|
||||
test.server > test.toplevel
|
||||
test.server > test.unit_test
|
||||
@@ -173,65 +148,43 @@ test.shamap > xrpl.shamap
|
||||
test.toplevel > test.csf
|
||||
test.toplevel > xrpl.json
|
||||
test.unit_test > xrpl.basics
|
||||
test.unit_test > xrpl.protocol
|
||||
tests.libxrpl > xrpl.basics
|
||||
tests.libxrpl > xrpl.json
|
||||
tests.libxrpl > xrpl.net
|
||||
tests.libxrpl > xrpl.protocol
|
||||
tests.libxrpl > xrpl.protocol_autogen
|
||||
xrpl.conditions > xrpl.basics
|
||||
xrpl.conditions > xrpl.protocol
|
||||
xrpl.core > xrpl.basics
|
||||
xrpl.core > xrpl.json
|
||||
xrpl.core > xrpl.ledger
|
||||
xrpl.core > xrpl.protocol
|
||||
xrpl.json > xrpl.basics
|
||||
xrpl.ledger > xrpl.basics
|
||||
xrpl.ledger > xrpl.protocol
|
||||
xrpl.ledger > xrpl.server
|
||||
xrpl.ledger > xrpl.shamap
|
||||
xrpl.net > xrpl.basics
|
||||
xrpl.nodestore > xrpl.basics
|
||||
xrpl.nodestore > xrpl.protocol
|
||||
xrpl.protocol > xrpl.basics
|
||||
xrpl.protocol > xrpl.json
|
||||
xrpl.protocol_autogen > xrpl.json
|
||||
xrpl.protocol_autogen > xrpl.protocol
|
||||
xrpl.rdb > xrpl.basics
|
||||
xrpl.rdb > xrpl.core
|
||||
xrpl.rdb > xrpl.protocol
|
||||
xrpl.resource > xrpl.basics
|
||||
xrpl.resource > xrpl.json
|
||||
xrpl.resource > xrpl.protocol
|
||||
xrpl.server > xrpl.basics
|
||||
xrpl.server > xrpl.core
|
||||
xrpl.server > xrpl.json
|
||||
xrpl.server > xrpl.protocol
|
||||
xrpl.server > xrpl.rdb
|
||||
xrpl.server > xrpl.resource
|
||||
xrpl.server > xrpl.shamap
|
||||
xrpl.shamap > xrpl.basics
|
||||
xrpl.shamap > xrpl.nodestore
|
||||
xrpl.shamap > xrpl.protocol
|
||||
xrpl.tx > xrpl.basics
|
||||
xrpl.tx > xrpl.core
|
||||
xrpl.tx > xrpl.ledger
|
||||
xrpl.tx > 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.core
|
||||
xrpld.app > xrpl.json
|
||||
xrpld.app > xrpl.ledger
|
||||
xrpld.app > xrpl.net
|
||||
xrpld.app > xrpl.nodestore
|
||||
xrpld.app > xrpl.protocol
|
||||
xrpld.app > xrpl.rdb
|
||||
xrpld.app > xrpl.resource
|
||||
xrpld.app > xrpl.server
|
||||
xrpld.app > xrpl.shamap
|
||||
xrpld.app > xrpl.tx
|
||||
xrpld.conditions > xrpl.basics
|
||||
xrpld.conditions > xrpl.protocol
|
||||
xrpld.consensus > xrpl.basics
|
||||
xrpld.consensus > xrpl.json
|
||||
xrpld.consensus > xrpl.protocol
|
||||
@@ -240,21 +193,17 @@ xrpld.core > xrpl.core
|
||||
xrpld.core > xrpl.json
|
||||
xrpld.core > xrpl.net
|
||||
xrpld.core > xrpl.protocol
|
||||
xrpld.core > xrpl.rdb
|
||||
xrpld.overlay > xrpl.basics
|
||||
xrpld.overlay > xrpl.core
|
||||
xrpld.overlay > xrpld.core
|
||||
xrpld.overlay > xrpld.peerfinder
|
||||
xrpld.overlay > xrpl.json
|
||||
xrpld.overlay > xrpl.protocol
|
||||
xrpld.overlay > xrpl.rdb
|
||||
xrpld.overlay > xrpl.resource
|
||||
xrpld.overlay > xrpl.server
|
||||
xrpld.overlay > xrpl.tx
|
||||
xrpld.peerfinder > xrpl.basics
|
||||
xrpld.peerfinder > xrpld.core
|
||||
xrpld.peerfinder > xrpl.protocol
|
||||
xrpld.peerfinder > xrpl.rdb
|
||||
xrpld.perflog > xrpl.basics
|
||||
xrpld.perflog > xrpl.core
|
||||
xrpld.perflog > xrpld.rpc
|
||||
@@ -267,8 +216,6 @@ xrpld.rpc > xrpl.ledger
|
||||
xrpld.rpc > xrpl.net
|
||||
xrpld.rpc > xrpl.nodestore
|
||||
xrpld.rpc > xrpl.protocol
|
||||
xrpld.rpc > xrpl.rdb
|
||||
xrpld.rpc > xrpl.resource
|
||||
xrpld.rpc > xrpl.server
|
||||
xrpld.rpc > xrpl.tx
|
||||
xrpld.shamap > xrpl.shamap
|
||||
|
||||
4
.github/scripts/strategy-matrix/generate.py
vendored
4
.github/scripts/strategy-matrix/generate.py
vendored
@@ -55,7 +55,7 @@ def generate_strategy_matrix(all: bool, config: Config) -> list:
|
||||
# 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/amd64, enable voidstar.
|
||||
# - 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.
|
||||
@@ -78,7 +78,7 @@ def generate_strategy_matrix(all: bool, config: Config) -> list:
|
||||
if (
|
||||
f"{os['compiler_name']}-{os['compiler_version']}" == "clang-16"
|
||||
and build_type == "Debug"
|
||||
and architecture["platform"] == "linux/amd64"
|
||||
and architecture["platform"] == "linux/arm64"
|
||||
):
|
||||
cmake_args = f"-Dvoidstar=ON {cmake_args}"
|
||||
skip = False
|
||||
|
||||
13
.github/workflows/check-pr-commits.yml
vendored
13
.github/workflows/check-pr-commits.yml
vendored
@@ -1,13 +0,0 @@
|
||||
name: Check PR commits
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
|
||||
# The action needs to have write permissions to post comments on the PR.
|
||||
permissions:
|
||||
contents: read
|
||||
pull-requests: write
|
||||
|
||||
jobs:
|
||||
check_commits:
|
||||
uses: XRPLF/actions/.github/workflows/check-pr-commits.yml@481048b78b94ac3343d1292b4ef125a813879f2b
|
||||
14
.github/workflows/check-pr-title.yml
vendored
14
.github/workflows/check-pr-title.yml
vendored
@@ -1,14 +0,0 @@
|
||||
name: Check PR title
|
||||
|
||||
on:
|
||||
merge_group:
|
||||
types:
|
||||
- checks_requested
|
||||
pull_request:
|
||||
types: [opened, edited, reopened, synchronize, ready_for_review]
|
||||
branches: [develop]
|
||||
|
||||
jobs:
|
||||
check_title:
|
||||
if: ${{ github.event.pull_request.draft != true }}
|
||||
uses: XRPLF/actions/.github/workflows/check-pr-title.yml@e2c7f400d1e85ae65dad552fd425169fbacca4a3
|
||||
24
.github/workflows/on-pr.yml
vendored
24
.github/workflows/on-pr.yml
vendored
@@ -33,7 +33,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
- name: Determine changed files
|
||||
# This step checks whether any files have changed that should
|
||||
# cause the next jobs to run. We do it this way rather than
|
||||
@@ -46,7 +46,7 @@ jobs:
|
||||
# that Github considers any skipped jobs to have passed, and in
|
||||
# turn the required checks as well.
|
||||
id: changes
|
||||
uses: tj-actions/changed-files@22103cc46bda19c2b464ffe86db46df6922fd323 # v47.0.5
|
||||
uses: tj-actions/changed-files@ed68ef82c095e0d48ec87eccea555d944a631a4c # v46.0.5
|
||||
with:
|
||||
files: |
|
||||
# These paths are unique to `on-pr.yml`.
|
||||
@@ -65,12 +65,9 @@ jobs:
|
||||
.github/workflows/reusable-build.yml
|
||||
.github/workflows/reusable-build-test-config.yml
|
||||
.github/workflows/reusable-build-test.yml
|
||||
.github/workflows/reusable-clang-tidy.yml
|
||||
.github/workflows/reusable-clang-tidy-files.yml
|
||||
.github/workflows/reusable-strategy-matrix.yml
|
||||
.github/workflows/reusable-test.yml
|
||||
.github/workflows/reusable-upload-recipe.yml
|
||||
.clang-tidy
|
||||
.codecov.yml
|
||||
cmake/**
|
||||
conan/**
|
||||
@@ -110,17 +107,6 @@ jobs:
|
||||
if: ${{ needs.should-run.outputs.go == 'true' }}
|
||||
uses: ./.github/workflows/reusable-check-rename.yml
|
||||
|
||||
clang-tidy:
|
||||
needs: should-run
|
||||
if: ${{ needs.should-run.outputs.go == 'true' }}
|
||||
uses: ./.github/workflows/reusable-clang-tidy.yml
|
||||
permissions:
|
||||
issues: write
|
||||
contents: read
|
||||
with:
|
||||
check_only_changed: true
|
||||
create_issue_on_failure: false
|
||||
|
||||
build-test:
|
||||
needs: should-run
|
||||
if: ${{ needs.should-run.outputs.go == 'true' }}
|
||||
@@ -141,8 +127,9 @@ jobs:
|
||||
needs:
|
||||
- should-run
|
||||
- build-test
|
||||
# Only run when committing to a PR that targets a release branch.
|
||||
if: ${{ github.repository == 'XRPLF/rippled' && needs.should-run.outputs.go == 'true' && github.event_name == 'pull_request' && startsWith(github.event.pull_request.base.ref, 'release') }}
|
||||
# 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:
|
||||
remote_username: ${{ secrets.CONAN_REMOTE_USERNAME }}
|
||||
@@ -169,7 +156,6 @@ jobs:
|
||||
needs:
|
||||
- check-levelization
|
||||
- check-rename
|
||||
- clang-tidy
|
||||
- build-test
|
||||
- upload-recipe
|
||||
- notify-clio
|
||||
|
||||
5
.github/workflows/on-tag.yml
vendored
5
.github/workflows/on-tag.yml
vendored
@@ -5,7 +5,7 @@ name: Tag
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- "[0-9]+.[0-9]+.[0-9]*"
|
||||
- "v*"
|
||||
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ github.ref }}
|
||||
@@ -17,7 +17,8 @@ defaults:
|
||||
|
||||
jobs:
|
||||
upload-recipe:
|
||||
if: ${{ github.repository == 'XRPLF/rippled' }}
|
||||
# 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 }}
|
||||
|
||||
16
.github/workflows/on-trigger.yml
vendored
16
.github/workflows/on-trigger.yml
vendored
@@ -22,12 +22,9 @@ on:
|
||||
- ".github/workflows/reusable-build.yml"
|
||||
- ".github/workflows/reusable-build-test-config.yml"
|
||||
- ".github/workflows/reusable-build-test.yml"
|
||||
- ".github/workflows/reusable-clang-tidy.yml"
|
||||
- ".github/workflows/reusable-clang-tidy-files.yml"
|
||||
- ".github/workflows/reusable-strategy-matrix.yml"
|
||||
- ".github/workflows/reusable-test.yml"
|
||||
- ".github/workflows/reusable-upload-recipe.yml"
|
||||
- ".clang-tidy"
|
||||
- ".codecov.yml"
|
||||
- "cmake/**"
|
||||
- "conan/**"
|
||||
@@ -63,15 +60,6 @@ defaults:
|
||||
shell: bash
|
||||
|
||||
jobs:
|
||||
clang-tidy:
|
||||
uses: ./.github/workflows/reusable-clang-tidy.yml
|
||||
permissions:
|
||||
issues: write
|
||||
contents: read
|
||||
with:
|
||||
check_only_changed: false
|
||||
create_issue_on_failure: ${{ github.event_name == 'schedule' }}
|
||||
|
||||
build-test:
|
||||
uses: ./.github/workflows/reusable-build-test.yml
|
||||
strategy:
|
||||
@@ -92,8 +80,8 @@ jobs:
|
||||
|
||||
upload-recipe:
|
||||
needs: build-test
|
||||
# Only run when pushing to the develop branch.
|
||||
if: ${{ github.repository == 'XRPLF/rippled' && github.event_name == 'push' && github.ref == 'refs/heads/develop' }}
|
||||
# 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 }}
|
||||
|
||||
7
.github/workflows/pre-commit.yml
vendored
7
.github/workflows/pre-commit.yml
vendored
@@ -1,9 +1,6 @@
|
||||
name: Run pre-commit hooks
|
||||
|
||||
on:
|
||||
merge_group:
|
||||
types:
|
||||
- checks_requested
|
||||
pull_request:
|
||||
push:
|
||||
branches:
|
||||
@@ -14,7 +11,7 @@ on:
|
||||
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@e7896f15cc60d0da1a272c77ee5c4026b424f9c7
|
||||
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-41ec7c1" }'
|
||||
container: '{ "image": "ghcr.io/xrplf/ci/tools-rippled-pre-commit:sha-ab4d1f0" }'
|
||||
|
||||
51
.github/workflows/publish-docs.yml
vendored
51
.github/workflows/publish-docs.yml
vendored
@@ -4,18 +4,6 @@ name: Build and publish documentation
|
||||
|
||||
on:
|
||||
push:
|
||||
branches:
|
||||
- "develop"
|
||||
- "release*"
|
||||
paths:
|
||||
- ".github/workflows/publish-docs.yml"
|
||||
- "*.md"
|
||||
- "**/*.md"
|
||||
- "docs/**"
|
||||
- "include/**"
|
||||
- "src/libxrpl/**"
|
||||
- "src/xrpld/**"
|
||||
pull_request:
|
||||
paths:
|
||||
- ".github/workflows/publish-docs.yml"
|
||||
- "*.md"
|
||||
@@ -35,22 +23,17 @@ defaults:
|
||||
|
||||
env:
|
||||
BUILD_DIR: build
|
||||
# ubuntu-latest has only 2 CPUs for private repositories
|
||||
# https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for--private-repositories
|
||||
NPROC_SUBTRACT: ${{ github.event.repository.private && '1' || '2' }}
|
||||
NPROC_SUBTRACT: 2
|
||||
|
||||
jobs:
|
||||
build:
|
||||
publish:
|
||||
runs-on: ubuntu-latest
|
||||
container: ghcr.io/xrplf/ci/tools-rippled-documentation:sha-a8c7be1
|
||||
permissions:
|
||||
contents: write
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
|
||||
- name: Prepare runner
|
||||
uses: XRPLF/actions/prepare-runner@2bbc2dc1abeec7bfaa886804ab86871ac201764e
|
||||
with:
|
||||
enable_ccache: false
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
|
||||
- name: Get number of processors
|
||||
uses: XRPLF/actions/get-nproc@cf0433aa74563aead044a1e395610c96d65a37cf
|
||||
@@ -81,23 +64,9 @@ jobs:
|
||||
cmake -Donly_docs=ON ..
|
||||
cmake --build . --target docs --parallel ${BUILD_NPROC}
|
||||
|
||||
- name: Create documentation artifact
|
||||
if: ${{ github.event_name == 'push' }}
|
||||
uses: actions/upload-pages-artifact@7b1f4a764d45c48632c6b24a0339c27f5614fb0b # v4.0.0
|
||||
- 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
|
||||
with:
|
||||
path: ${{ env.BUILD_DIR }}/docs/html
|
||||
|
||||
deploy:
|
||||
if: ${{ github.event_name == 'push' }}
|
||||
needs: build
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
pages: write
|
||||
id-token: write
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deploy.outputs.page_url }}
|
||||
steps:
|
||||
- name: Deploy to GitHub Pages
|
||||
id: deploy
|
||||
uses: actions/deploy-pages@d6db90164ac5ed86f2b6aed7e0febac5b3c0c03e # v4.0.5
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
publish_dir: ${{ env.BUILD_DIR }}/docs/html
|
||||
|
||||
70
.github/workflows/reusable-build-test-config.yml
vendored
70
.github/workflows/reusable-build-test-config.yml
vendored
@@ -76,7 +76,7 @@ jobs:
|
||||
name: ${{ inputs.config_name }}
|
||||
runs-on: ${{ fromJSON(inputs.runs_on) }}
|
||||
container: ${{ inputs.image != '' && inputs.image || null }}
|
||||
timeout-minutes: ${{ inputs.sanitizers != '' && 360 || 60 }}
|
||||
timeout-minutes: 60
|
||||
env:
|
||||
# Use a namespace to keep the objects separate for each configuration.
|
||||
CCACHE_NAMESPACE: ${{ inputs.config_name }}
|
||||
@@ -101,13 +101,13 @@ jobs:
|
||||
steps:
|
||||
- name: Cleanup workspace (macOS and Windows)
|
||||
if: ${{ runner.os == 'macOS' || runner.os == 'Windows' }}
|
||||
uses: XRPLF/actions/cleanup-workspace@c7d9ce5ebb03c752a354889ecd870cadfc2b1cd4
|
||||
uses: XRPLF/actions/cleanup-workspace@cf0433aa74563aead044a1e395610c96d65a37cf
|
||||
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
|
||||
- name: Prepare runner
|
||||
uses: XRPLF/actions/prepare-runner@2bbc2dc1abeec7bfaa886804ab86871ac201764e
|
||||
uses: XRPLF/actions/prepare-runner@2cbf481018d930656e9276fcc20dc0e3a0be5b6d
|
||||
with:
|
||||
enable_ccache: ${{ inputs.ccache_enabled }}
|
||||
|
||||
@@ -166,29 +166,6 @@ jobs:
|
||||
--parallel "${BUILD_NPROC}" \
|
||||
--target "${CMAKE_TARGET}"
|
||||
|
||||
- name: Check protocol autogen files are up-to-date
|
||||
env:
|
||||
MESSAGE: |
|
||||
|
||||
The generated protocol wrapper classes are out of date.
|
||||
|
||||
This typically happens when your branch is behind develop and
|
||||
the macro files or generator scripts have changed.
|
||||
|
||||
To fix this:
|
||||
1. Update your branch from develop (merge or rebase)
|
||||
2. Build with code generation enabled (XRPL_NO_CODEGEN=OFF)
|
||||
3. Commit and push the regenerated files
|
||||
run: |
|
||||
set -e
|
||||
DIFF=$(git status --porcelain -- include/xrpl/protocol_autogen src/tests/libxrpl/protocol_autogen)
|
||||
if [ -n "${DIFF}" ]; then
|
||||
echo "::error::Generated protocol files are out of date"
|
||||
git diff -- include/xrpl/protocol_autogen src/tests/libxrpl/protocol_autogen
|
||||
echo "${MESSAGE}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Show ccache statistics
|
||||
if: ${{ inputs.ccache_enabled }}
|
||||
run: |
|
||||
@@ -199,8 +176,8 @@ jobs:
|
||||
fi
|
||||
|
||||
- name: Upload the binary (Linux)
|
||||
if: ${{ github.repository == 'XRPLF/rippled' && runner.os == 'Linux' }}
|
||||
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
|
||||
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
|
||||
@@ -227,17 +204,11 @@ jobs:
|
||||
|
||||
- name: Set sanitizer options
|
||||
if: ${{ !inputs.build_only && env.SANITIZERS_ENABLED == 'true' }}
|
||||
env:
|
||||
CONFIG_NAME: ${{ inputs.config_name }}
|
||||
run: |
|
||||
ASAN_OPTS="include=${GITHUB_WORKSPACE}/sanitizers/suppressions/runtime-asan-options.txt:suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/asan.supp"
|
||||
if [[ "${CONFIG_NAME}" == *gcc* ]]; then
|
||||
ASAN_OPTS="${ASAN_OPTS}:alloc_dealloc_mismatch=0"
|
||||
fi
|
||||
echo "ASAN_OPTIONS=${ASAN_OPTS}" >> ${GITHUB_ENV}
|
||||
echo "TSAN_OPTIONS=include=${GITHUB_WORKSPACE}/sanitizers/suppressions/runtime-tsan-options.txt:suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/tsan.supp" >> ${GITHUB_ENV}
|
||||
echo "UBSAN_OPTIONS=include=${GITHUB_WORKSPACE}/sanitizers/suppressions/runtime-ubsan-options.txt:suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/ubsan.supp" >> ${GITHUB_ENV}
|
||||
echo "LSAN_OPTIONS=include=${GITHUB_WORKSPACE}/sanitizers/suppressions/runtime-lsan-options.txt:suppressions=${GITHUB_WORKSPACE}/sanitizers/suppressions/lsan.supp" >> ${GITHUB_ENV}
|
||||
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 }}
|
||||
@@ -258,23 +229,8 @@ jobs:
|
||||
env:
|
||||
BUILD_NPROC: ${{ steps.nproc.outputs.nproc }}
|
||||
run: |
|
||||
set -o pipefail
|
||||
# Coverage builds are slower due to instrumentation; use fewer parallel jobs to avoid flakiness
|
||||
[ "$COVERAGE_ENABLED" = "true" ] && BUILD_NPROC=$(( BUILD_NPROC - 2 ))
|
||||
./xrpld --unittest --unittest-jobs "${BUILD_NPROC}" 2>&1 | tee unittest.log
|
||||
./xrpld --unittest --unittest-jobs "${BUILD_NPROC}"
|
||||
|
||||
- name: Show test failure summary
|
||||
if: ${{ failure() && !inputs.build_only }}
|
||||
working-directory: ${{ runner.os == 'Windows' && format('{0}/{1}', env.BUILD_DIR, inputs.build_type) || env.BUILD_DIR }}
|
||||
run: |
|
||||
if [ ! -f unittest.log ]; then
|
||||
echo "unittest.log not found; embedded tests may not have run."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if ! grep -E "failed" unittest.log; then
|
||||
echo "Log present but no failure lines found in unittest.log."
|
||||
fi
|
||||
- name: Debug failure (Linux)
|
||||
if: ${{ failure() && runner.os == 'Linux' && !inputs.build_only }}
|
||||
run: |
|
||||
@@ -297,8 +253,8 @@ jobs:
|
||||
--target coverage
|
||||
|
||||
- name: Upload coverage report
|
||||
if: ${{ github.repository == 'XRPLF/rippled' && !inputs.build_only && env.COVERAGE_ENABLED == 'true' }}
|
||||
uses: codecov/codecov-action@1af58845a975a7985b0beb0cbe6fbbb71a41dbad # v5.5.3
|
||||
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
|
||||
|
||||
@@ -18,9 +18,9 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
- name: Check levelization
|
||||
run: python .github/scripts/levelization/generate.py
|
||||
run: .github/scripts/levelization/generate.sh
|
||||
- name: Check for differences
|
||||
env:
|
||||
MESSAGE: |
|
||||
@@ -32,7 +32,7 @@ jobs:
|
||||
removed from loops.txt, it's probably an improvement, while if
|
||||
something was added, it's probably a regression.
|
||||
|
||||
Run '.github/scripts/levelization/generate.py' in your repo, commit
|
||||
Run '.github/scripts/levelization/generate.sh' in your repo, commit
|
||||
and push the changes. See .github/scripts/levelization/README.md for
|
||||
more info.
|
||||
run: |
|
||||
|
||||
2
.github/workflows/reusable-check-rename.yml
vendored
2
.github/workflows/reusable-check-rename.yml
vendored
@@ -18,7 +18,7 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
- name: Check definitions
|
||||
run: .github/scripts/rename/definitions.sh .
|
||||
- name: Check copyright notices
|
||||
|
||||
162
.github/workflows/reusable-clang-tidy-files.yml
vendored
162
.github/workflows/reusable-clang-tidy-files.yml
vendored
@@ -1,162 +0,0 @@
|
||||
name: Run clang-tidy on files
|
||||
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
files:
|
||||
description: "List of files to check (empty means check all files)"
|
||||
type: string
|
||||
default: ""
|
||||
create_issue_on_failure:
|
||||
description: "Whether to create an issue if the check failed"
|
||||
type: boolean
|
||||
default: false
|
||||
|
||||
defaults:
|
||||
run:
|
||||
shell: bash
|
||||
|
||||
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
|
||||
BUILD_TYPE: Release
|
||||
|
||||
jobs:
|
||||
run-clang-tidy:
|
||||
name: Run clang tidy
|
||||
runs-on: ["self-hosted", "Linux", "X64", "heavy"]
|
||||
container: "ghcr.io/xrplf/ci/debian-trixie:clang-21-sha-53033a2"
|
||||
permissions:
|
||||
issues: write
|
||||
contents: read
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
|
||||
- name: Prepare runner
|
||||
uses: XRPLF/actions/prepare-runner@2bbc2dc1abeec7bfaa886804ab86871ac201764e
|
||||
with:
|
||||
enable_ccache: false
|
||||
|
||||
- name: Print build environment
|
||||
uses: ./.github/actions/print-env
|
||||
|
||||
- name: Get number of processors
|
||||
uses: XRPLF/actions/get-nproc@cf0433aa74563aead044a1e395610c96d65a37cf
|
||||
id: nproc
|
||||
|
||||
- name: Setup Conan
|
||||
uses: ./.github/actions/setup-conan
|
||||
|
||||
- name: Build dependencies
|
||||
uses: ./.github/actions/build-deps
|
||||
with:
|
||||
build_nproc: ${{ steps.nproc.outputs.nproc }}
|
||||
build_type: ${{ env.BUILD_TYPE }}
|
||||
log_verbosity: verbose
|
||||
|
||||
- name: Configure CMake
|
||||
working-directory: ${{ env.BUILD_DIR }}
|
||||
run: |
|
||||
cmake \
|
||||
-G 'Ninja' \
|
||||
-DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake \
|
||||
-DCMAKE_BUILD_TYPE="${BUILD_TYPE}" \
|
||||
-Dtests=ON \
|
||||
-Dwerr=ON \
|
||||
-Dxrpld=ON \
|
||||
..
|
||||
|
||||
# clang-tidy needs headers generated from proto files
|
||||
- name: Build libxrpl.libpb
|
||||
working-directory: ${{ env.BUILD_DIR }}
|
||||
run: |
|
||||
ninja -j ${{ steps.nproc.outputs.nproc }} xrpl.libpb
|
||||
|
||||
- name: Run clang tidy
|
||||
id: run_clang_tidy
|
||||
continue-on-error: true
|
||||
env:
|
||||
TARGETS: ${{ inputs.files != '' && inputs.files || 'src tests' }}
|
||||
run: |
|
||||
run-clang-tidy -j ${{ steps.nproc.outputs.nproc }} -p "${BUILD_DIR}" ${TARGETS} 2>&1 | tee clang-tidy-output.txt
|
||||
|
||||
- name: Upload clang-tidy output
|
||||
if: steps.run_clang_tidy.outcome != 'success'
|
||||
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
|
||||
with:
|
||||
name: clang-tidy-results
|
||||
path: clang-tidy-output.txt
|
||||
retention-days: 30
|
||||
|
||||
- name: Create an issue
|
||||
if: steps.run_clang_tidy.outcome != 'success' && inputs.create_issue_on_failure
|
||||
id: create_issue
|
||||
shell: bash
|
||||
env:
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
run: |
|
||||
# Prepare issue body with clang-tidy output
|
||||
cat > issue.md <<EOF
|
||||
## Clang-tidy Check Failed
|
||||
|
||||
**Workflow:** ${{ github.workflow }}
|
||||
**Run ID:** ${{ github.run_id }}
|
||||
**Commit:** ${{ github.sha }}
|
||||
**Branch/Ref:** ${{ github.ref }}
|
||||
**Triggered by:** ${{ github.actor }}
|
||||
|
||||
### Clang-tidy Output:
|
||||
\`\`\`
|
||||
EOF
|
||||
|
||||
# Append clang-tidy output (filter for errors and warnings)
|
||||
if [ -f clang-tidy-output.txt ]; then
|
||||
# Extract lines containing 'error:', 'warning:', or 'note:'
|
||||
grep -E '(error:|warning:|note:)' clang-tidy-output.txt > filtered-output.txt || true
|
||||
|
||||
# If filtered output is empty, use original (might be a different error format)
|
||||
if [ ! -s filtered-output.txt ]; then
|
||||
cp clang-tidy-output.txt filtered-output.txt
|
||||
fi
|
||||
|
||||
# Truncate if too large
|
||||
head -c 60000 filtered-output.txt >> issue.md
|
||||
if [ "$(wc -c < filtered-output.txt)" -gt 60000 ]; then
|
||||
echo "" >> issue.md
|
||||
echo "... (output truncated, see artifacts for full output)" >> issue.md
|
||||
fi
|
||||
|
||||
rm filtered-output.txt
|
||||
else
|
||||
echo "No output file found" >> issue.md
|
||||
fi
|
||||
|
||||
cat >> issue.md <<EOF
|
||||
\`\`\`
|
||||
|
||||
**Workflow run:** ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
|
||||
|
||||
---
|
||||
*This issue was automatically created by the clang-tidy workflow.*
|
||||
EOF
|
||||
|
||||
# Create the issue
|
||||
gh issue create \
|
||||
--label "Bug,Clang-tidy" \
|
||||
--title "Clang-tidy check failed" \
|
||||
--body-file ./issue.md \
|
||||
> create_issue.log
|
||||
|
||||
created_issue="$(sed 's|.*/||' create_issue.log)"
|
||||
echo "created_issue=$created_issue" >> $GITHUB_OUTPUT
|
||||
echo "Created issue #$created_issue"
|
||||
|
||||
rm -f create_issue.log issue.md clang-tidy-output.txt
|
||||
|
||||
- name: Fail the workflow if clang-tidy failed
|
||||
if: steps.run_clang_tidy.outcome != 'success'
|
||||
run: |
|
||||
echo "Clang-tidy check failed!"
|
||||
exit 1
|
||||
55
.github/workflows/reusable-clang-tidy.yml
vendored
55
.github/workflows/reusable-clang-tidy.yml
vendored
@@ -1,55 +0,0 @@
|
||||
name: Clang-tidy check
|
||||
|
||||
on:
|
||||
workflow_call:
|
||||
inputs:
|
||||
check_only_changed:
|
||||
description: "Check only changed files in PR. If false, checks all files in the repository."
|
||||
type: boolean
|
||||
default: false
|
||||
create_issue_on_failure:
|
||||
description: "Whether to create an issue if the check failed"
|
||||
type: boolean
|
||||
default: false
|
||||
|
||||
defaults:
|
||||
run:
|
||||
shell: bash
|
||||
|
||||
jobs:
|
||||
determine-files:
|
||||
name: Determine files to check
|
||||
if: ${{ inputs.check_only_changed }}
|
||||
runs-on: ubuntu-latest
|
||||
outputs:
|
||||
clang_tidy_config_changed: ${{ steps.changed_clang_tidy.outputs.any_changed }}
|
||||
any_cpp_changed: ${{ steps.changed_files.outputs.any_changed }}
|
||||
all_changed_files: ${{ steps.changed_files.outputs.all_changed_files }}
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
|
||||
- name: Get changed C++ files
|
||||
id: changed_files
|
||||
uses: tj-actions/changed-files@22103cc46bda19c2b464ffe86db46df6922fd323 # v47.0.5
|
||||
with:
|
||||
files: |
|
||||
**/*.cpp
|
||||
**/*.h
|
||||
**/*.ipp
|
||||
separator: " "
|
||||
|
||||
- name: Get changed clang-tidy configuration
|
||||
id: changed_clang_tidy
|
||||
uses: tj-actions/changed-files@22103cc46bda19c2b464ffe86db46df6922fd323 # v47.0.5
|
||||
with:
|
||||
files: |
|
||||
.clang-tidy
|
||||
|
||||
run-clang-tidy:
|
||||
needs: [determine-files]
|
||||
if: ${{ always() && !cancelled() && (!inputs.check_only_changed || needs.determine-files.outputs.any_cpp_changed == 'true' || needs.determine-files.outputs.clang_tidy_config_changed == 'true') }}
|
||||
uses: ./.github/workflows/reusable-clang-tidy-files.yml
|
||||
with:
|
||||
files: ${{ needs.determine-files.outputs.clang_tidy_config_changed == 'true' && '' || (inputs.check_only_changed && needs.determine-files.outputs.all_changed_files || '') }}
|
||||
create_issue_on_failure: ${{ inputs.create_issue_on_failure }}
|
||||
@@ -29,10 +29,10 @@ jobs:
|
||||
matrix: ${{ steps.generate.outputs.matrix }}
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
|
||||
- name: Set up Python
|
||||
uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
|
||||
uses: actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065 # v5.6.0
|
||||
with:
|
||||
python-version: 3.13
|
||||
|
||||
|
||||
14
.github/workflows/reusable-upload-recipe.yml
vendored
14
.github/workflows/reusable-upload-recipe.yml
vendored
@@ -43,7 +43,7 @@ jobs:
|
||||
container: ghcr.io/xrplf/ci/ubuntu-noble:gcc-13-sha-5dd7158
|
||||
steps:
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
|
||||
- name: Generate build version number
|
||||
id: version
|
||||
@@ -69,30 +69,24 @@ jobs:
|
||||
conan export . --version=${{ steps.version.outputs.version }}
|
||||
conan upload --confirm --check --remote="${REMOTE_NAME}" xrpl/${{ steps.version.outputs.version }}
|
||||
|
||||
# When this workflow is triggered by a push event, it will always be when merging into the
|
||||
# 'develop' branch, see on-trigger.yml.
|
||||
- name: Upload Conan recipe (develop)
|
||||
if: ${{ github.event_name == 'push' }}
|
||||
if: ${{ github.ref == 'refs/heads/develop' }}
|
||||
env:
|
||||
REMOTE_NAME: ${{ inputs.remote_name }}
|
||||
run: |
|
||||
conan export . --version=develop
|
||||
conan upload --confirm --check --remote="${REMOTE_NAME}" xrpl/develop
|
||||
|
||||
# When this workflow is triggered by a pull request event, it will always be when merging into
|
||||
# one of the 'release' branches, see on-pr.yml.
|
||||
- name: Upload Conan recipe (rc)
|
||||
if: ${{ github.event_name == 'pull_request' }}
|
||||
if: ${{ startsWith(github.ref, 'refs/heads/release') }}
|
||||
env:
|
||||
REMOTE_NAME: ${{ inputs.remote_name }}
|
||||
run: |
|
||||
conan export . --version=rc
|
||||
conan upload --confirm --check --remote="${REMOTE_NAME}" xrpl/rc
|
||||
|
||||
# When this workflow is triggered by a push event, it will always be when tagging a final
|
||||
# release, see on-tag.yml.
|
||||
- name: Upload Conan recipe (release)
|
||||
if: ${{ startsWith(github.ref, 'refs/tags/') }}
|
||||
if: ${{ github.event_name == 'tag' }}
|
||||
env:
|
||||
REMOTE_NAME: ${{ inputs.remote_name }}
|
||||
run: |
|
||||
|
||||
10
.github/workflows/upload-conan-deps.yml
vendored
10
.github/workflows/upload-conan-deps.yml
vendored
@@ -64,13 +64,13 @@ jobs:
|
||||
steps:
|
||||
- name: Cleanup workspace (macOS and Windows)
|
||||
if: ${{ runner.os == 'macOS' || runner.os == 'Windows' }}
|
||||
uses: XRPLF/actions/cleanup-workspace@c7d9ce5ebb03c752a354889ecd870cadfc2b1cd4
|
||||
uses: XRPLF/actions/cleanup-workspace@cf0433aa74563aead044a1e395610c96d65a37cf
|
||||
|
||||
- name: Checkout repository
|
||||
uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
||||
uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
|
||||
|
||||
- name: Prepare runner
|
||||
uses: XRPLF/actions/prepare-runner@2bbc2dc1abeec7bfaa886804ab86871ac201764e
|
||||
uses: XRPLF/actions/prepare-runner@2cbf481018d930656e9276fcc20dc0e3a0be5b6d
|
||||
with:
|
||||
enable_ccache: false
|
||||
|
||||
@@ -103,11 +103,11 @@ jobs:
|
||||
sanitizers: ${{ matrix.sanitizers }}
|
||||
|
||||
- name: Log into Conan remote
|
||||
if: ${{ github.repository == 'XRPLF/rippled' && (github.event_name == 'push' || github.event_name == 'workflow_dispatch') }}
|
||||
if: ${{ github.repository_owner == 'XRPLF' && (github.event_name == 'push' || github.event_name == 'workflow_dispatch') }}
|
||||
run: conan remote login "${CONAN_REMOTE_NAME}" "${{ secrets.CONAN_REMOTE_USERNAME }}" --password "${{ secrets.CONAN_REMOTE_PASSWORD }}"
|
||||
|
||||
- name: Upload Conan packages
|
||||
if: ${{ github.repository == 'XRPLF/rippled' && (github.event_name == 'push' || github.event_name == 'workflow_dispatch') }}
|
||||
if: ${{ github.repository_owner == 'XRPLF' && (github.event_name == 'push' || github.event_name == 'workflow_dispatch') }}
|
||||
env:
|
||||
FORCE_OPTION: ${{ github.event.inputs.force_upload == 'true' && '--force' || '' }}
|
||||
run: conan upload "*" --remote="${CONAN_REMOTE_NAME}" --confirm ${FORCE_OPTION}
|
||||
|
||||
14
.gitignore
vendored
14
.gitignore
vendored
@@ -42,9 +42,6 @@ gmon.out
|
||||
# Locally patched Conan recipes
|
||||
external/conan-center-index/
|
||||
|
||||
# Local conan directory
|
||||
.conan
|
||||
|
||||
# XCode IDE.
|
||||
*.pbxuser
|
||||
!default.pbxuser
|
||||
@@ -72,14 +69,3 @@ DerivedData
|
||||
|
||||
# AI tools.
|
||||
/.augment
|
||||
/.claude
|
||||
/CLAUDE.md
|
||||
|
||||
# Python
|
||||
__pycache__
|
||||
|
||||
# Direnv's directory
|
||||
/.direnv
|
||||
|
||||
# clangd cache
|
||||
/.cache
|
||||
|
||||
@@ -13,8 +13,6 @@ repos:
|
||||
- repo: https://github.com/pre-commit/pre-commit-hooks
|
||||
rev: 3e8a8703264a2f4a69428a0aa4dcb512790b2c8c # frozen: v6.0.0
|
||||
hooks:
|
||||
- id: check-added-large-files
|
||||
args: [--maxkb=400, --enforce-all]
|
||||
- id: trailing-whitespace
|
||||
- id: end-of-file-fixer
|
||||
- id: mixed-line-ending
|
||||
@@ -22,33 +20,33 @@ repos:
|
||||
args: [--assume-in-merge]
|
||||
|
||||
- repo: https://github.com/pre-commit/mirrors-clang-format
|
||||
rev: cd481d7b0bfb5c7b3090c21846317f9a8262e891 # frozen: v22.1.0
|
||||
rev: 7d85583be209cb547946c82fbe51f4bc5dd1d017 # frozen: v18.1.8
|
||||
hooks:
|
||||
- id: clang-format
|
||||
args: [--style=file]
|
||||
"types_or": [c++, c, proto]
|
||||
exclude: ^include/xrpl/protocol_autogen/(transactions|ledger_entries)/
|
||||
|
||||
- repo: https://github.com/BlankSpruce/gersemi
|
||||
rev: 0.26.0
|
||||
- repo: https://github.com/cheshirekow/cmake-format-precommit
|
||||
rev: e2c2116d86a80e72e7146a06e68b7c228afc6319 # frozen: v0.6.13
|
||||
hooks:
|
||||
- id: gersemi
|
||||
- id: cmake-format
|
||||
additional_dependencies: [PyYAML]
|
||||
|
||||
- repo: https://github.com/rbubley/mirrors-prettier
|
||||
rev: c2bc67fe8f8f549cc489e00ba8b45aa18ee713b1 # frozen: v3.8.1
|
||||
rev: 5ba47274f9b181bce26a5150a725577f3c336011 # frozen: v3.6.2
|
||||
hooks:
|
||||
- id: prettier
|
||||
|
||||
- repo: https://github.com/psf/black-pre-commit-mirror
|
||||
rev: ea488cebbfd88a5f50b8bd95d5c829d0bb76feb8 # frozen: 26.1.0
|
||||
rev: 831207fd435b47aeffdf6af853097e64322b4d44 # frozen: v25.12.0
|
||||
hooks:
|
||||
- id: black
|
||||
|
||||
- repo: https://github.com/streetsidesoftware/cspell-cli
|
||||
rev: a42085ade523f591dca134379a595e7859986445 # frozen: v9.7.0
|
||||
rev: 1cfa010f078c354f3ffb8413616280cc28f5ba21 # frozen: v9.4.0
|
||||
hooks:
|
||||
- id: cspell # Spell check changed files
|
||||
exclude: (.config/cspell.config.yaml|^include/xrpl/protocol_autogen/(transactions|ledger_entries)/)
|
||||
exclude: .config/cspell.config.yaml
|
||||
- id: cspell # Spell check the commit message
|
||||
name: check commit message spelling
|
||||
args:
|
||||
@@ -59,27 +57,8 @@ repos:
|
||||
- .git/COMMIT_EDITMSG
|
||||
stages: [commit-msg]
|
||||
|
||||
- repo: local
|
||||
hooks:
|
||||
- id: nix-fmt
|
||||
name: Format Nix files
|
||||
entry: |
|
||||
bash -c '
|
||||
if command -v nix &> /dev/null || [ "$GITHUB_ACTIONS" = "true" ]; then
|
||||
nix --extra-experimental-features "nix-command flakes" fmt "$@"
|
||||
else
|
||||
echo "Skipping nix-fmt: nix not installed and not in GitHub Actions"
|
||||
exit 0
|
||||
fi
|
||||
' --
|
||||
language: system
|
||||
types:
|
||||
- nix
|
||||
pass_filenames: true
|
||||
|
||||
exclude: |
|
||||
(?x)^(
|
||||
external/.*|
|
||||
.github/scripts/levelization/results/.*\.txt|
|
||||
src/tests/libxrpl/protocol_autogen/(transactions|ledger_entries)/.*
|
||||
.github/scripts/levelization/results/.*\.txt
|
||||
)$
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user