rippled
Loading...
Searching...
No Matches
instrumentation.h
1#ifndef BEAST_UTILITY_INSTRUMENTATION_H_INCLUDED
2#define BEAST_UTILITY_INSTRUMENTATION_H_INCLUDED
3
4#include <cassert>
5
6#ifdef ENABLE_VOIDSTAR
7#ifdef NDEBUG
8#error "Antithesis instrumentation requires Debug build"
9#endif
10#include <antithesis_sdk.h>
11#else
12// Macros below are copied from antithesis_sdk.h and slightly simplified
13// The duplication is because Visual Studio 2019 cannot compile that header
14// even with the option -Zc:__cplusplus added.
15#define ALWAYS(cond, message, ...) assert((message) && (cond))
16#define ALWAYS_OR_UNREACHABLE(cond, message, ...) assert((message) && (cond))
17#define SOMETIMES(cond, message, ...)
18#define REACHABLE(message, ...)
19#define UNREACHABLE(message, ...) assert((message) && false)
20#endif
21
22#define XRPL_ASSERT ALWAYS_OR_UNREACHABLE
23#define XRPL_ASSERT_PARTS(cond, function, description, ...) \
24 XRPL_ASSERT(cond, function " : " description)
25
26// How to use the instrumentation macros:
27//
28// * XRPL_ASSERT if cond must be true but the line might not be reached during
29// fuzzing. Same like `assert` in normal use.
30// * XRPL_ASSERT_PARTS is for convenience, and works like XRPL_ASSERT, but
31// splits the message param into "function" and "description", then joins
32// them with " : " before passing to XRPL_ASSERT.
33// * ALWAYS if cond must be true _and_ the line must be reached during fuzzing.
34// Same like `assert` in normal use.
35// * REACHABLE if the line must be reached during fuzzing
36// * SOMETIMES a hint for the fuzzer to try to make the cond true
37// * UNREACHABLE if the line must not be reached (in fuzzing or in normal use).
38// Same like `assert(false)` in normal use.
39//
40// NOTE: XRPL_ASSERT has similar semantics as C `assert` macro, with only minor
41// differences:
42// * XRPL_ASSERT must have an unique name (naming convention in CONTRIBUTING.md)
43// * during fuzzing, the program will continue execution past failed XRPL_ASSERT
44//
45// We continue to use regular C `assert` inside unit tests and inside constexpr
46// functions.
47//
48// NOTE: UNREACHABLE does *not* have the same semantics as std::unreachable.
49// The program will continue execution past an UNREACHABLE in a Release build
50// and during fuzzing (similar to failed XRPL_ASSERT).
51// Also, the naming convention in UNREACHABLE is subtly different from other
52// instrumentation macros - its name describes the condition which was _not_
53// meant to happen, while name in other macros describes the condition that is
54// meant to happen (e.g. as in "assert that this happens").
55
56#endif