Merge branch develop

.github/workflows/clang-format.yml

@@ -8,7 +8,7 @@ jobs:
     env:
       CLANG_VERSION: 10
     steps:
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v3
     - name: Install clang-format
       run: |
         codename=$( lsb_release --codename --short )

.github/workflows/levelization.yml

@@ -8,7 +8,7 @@ jobs:
     env:
       CLANG_VERSION: 10
     steps:
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v3
     - name: Check levelization
       run: Builds/levelization/levelization.sh
     - name: Check for differences

.gitignore

@@ -108,3 +108,4 @@ pkg_out
 pkg
 CMakeUserPresets.json
 bld.rippled/
+.vscode

.pre-commit-config.yaml

@@ -0,0 +1,6 @@
+# .pre-commit-config.yaml
+repos:
+- repo: https://github.com/pre-commit/mirrors-clang-format
+  rev: v10.0.1
+  hooks:
+  - id: clang-format

Builds/CMake/RippledCompiler.cmake

@@ -13,7 +13,6 @@ link_libraries (Ripple::common)
 set_target_properties (common
   PROPERTIES INTERFACE_POSITION_INDEPENDENT_CODE ON)
 set(CMAKE_CXX_EXTENSIONS OFF)
-target_compile_features (common INTERFACE cxx_std_17)
 target_compile_definitions (common
   INTERFACE
     $<$<CONFIG:Debug>:DEBUG _DEBUG>
@@ -108,6 +107,7 @@ else ()
       -Wno-char-subscripts
       -Wno-format
       -Wno-unused-local-typedefs
+      -fstack-protector
       $<$<BOOL:${is_gcc}>:
         -Wno-unused-but-set-variable
         -Wno-deprecated
@@ -120,6 +120,7 @@ else ()
   target_link_libraries (common
     INTERFACE
       -rdynamic
+      $<$<BOOL:${is_linux}>:-Wl,-z,relro,-z,now>
       # link to static libc/c++ iff:
       #   * static option set and
       #   * NOT APPLE (AppleClang does not support static libc/c++) and

Builds/containers/packaging/dpkg/build_dpkg.sh

@@ -67,6 +67,10 @@ if [ -e rippled_${RIPPLED_DPKG_FULL_VERSION}_amd64.buildinfo ] ; then
     cp rippled_${RIPPLED_DPKG_FULL_VERSION}_amd64.buildinfo ${PKG_OUTDIR}
 fi
 
+pushd ${PKG_OUTDIR}
+for f in *.ddeb; do mv -- "$f" "${f%.ddeb}.deb"; done
+popd
+
 cat rippled_${RIPPLED_DPKG_FULL_VERSION}_amd64.changes
 # extract the text in the .changes file that appears between
 #    Checksums-Sha256:  ...

Builds/containers/packaging/dpkg/debian/rules

@@ -15,12 +15,25 @@ override_dh_systemd_start:
 	dh_systemd_start --no-restart-on-upgrade
 
 override_dh_auto_configure:
+	apt install --yes gcc-11 g++-11
+	update-alternatives --install \
+		/usr/bin/gcc gcc /usr/bin/gcc-11 100 \
+		--slave /usr/bin/g++ g++ /usr/bin/g++-11 \
+		--slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-11 \
+		--slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-11 \
+		--slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-11 \
+		--slave /usr/bin/gcov gcov /usr/bin/gcov-11 \
+		--slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-dump-11 \
+		--slave /usr/bin/gcov-dump gcov-dump /usr/bin/gcov-tool-11
+	update-alternatives --set gcc /usr/bin/gcc-11
 	env
 	rm -rf bld
-
+	conan profile update settings.compiler.cppstd=20 gcc
+	conan profile update settings.compiler.version=11 gcc
 	conan export external/snappy snappy/1.1.9@
 
 	conan install . \
+		--profile gcc \
 		--install-folder bld/rippled  \
 		--build missing \
 		--build boost \
@@ -38,12 +51,14 @@ override_dh_auto_configure:
 		-B bld/rippled
 
 	conan install . \
+		--profile gcc \
 		--install-folder bld/rippled-reporting \
 		--build missing \
 		--build boost \
 		--build sqlite3 \
 		--build libuv \
 		--settings build_type=Release \
+		--settings compiler.cppstd=17 \
 		--options reporting=True
 
 	cmake -DCMAKE_TOOLCHAIN_FILE:FILEPATH=build/generators/conan_toolchain.cmake \
@@ -58,7 +73,6 @@ override_dh_auto_configure:
 
 override_dh_auto_build:
 	cmake --build bld/rippled --target rippled --target validator-keys -j${nproc}
-
 	cmake --build bld/rippled-reporting --target rippled -j${nproc}
 
 override_dh_auto_install:

CONTRIBUTING.md

@@ -1,54 +1,51 @@
 The XRP Ledger has many and diverse stakeholders, and everyone deserves
-a chance to contribute meaningful changes to the code that runs the XRPL.
+a chance to contribute meaningful changes to the code that runs the
+XRPL.
 
 # Contributing
 
-We assume you are familiar with the general practice of [making contributions
-on GitHub][1].
-This file includes only special instructions specific to this project.
+We assume you are familiar with the general practice of [making
+contributions on GitHub][1]. This file includes only special
+instructions specific to this project.
 
 
 ## Before you start
 
-All of your contributions must be developed in your personal
+In general, contributions should be developed in your personal
 [fork](https://github.com/XRPLF/rippled/fork).
-No personal branches may ever be pushed to the [main project][rippled].
-These are the only branches that may ever exist in the main project:
+
+The following branches exist in the main project repository:
 
 - `develop`: The latest set of unreleased features, and the most common
     starting point for contributions.
-- `release`: The latest release candidate.
+- `release`: The latest beta release or release candidate.
 - `master`: The latest stable release.
 - `gh-pages`: The documentation for this project, built by Doxygen.
 
-The tip of each branch must be signed.
-In order for GitHub to sign a squashed commit that it builds from your pull
-request,
-all of your commits must be signed,
-and GitHub must know your verifying key.
-Please walk through the excellent documentation from GitHub to set
-up [signature verification][signing].
+The tip of each branch must be signed. In order for GitHub to sign a
+squashed commit that it builds from your pull request, GitHub must know
+your verifying key. Please set up [signature verification][signing].
 
 [rippled]: https://github.com/XRPLF/rippled
-[signing]: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
+[signing]:
+    https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
 
 
 ## Major contributions
 
-If your contribution is a major feature or breaking change,
-then you must first write an XRP Ledger Standard (XLS) describing it.
-Go to [XRPL-Standards](https://github.com/XRPLF/XRPL-Standards/discussions),
-choose the next available standard number, and
-open a discussion with an appropriate title to propose your draft standard.
+If your contribution is a major feature or breaking change, then you
+must first write an XRP Ledger Standard (XLS) describing it. Go to
+[XRPL-Standards](https://github.com/XRPLF/XRPL-Standards/discussions),
+choose the next available standard number, and open a discussion with an
+appropriate title to propose your draft standard.
 
 When you submit a pull request, please link the corresponding XLS in the
-description.
-An XLS still in draft status is considered a work-in-progress and open for
-discussion.
-Please do not submit a pull request before allowing due time for questions,
-suggestions, and changes to the XLS draft.
-It is the responsibility of the XLS author to update the draft to match the
-final implementation when its corresponding pull request is merged.
+description. An XLS still in draft status is considered a
+work-in-progress and open for discussion. Please allow time for
+questions, suggestions, and changes to the XLS draft. It is the
+responsibility of the XLS author to update the draft to match the final
+implementation when its corresponding pull request is merged, unless the
+author delegates that responsibility to others.
 
 
 ## Before making a pull request
@@ -79,13 +76,13 @@ Header includes must be [levelized](./Builds/levelization).
 
 ## Pull requests
 
-Pull requests must target the `develop` branch.[^1]
+In general, pull requests use `develop` as the base branch.
 
-[^1]: There are exceptions to this policy for hotfixes, but no one consulting
-  this document will be in that situation.
+(Hotfixes are an exception.)
 
 Changes to pull requests must be added as new commits.
-You may **never force push a branch in a pull request** (e.g. after a rebase).
+Once code reviewers have started looking at your code, please avoid
+force-pushing a branch in a pull request.
 This preserves the ability for reviewers to filter changes since their last
 review.
 
@@ -100,8 +97,9 @@ to preserve a linear history for the `develop` branch.
 
 # Style guide
 
-This is a non-exhaustive list of recommended style guidelines.
-These are not always strictly enforced and serve as a way to keep the codebase coherent rather than a set of _thou shalt not_ commandments.
+This is a non-exhaustive list of recommended style guidelines. These are
+not always strictly enforced and serve as a way to keep the codebase
+coherent rather than a set of _thou shalt not_ commandments.
 
 
 ## Formatting
@@ -121,27 +119,39 @@ this:
 You can format individual files in place by running `clang-format -i <file>...`
 from any directory within this project.
 
+You can install a pre-commit hook to automatically run `clang-format` before every commit:
+```
+pip3 install pre-commit
+pre-commit install
+```
 
 ## Avoid
 
 1. Proliferation of nearly identical code.
 2. Proliferation of new files and classes.
 3. Complex inheritance and complex OOP patterns.
 4. Unmanaged memory allocation and raw pointers.
-5. Macros and non-trivial templates (unless they add significant value.)
-6. Lambda patterns (unless these add significant value.)
-7. CPU or architecture-specific code unless there is a good reason to include it, and where it is used guard it with macros and provide explanatory comments.
+5. Macros and non-trivial templates (unless they add significant value).
+6. Lambda patterns (unless these add significant value).
+7. CPU or architecture-specific code unless there is a good reason to
+   include it, and where it is used, guard it with macros and provide
+   explanatory comments.
 8. Importing new libraries unless there is a very good reason to do so.
 
 
 ## Seek to
 
 9. Extend functionality of existing code rather than creating new code.
-10. Prefer readability over terseness where important logic is concerned.
-11. Inline functions that are not used or are not likely to be used elsewhere in the codebase.
-12. Use clear and self-explanatory names for functions, variables, structs and classes.
-13. Use TitleCase for classes, structs and filenames, camelCase for function and variable names, lower case for namespaces and folders.
-14. Provide as many comments as you feel that a competent programmer would need to understand what your code does.
+10. Prefer readability over terseness where important logic is
+    concerned.
+11. Inline functions that are not used or are not likely to be used
+    elsewhere in the codebase.
+12. Use clear and self-explanatory names for functions, variables,
+    structs and classes.
+13. Use TitleCase for classes, structs and filenames, camelCase for
+    function and variable names, lower case for namespaces and folders.
+14. Provide as many comments as you feel that a competent programmer
+    would need to understand what your code does.
 
 
 # Maintainers

src/ripple/app/misc/NetworkOPs.cpp

@@ -2058,7 +2058,7 @@ NetworkOPsImp::pubServer()
                     f.em->openLedgerFeeLevel,
                     f.loadBaseServer,
                     f.em->referenceFeeLevel)
-                    .second);
+                    .value_or(ripple::muldiv_max));
 
             jvObj[jss::load_factor] = trunc32(loadFactor);
             jvObj[jss::load_factor_fee_escalation] =
@@ -2506,7 +2506,7 @@ NetworkOPsImp::getServerInfo(bool human, bool admin, bool counters)
                 escalationMetrics.openLedgerFeeLevel,
                 loadBaseServer,
                 escalationMetrics.referenceFeeLevel)
-                .second;
+                .value_or(ripple::muldiv_max);
 
         auto const loadFactor = std::max(
             safe_cast<std::uint64_t>(loadFactorServer),

src/ripple/app/misc/TxQ.h

@@ -492,7 +492,7 @@ class TxQ
             @param seriesSize Total number of transactions in the series to be
                 processed.
 
-            @return A `std::pair` as returned from @ref `mulDiv` indicating
+            @return A `std::pair` indicating
                 whether the calculation result overflows.
         */
         static std::pair<bool, FeeLevel64>
@@ -862,20 +862,15 @@ template <class T>
 XRPAmount
 toDrops(FeeLevel<T> const& level, XRPAmount baseFee)
 {
-    if (auto const drops = mulDiv(level, baseFee, TxQ::baseLevel); drops.first)
-        return drops.second;
-
-    return XRPAmount(STAmount::cMaxNativeN);
+    return mulDiv(level, baseFee, TxQ::baseLevel)
+        .value_or(XRPAmount(STAmount::cMaxNativeN));
 }
 
 inline FeeLevel64
 toFeeLevel(XRPAmount const& drops, XRPAmount const& baseFee)
 {
-    if (auto const feeLevel = mulDiv(drops, TxQ::baseLevel, baseFee);
-        feeLevel.first)
-        return feeLevel.second;
-
-    return FeeLevel64(std::numeric_limits<std::uint64_t>::max());
+    return mulDiv(drops, TxQ::baseLevel, baseFee)
+        .value_or(FeeLevel64(std::numeric_limits<std::uint64_t>::max()));
 }
 
 }  // namespace ripple

src/ripple/app/misc/impl/LoadFeeTrack.cpp

@@ -109,9 +109,9 @@ scaleFeeLoad(
 
     auto const result = mulDiv(
         fee, feeFactor, safe_cast<std::uint64_t>(feeTrack.getLoadBase()));
-    if (!result.first)
+    if (!result)
         Throw<std::overflow_error>("scaleFeeLoad");
-    return result.second;
+    return *result;
 }
 
 }  // namespace ripple