Fix: bt_value_map_borrow_entry_value(): use `@bt_pre_is_map_val`

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I48f15e9938d78245fd5f86a35935bf56fd304261

.clang-tidy: enable cppcoreguidelines-avoid-const-or-ref-data-members

Enable:

  https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines/avoid-const-or-ref-data-members.html

Set the `AllowMissingMoveFunctionsWhenCopyIsDeleted`, so it's less
verbose when you just want to delete everything.

Set `AllowSoleDefaultDtor`, because we have legitimate cases (when
defining virtual base classes) where we only define a default
destructor.  Perhaps there's a pitfall I don't see when allowing this?

Change-Id: I4a8d20c0be628ac807db4c6b52548e3b7d7ee286
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12090
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Add clang-tidy config file

Copied from:

  https://git.lttng.org/?p=lttng-tools.git;a=blob;f=.clang-tidy;h=75f559c5d961041df8e37280ef27cb0cac8cdd96;hb=20c4b46aee1a984bc558b483826c1078f24d35e9

And adapted for Babeltrace:

 - Define `BT_ASSERT` and `BT_ASSERT_DBG` as assertion macros.
 - Remove `HeaderFilterRegex`.  We might want to use this setting, but
   I'm not sure what its value would be for Babeltrace.
 - Fix a . -> , typo

Change-Id: I73f1776bc4b7cb1bdc0d5728f9a46b17157088c8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12078
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

flt.utils.muxer: use clock correlation validator

Change the clock correlation validation code in `flt.utils.muxer` to use
the clock correlation validation library.

Change-Id: I5452f530de5fb035f66da5fc6f63bba48711e503
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11991
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

flt.utils.muxer: don't reset clock expectation when seeking beginning

When seeking the beginning, there is no reason to reset the clock
expectations.  The clocks seen after a seek beginning should be
compatible with those seen before.

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I2ea587ea7b7f62ae509632836ae4364292903001
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12148
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2c: add `format_as()` functions for `Uuid` and `UuidView`

Change-Id: I6530144e78d6aa10dedb320b90a4c208aa572e9d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12138
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

tests/plugins/flt.utils.muxer: add test for clock (in)compatibility cases

Add a test for the various clock class incompatibility cases checked by
the `MsgIter::_makeSureClkClsIsExpected` method in the `flt.utils.muxer`
component class.

The scenarios are equivalent to the triggers in
`tests/lib/conds/conds-trigger.cpp`, used to test the preconditions in
the library.  Since the scenarios are equivalent, it would probably be
possible to share some code with that file, but I haven't tried it.

In essence, for each scenario, the test creates a graph where a muxer
component receives two messages with incompatible clock
configurations.  The test expects that an exception is thrown, and
checks whether the root cause contains an expected string.

Change-Id: I8bd98fa52719ab2cedb7cbb09310a560b437eb28
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12005
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

plugins/common/muxing: compare "origin is Unix epoch" property of clock classes

If two clock classes only differ by their "origin is Unix epoch"
property, they will compare equal as far as `compare_clock_classes` is
concerned.  Add a comparison for that.

Change-Id: Iecac8fd4aa3064b221291264f4fc6758e32a0943
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12067
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

plugins/common/muxing: compare stream class clock classes

When comparing two streams and all else is equal about the stream and
their classes, compare the clock classes attached to the stream classes.

My use case for this is that I'm writing a test where two source
components send a stream beginning message to a muxer components.  The
only difference between the two is the clock classes associated to the
stream classes.  Some stream classes have an associated clock class,
some don't.  In other cases, the stream classes differ only by some
properties of their clock classes.  I want to be sure that the messages
will come out of the muxer's priority heap in a stable order.

Change-Id: I113704dac4ff952573c3dd96acd33b295425a863
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12054
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

plugins/common/muxing: split `compare_clock_snapshots_and_clock_classes()`

A subsequent commit will want to re-use the code to compare two clock
classes.  Split `compare_clock_snapshots_and_clock_classes()` in two, to
make the comparing clock classes part independent from the comparing
clock snapshots part.

Change-Id: I7888d7d3d1339ccb6c27054919349745cb7875eb
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12053
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

sink.utils.counter: remove unnecessary check in counter_consume()

Given the lifecycle of a component, I'm pretty sure this condition can
never be true.  For counter_consume() to be called,
counter_graph_is_configured() must execute successfully.  If
counter_graph_is_configured() executes successfully, `counter->msg_iter`
is necessarily set.

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ibd3cbcfdeefa8d79143e39c6fb846ca5eeebd249
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12010
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

sink.utils.dummy: remove unnecessary check in dummy_consume()

Given the lifecycle of a component, I'm pretty sure this condition can
never be true.  For dummy_consume() to be called,
dummy_graph_is_configured() must execute successfully.  If
dummy_graph_is_configured() executes successfully, `dummy->msg_iter` is
necessarily set.

Change-Id: I5c11c6b76c8cb267f0185c1a35bc2f5e70826509
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12009
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

sink.utils.counter: append error cause when call to bt_message_iterator_next()` fails

Same as the previous patch, but for the counter component.

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I95f27091512aebc9d01c7b05d98955fdfdcab5da
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12008
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

sink.utils.dummy: append error cause when call to bt_message_iterator_next()` fails

I'm looking at some error stacks for a graph involving a dummy
component, and I noticed that it did not produce an error cause when
failing to consume.  I think it would be nice if it did, to avoid having
a gap in the error stack.

Change-Id: I1b7af3218f9937a21d3dee7406a2b03e122671c6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12007
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: use universal reference for `Graph::addComponent()` initialization data

I noticed it was not possible to pass data to `Graph::addComponent`
using a temporary object:

    graph->addComponent(*srcCompCls, "source-1", TestSourceData {});

My understanding of it is that the compiler does not consider the
overload with the `InitDataT&` parameter for this, because the temporary
object can't bind to the lvalue reference.

Change these methods to take forwarding references instead.

Change-Id: Icc80239812c325b777ed83e8634302a0c9d72f14
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12049
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

Fix: flt.utils.muxer: reject two different clock classes with unknown origin and no UUID

When getting a message with a clock class whose origin is unknown and
that has no UUID, the expectation of a `flt.utils.muxer` component
should be that all subsequent messages with an associated clock class
will have the exact same clock class instance.  Currently, it accepts
any other clock class instance that has an unknown origin and no UUID.

This is a change that is equivalent to what was done in commit
29e191fceb61 ("Fix: lib: strengthen clock expectation check for no Unix
epoch / no UUID case") in the library iterator code.

When first seeing a clock class with unknown origin and no UUID, make
the muxer message iterator save the clock class instance, holding a
strong reference, and ensure that all clock classes seen after are the
same instance.

Change-Id: I676471cc0c3b88a83cd0b452dee8d6b1ed549e4d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12044
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2c: add `CStringView::startsWith`

Change-Id: I4a39561085850c06adc1f6e36466fba9a2e6dfa0
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12011
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add C++ bindings around `bt_error *`

Add C++ bindings to access the error on the current thread.

 - Take the current thread error with takeCurrentThreadError(),
   returning a `UniqueConstError`.
 - Move the current thread error back with moveErrorToCurrentThread().
 - Access the error cause by iterating or subscripting
   `UniqueConstError`, which yields objects of type `ConstErrorCause` (a
   borrowed object type).
 - Access the common error cause information using methods of
   `ConstErrorCause`, including the error cause actor type.
 - Obtain a more specific error cause object with
   `ConstErrorCause::as*()`.

Change-Id: Ie18e22ef8901bc9c8d7c85432d515ca763b484c2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12006
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

lib/graph/iterator.c: fix indentation (spaces -> tabs)

Change-Id: Ic6b408ef73e54e59161dca18fe19a45285d39c22
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12123
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

lib/graph/iterator: use clock correlation validator util

Make `graph/iterator.{c,h}` use the clock correlation validator
convenience library.

 - Replace the fields of `struct bt_message_iterator` that track the
   clock expectation state with a single `struct
   bt_clock_correlation_validator` field, only present if babeltrace is
   built in dev mode.

 - Initialize `bt_message_iterator::correlation_validator` in
   create_self_component_input_port_message_iterator.  Finalize it in
   `bt_message_iterator_destroy`.

 - Replace the bulk of
   `assert_post_dev_clock_classes_are_compatible_one` with one call to
   `bt_clock_correlation_validator_validate_message`.  If the latter
   returns an error, trigger an assertion failure based on the return
   error type and associated information.

The modifications in the Makefiles (adding `dummy.cpp`) are to force
linking with the C++ compiler driver.  This is necessary, since the
`libbabeltrace2.so` library now requires some symbols from the C++
standard library (e.g. `libstdc++.so`).  The `dummy.cpp` does not
actually need to exist.  This trick is described in the automake doc
[1].

[1] https://www.gnu.org/software/automake/manual/automake.html#Libtool-Convenience-Libraries

Change-Id: I46a3a553d5e18eb6860d65d928ef33d941e9e951
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11990
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

lib/graph/iterator: don't reset clock expectation when seeking beginning

When asking an iterator to seeking the beginning, there is no reason to
reset the clock expectations.  The clocks seen after a seek beginning
should be compatible with those seen before.

Change-Id: I91d45b22c477048d92bc567a3ee26ec9641c1055
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12147
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

clock-correlation-validator: add clock correlation validation util

`lib/graph/iterator.c` and `plugins/utils/muxer/msg-iter.cpp` have
equivalent code to verify that the various clock classes they see are
correlatable.  Add a util to factor out this logic.

Since the lib is written in C and the muxer component in C++, we need
both interfaces.  I chose to write the core of the library with a proper
C++ interface (since that's the future!) and make a small C wrapper
around it.  If/when we migrate some parts of the lib to C++, we will be
able to drop this C wrapper.

Change-Id: Iab8968ef33c9f7d4e2e8e06e0942de749a090841
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11753
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add `wrap(bt_graph *)`

Change-Id: I85e6e38576d71f64a7cd8cb0139104bce98aac36
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12046
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: don't use wrap in bindings code

Using `wrap()` in bindings code causes cyclic include problems, stop
using it.

For instance, we want to add `wrap(bt_graph *)`, so `wrap.hpp` needs to
include `graph.hpp`.  But `graph.hpp` currently uses and includes
`wrap.hpp`.

Change-Id: I5b7005617ed38eb791edf5802a05a8a8dd3115fd
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12045
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: make `getSupportedMipVersions` methods take a `ConstMapValue`

The "get_supported_mip_versions" component class methods always receive
a map value.  The equivalent methods in the C++ bindings should
therefore take a `ConstMapValue.

Change-Id: Ia3ba17048337d3abb72cefa2ae88c7b3187833f2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12048
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: remove unnecessary mentions of `bt2::`

Don't use `bt2::` when already inside the `bt2` namespace.

Change-Id: I63444e141ae13b6e508d4508488fb562ae9403d7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12047
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: make `{OptionalBorrowedObject,SharedObject}::operator bool` explicit

This code doesn't really make sense (what I really wanted to do was to
compare the underlying lib pointers), but I made this mistake on more
than one occasion:

    if (someOptionalBorrowedObject == someSharedObject)

What happens is: since `operator bool` for both types is implicit, they
get implicitly converted to bool.  As a result, the condition checks if
both objects contain an object or don't contain an object.  I consider
this a pitfall, as it compiles but it is likely never what we'll want to
do.

Make `operator bool` for both types explicit to avoid that.  This is
what is done in the STL for `shared_ptr` [1] and `optional` [2].

Note that even if `operator bool` is explicit, it remains implicitly
convertible to bool in certain contexts [3], such as an if condition.

[1] https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_bool
[2] https://en.cppreference.com/w/cpp/utility/optional/operator_bool
[3] https://stackoverflow.com/questions/39995573/when-can-i-use-explicit-operator-bool-without-a-cast

Change-Id: I2b2377323ca620162442cb7f0305763c034d13d8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12043
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

flt.utils.muxer: use `streamClassDefaultClockClass()` methods

Use them where possible, as a shortcut to
`.stream().cls().defaultClockClass()`.

Change-Id: I2923f3882dfd4dde31057962a1dd41f7b9edbd9a
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11965
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add `streamClassDefaultClockClass()` methods

Add `streamClassDefaultClockClass()` methods on all relevant message
types, calling the
`bt_message_*_borrow_stream_class_default_clock_class_const` library
functions.

Change-Id: Iee1636048838d263b4407c60f8760870bd4ddb01
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11964
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests: improve debuggability of `cli/test-trace-copy.sh`

When something fails in `cli/test-trace-copy.sh`, we don't really know
why, as everything is sent to `/dev/null`.

Make the test record stderr and print it (using tap's `diag`) when
something fails.

Add the `diag_file` helper to make that easy.

Change-Id: I2eb85cd5fffb136cddf2457089681ee57c21e4f7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11963
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2c: use `ComparableWithCStringView` on `operator!=` meant for `CStringView`

I don't recall exactly when I needed this, but it occured to me once
that the `operator!=` we provide for `CStringView` was getting picked up
for some unrelated type.  It just seems dangerous to provide a generic
templated operator like that that can match literally anything.

Use the same `ComparableWithCStringView` conditions here that we use for
`operator==` just above, so that it only gets used for what it was
intended for.

Change-Id: I798f1c8195c541f6188499dcfabfe1233a95a492
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11962
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add static_assert in `CommonClockClass::uuid(const std::uint8_t *)`

Change-Id: I66399af51ab21c52e8fbc61cc61cae1b94f1e2e7
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11956
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib/conds: test clock compatibility post conditions

Add tests for the clock class compatibility post conditions in
`iterator.c`.  There is one test for each `BT_ASSERT_POST_DEV` in
`assert_post_dev_clock_classes_are_compatible_one`.

`addClockClsCompatTriggers()` adds a bunch of triggers that make a
message iterator return two messages with incompatible clock classes.
The message types that play a role in the clock compatibility checks are
"stream beginning" and "message iterator inactivity".
`addClockClsCompatTriggers()` adds all possible combinations of using
these two message types for the first and second message.  Since it's
not possible to send a message iterator inactivity message without a
clock class, some cases are skipped.

The change in `Makefile.am` is needed for the test to work in builds
with `--enable-built-in-plugins`, for the `RunIn` utility to be able to
find the `utils` plugin.  This was not needed before, because all the
existing triggers make the program stop before `RunIn` attempts to load
the `utils` plugin.

Change-Id: Ib6c22923e4e9f02de64a87efddaee3c23d3891ea
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11811
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

Fix: lib/graph/iterator: consider clock classes from message iterator inactivity messages for clock correlation validation

Make the clock correlation validation code consider clock classes from
message iterator inactivity messages.  This is equivalent to what the
muxer component class does (see `MsgIter::_validateMsgClkCls()`).

Change-Id: I172d0015eb45508da7c412172b24aa4b0236ae9f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12120
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2s: control span-lite's contract check based on BT_DEBUG_MODE

Enable or disable span-lite's contract checking feature based on
BT_DEBUG_MODE.  When contract checking is enabled and a contract
assertion fails, span-lite calls `std::terminate()`.

Change-Id: Ieba9a08712823daf4b77f135155cd15ec97900f5
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12119
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

tests/lib/conds: make `condMain()` take a span for args

Make `argv` a span, instead of having `argc` + `argv`.  There is no
point in this change except that it seemed possible and I wanted to do
it.

Change-Id: I1e7e76638e9e6365df05bb5c7b175d44b6badf6f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12118
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2c: enable span-lite's `make_span()` function

Enable span-lite's `make_span()` function, which exists to compensate
for the lack of class template argument deduction in C++ pre 17.  This
allows creating spans without being too verbose.  This is not a standard
function, but the day we switch to C++ 17 and want to use `std::span`,
we can just replace all uses of `make_span()` with calls to
`std::span`'s constructor.

Make one version of `nonstd::make_span` (expected to be used in an
upcoming patch) available as `bt2c::makeSpan()`.

Change-Id: Ie28c1884d2c03c38a4b839096afae887fa54cc04
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12117
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

tests/lib/conds: store triggers in a vector

An upcoming patch needs to dynamically create and append triggers to the
trigger list.  Make the container a vector.  For simplicity, update
`condMain` to take a reference to a vector of unique pointers of
triggers (rather than inventing some abstraction).

Change-Id: Ic5e2fe6da151434ec515c041d4e1096193d29221
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12115
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

tests/lib/conds: change `nameSuffix` type to `bt2c::CStringView`

I'm not sure why `nameSuffix` is passed as a `const
bt2s::optional<std::string>&` currently.  `bt2c::CStringView` seems like
a good fit for it.  It avoids unnecessarily creating `std::string`s when
the caller passes a literal string.

Change-Id: I1412b77223fe01a70dda4c23558983f84dfb07d4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12114
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

lib/graph/iterator.c: use `BT_IF_DEV_MODE` at a few places

Use `BT_IF_DEV_MODE` where it can easily replace an `#ifdef
BT_DEV_MODE`.

Change-Id: I452f200e09b71a1bd3719262bb6e10009b82d3de
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11968
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

lib: split "message-clock-classes-are-compatible" post-condition in multiple post-conditions

Currently, `clock_classes_are_compatible()` returns a bool indicating if
the clock classes referenced in the current batch of messages are
compatible with the clock classes seen previously by the iterator.  If
there is any incompatibility, whatever the reason, the
"message-clock-classes-are-compatible" post-condition check is
triggered.

A subsequent patch will want to test each individual clock class
incompatibility case, which is not easy if they all produce a message
with the same condition id.

Change `clock_classes_are_compatible_one()` to directly do the
post-condition checks, and give a unique name to each check.

Rename to `assert_post_dev_clock_classes_are_compatible_one`, in line
with the existing `assert_post_dev_expected_packet()` & co.

Adjust and rename `clock_classes_are_compatible()` accordingly.

Change-Id: I38937422f731c0cfebad70f183be97144d43e121
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11954
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2c: add `Uuid::Uuid(bt2c::CStringView)`

Add a `Uuid` constructor that takes `bt2c::CStringView` and remove those
that take a `const char *` and `const std::string &`.  The implicit
conversions to `bt2c::CStringView` should be able to handle all those
types.

Change-Id: I1714fd2aa38c18a047b097908af7b52afebeab72
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11953
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: make `CommonClockClass::uuid` take a `bt2c::UuidView`

This, combined with a following patch that makes the constructors of
`bt2c::UuidView` implicit, makes it possible to pass a `bt2c::Uuid`
object directly to `CommonClockClass::uuid()`.

Change-Id: I336763e128bef5de8e208bc7fafcd9df59d7672a
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11952
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: make setters return `*this`

Change setters (and other methods currently returning `void`) to return
`*this`.

This allows writing more compact code and avoid intermediate variables,
like:

    return graph->addComponent(
        *dummySinkCompCls, "the-sink",
        bt2::MapValue::create()->insert("key1", "val1").insert("key2", "val2"));

It doesn't always produce super readable code, but it's nice to have the
option.

In sub-classes of `BorrowedObject`, the methods return by value.
`ConstMessageArray::append` returns by reference.

Change-Id: I5af80c96b4c947dc217f4dff4b0bcb31885005e8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11951
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: move `SelfSpecificComponent` to `internal` namespace

Change-Id: Icc3536de99be1e0de165e5ec990cffe73cf5be77
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11961
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: check return value in `CommonVariantField::selectedOption()`

Instead of ignoring the return value of
bt_field_variant_select_option_by_index(), check it with
BT_ASSERT_DBG().  This probably won't ever make a difference since
bt_field_variant_select_option_by_index() can't fail for now, but it
looks better.

Change-Id: I2354adfa1358ef0bd77b1d7c6604eef8ccaaa018
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11950
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add message creation methods to `UserMessageIterator`

These are meant to be used by sub-classes of `UserMessageIterator`.

Change-Id: I4dbbd4a121218f432b322e8909b19f4a367f650b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11847
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2c: change some `static inline` functions to just `inline`

I believe that using `inline` for functions in header is preferable to
`static inline`.  With `static inline`, the symbols resulting from the
functions are internal to each translation unit.  We may end up with
multiple copies of the same function in the final executable.  With
`inline`, the linker de-duplicates them.  This is better for code size
and cache and all that.  It may not be relevant for these functions, but
it would be good to set the precendent for the functions we will add in
the future.

The caveat with that is that all copies a function must be identical
(ODR), but I don't think we have a problem with that.

Change-Id: I62eeacf4e8326d70cb94aec33d6684453e1b8912
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11843
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: remove extraneous `protected`

Change-Id: I0771ac211b32f7cb5d07e87338efb22ba797a036
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11846
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: specify default constructor for `UnknownObject`

The constructor is trivial, specify a default constructor.

Change-Id: I9b9ecde9205e8dc57f7fe2f1da494db1c31633c2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11845
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: use `std::unique_ptr` to manage `UserMessageIterator::_mSavedLibError`

clang-tidy points out that `UserMessageIterator` has a user-defined
destructor, but default copy constructors and assignment operators.
This is indeed dangerous: if we have an error in `_mSavedLibError` and
the `UserMessageIterator` object gets copied, the error will be released
multiple times, causing a use-after-free.

The most obvious fix would be to explicitly delete the default
definitions of the copy constructors and assignment operators.  But
I think it's a bit more idiomatic C++ to use some RAII type to manage
the error.  In this case `std::unique_ptr` is a good fit.  This lets us
delete the user-defined destructor.  The copy constructors and
assignment operators are implicitly deleted, since `unique_ptr` doesn't
have them.

Change-Id: Ia78bbda6a342192cb35c1b6963d3ad7fccaa7c3f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11844
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: remove redundant assertions

Remove some redundant BT_ASSERT and BT_ASSERT_DBG.

 - Most `as*()` methods call a constructor that does the exact same
   check.  Some exceptions are field class types that have signed and
   unsigned variants, where the base class' assertion does not check the
   signedness.  Another one is `CommonNullValue::asNull`, where the
   `CommonNullValue` constructor does not take a lib object pointer, so
   does not do a check.
 - Things that end up constructing a `BorrowedObject` don't need to do
   a null pointer check, as `BorrowedObject`'s constructor does one.
 - `BorrowedObjectIterator::operator*` does not need an assertion on the
   length, as `operator[]` of the container is expected to do it (either
   directly, or rely on the preconditions in the lib).

Change-Id: I6f11680628607eee11164a2e9d3f9de7fc7468cb
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12052
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: cpp-common/bt2: more specific assertion in `CommonVariantWithIntegerSelectorFieldClass` constructor

It seems like we can check that the field class is not only a variant,
but more specifically a variant with integer selector.

Change-Id: Ib062779d957ba1e859247c891027121479ae3adb
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12051
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: cpp-common/bt2: don't pass a lib obj ptr when constructing a `CommonNullValue`

When trying to use `CommonValue::asNull()`, we get:

    /home/smarchi/src/babeltrace/src/cpp-common/bt2/value.hpp:1423:55: error: no matching function for call to 'bt2::CommonNullValue<const bt_value>::CommonNullValue(<brace-enclosed initializer list>)'
     1423 |     return CommonNullValue<LibObjT> {this->libObjPtr()};
          |                                                       ^

The `CommonNullValue` constructor takes no parameter, so don't try to
pass one.

Change-Id: I653ab947fc36134c8767f39185a9a2cd85511b90
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12050
CI-Build: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib/utils: add RunIn::onMsgIterNext()

Add a virtual method on `RunIn` to execute some code in the context of
a message iterator's `next` method.

Change-Id: I6f8ca7a9596fd998f07c401c1859177c728a0b53
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11834
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests: fix some include guards

Change-Id: Id8f0f6166039dd04ce36d1742fac41f9b104fca6
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12160
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Tests: src.ctf.lttng-live: stream creation while trace is inactive

Add a test case to exercise the case where streams are created in the
context of a live viewer session while all of its currently-known
streams are inactive.

A full description of the underlying problem is provided in the "Fix:
src.ctf.lttng-live: expect NEW_STREAM/METADATA for inactive streams"
change description.

In essence, when consuming an LTTng live session configured to use
per-PID buffers, a known bug caused Babeltrace to ignore new streams
from an application (A) if all existing streams (existing applications)
were inactive. This led to a user experience akin to a "hang" if they
were expecting events emited by 'A'.

The test replicates this issue by:
  1. Starting an initial trace (T1) with one data stream emitting events
     for a fixed duration, followed by live beacons (triggering inactivity
     messages) for the rest of the duration of the test.
  2. Introducing a second trace (T2) with one data stream while the first
     trace only provides live beacons.
  3. Ensuring messages of T1 and T2 are visible and suitably interleaved.

When running the test against without the fix, Babeltrace fails to
receive new streams when only live beacons are provided, due to an
unchecked 'NEW_STREAMS' flag.

Moreover, once T1 ends (after providing its last inactivity beacon),
the lttng-live component falls in its 'idle' state where it keeps asking
for new streams (see lttng-live.cpp:1573) until the session is torn down
by the server.

Since new streams are available, the server will provide new streams
in response to the first `LTTNG_VIEWER_GET_NEW_STREAMS` command.
However, the first index provided for T2's data stream occurs _before_
the last "live beacon" that was received on T1's behalf.

This causes an internal sanity check to fail with the following error:
  01-18 15:08:39.743 153627 153627 E PLUGIN/SRC.CTF.LTTNG-LIVE handle_late_message@plugins/ctf/lttng-live/lttng-live.cpp:1141 [lttng-live] Invalid live stream state: have a late message when no inactivity message was ever sent for that stream.

With the fix applied, the test succeeds in showing the two traces'
messages interleaved in the expected order.

Change-Id: If40161edfdbefee6189ef63041b0f967493f1db9
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11675
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
CI-Build: Philippe Proulx <eeppeliteloop@gmail.com>

Tests: lttng_live_server: support trace creation timestamps

Add support for a per-trace "creation time" as part of the live server
scenarios.

The objective of this change is to simulate situations where streams are
created and declared to the live client while other streams are already
being consumed.

The approach taken is to add a 'creation-timestamp' property to the
trace objects expressed in the scenario files. The creation timestamp,
when left unspecified is implicitly at the origin of the timeline.

Streams that exist when a client attaches to a live tracing session are
announced as part of the reply of
_LttngLiveViewerAttachToTracingSessionCommand.

When the creation timestamp is not at the origin, the live server starts
expressing the presence of new available streams once it delivers
index entries that start at, or after, the trace creation timestamp.

As part of the live protocol, newly-available streams are expressed by
setting the 'NEW_STREAM' flag as part of the 'flags' of a GetNextIndex
command's reply payload.

Hence, when handling the
_LttngLiveViewerGetNextDataStreamIndexEntryCommand, the server checks
for unannounced streams that have a creation timestamp lesser or equal
to the beginning timestamp of the index entry being delivered. If any
such streams are available, the 'NEW_STREAMS' flag is set as part of the
reply's flags.

When the 'NEW_STREAMS' flag is set, the client is expected to eventually
issue a _LttngLiveViewerGetNewStreamInfosCommand to list any previously
unannounced stream.

The _LttngLiveViewerGetNewStreamInfosCommand handler was previously
stubbed-out to only reply with the 'HUP' status (meaning the client
should hang-up) since the command was never used to announce new
streams. This doesn't mean that the command was unused.

When a live viewer session has reached a point where all of its streams
have been torn-down (no more data to consume), the live viewer
periodically polls the live server with the 'GetNewStreamInfos' command
to resume consumption when/if new streams appear.

Since the command's handler always returned with the "hang-up" status,
the live client would always gracefully exit at that point as it had
consumed all of the available data provided by the various tests.

The handler now implements the command to announce new streams, when
those are available. Thus, multiple statuses can now be returned:
  - OK: new streams are announced as part of the reply
  - NO_NEW: no new streams are available at this point, but there are
    still index entries (and data) left to consume as part of the
    current scenario's traces
  - HUP: all of the current scenario's streams no longer have index
    entries left to be delivered and all streams have been announced to
    the client.

In terms of the live protocol, the sequence of events leading to the use
of this command is:
  - The client issues LTTNG_VIEWER_GET_NEXT_INDEX to receive a new index
    entry
  - There is a new stream with a creation time <= to the next available
    index: announce it to the client by replying with an "inactivity
    beacon" (an empty index entry) + the LTTNG_VIEWER_FLAG_NEW_STREAM
    status flag
  - In response to the LTTNG_VIEWER_FLAG_NEW_STREAM flag's presence, the
    client asks for new streams by issueing the
    LTTNG_VIEWER_GET_NEW_STREAMS command
  - The server replies with a description of the new stream(s) containing:
    - channel name
    - relative path of the file
    - 'is_metadata' flag
    - stream id
    - trace id (which may not have existed up to this point)
  - The client then issues LTTNG_VIEWER_GET_METADATA to get any new
    metadata for the various traces it now tracks. In the case where a
    new trace was announced (a new trace id), this will be the moment
    when the client gets an initial fragment of metadata to initialize
    the trace class hierarchy (see lttng-live.cpp:481)

Notes
-----

The `is_sent` property of stream states is renamed to `all_data_is_sent`
as it felt ambiguous with regards to the new `is_announced` property
which expresses whether or not a stream has been made visible to the
live client.

Change-Id: Iecb86917b444f5068a445e8481749d34ad3b07c7
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11687
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

Fix: src.ctf.lttng-live: expect NEW_STREAM/METADATA for inactive streams

Observed issue
--------------

Some LTTng-tools live tests failures appear to show babeltrace2
hanging (failing to print expected events). The problem is intermittent,
but Kienan was able to develop a test case that's reproducible for him.

The test case performs the following steps:
  - Start a ust application and leave it running
  - Configure and then start an lttng live session
  - Connect a live viewer (babeltrace)
  - Run a second ust application
  - Wait for the expected number of events
    - In the failing case, no events are seen by babeltrace

Using per-uid buffers, the test typically completes normally. With
per-pid buffers the test fails, hanging indefinitely if waiting for the
specified number of events. While "hanging", babeltrace2 is polling the
relayd.

This affects for babeltrace2 stable-2.0 and master while using
lttng-tools master.

For more information, see the description of bug #1406[1]

Cause
-----

When consuming a live trace captured in per-PID mode, Babeltrace
periodically requests the index of the next packet it should consume.

As part of the reply, it gets a 'flags' field which is used to announce
that new streams, or new metadata, are available to the viewer.
Unfortunately, these 'flags' are only set when the relay daemon has new
tracing data to deliver. It is not set when the relay daemon indicates
that the stream is inactive (see LTTNG_VIEWER_INDEX_INACTIVE).

In the average case where an application is spawned while others are
actively emiting events, a request for new data will result in a reply
that returns an index entry (code LTTNG_VIEWER_INDEX_OK) for an
available packet accompanied by the LTTNG_VIEWER_FLAG_NEW_STREAM flag.

This flag indicates to the viewer that it should request new
streams (using the LTTNG_VIEWER_GET_NEW_STREAMS live protocol command)
before consuming the new data.

In the cases where we observe a hang, an application is running but not
emiting new events. As such, the relay daemon periodically emits "live
beacons" to indicate that the session's streams are inactive up to a
given time 'T'.

Since the existing application remains inactive and the viewer is never
notified that new streams are available, the viewer effectively remains
"stuck" and never notices the new application being traced.

The LTTNG_VIEWER_FLAG_NEW_METADATA communicates a similar semantic with
regards to the metadata. However, ignoring it for inactive streams isn't
as deleterious: the same information is made available to the viewer the
next time it will successfully request a new index to the relay daemon.

This would only become a problem if the tracers start to express
non-layout data (like supplemental environment information? but I don't
see a real use-case) as part of the metadata stream that should be made
available downstream even during periods of inactivity.

Note that the same problem most likely affects the per-UID buffer
allocation mode when multiple users are being traced.

Solution
--------

On the producer end, LTTNG_VIEWER_FLAG_NEW_STREAM is set even when
returning an inactivity index.

Note that to preserve compatibility with older live consumers that don't
expect this flag in non-OK response, the LTTNG_VIEWER_FLAG_NEW_STREAM
notification is repeated until the next LTTNG_VIEWER_GET_NEXT_INDEX
command that returns LTTNG_VIEWER_INDEX_OK.

On Babeltrace's end, the handler of the LTTNG_VIEWER_GET_NEXT_INDEX
command (lttng_live_get_next_index) is modified to expect
LTTNG_VIEWER_FLAG_NEW_STREAM in the cases where the command returns:
  - LTTNG_VIEWER_INDEX_OK (as done previously),
  - LTTNG_VIEWER_INDEX_HUP (new),
  - LTTNG_VIEWER_INDEX_INACTIVE (new).

Drawbacks
---------

This is arguably a protocol change as none of the producers ever set the
NEW_METADATA/NEW_STREAM flags when indicating an inactive stream.

References
----------

[1] https://bugs.lttng.org/issues/1406

Fixes #1406
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Change-Id: Icc7f90f5cb805f50ea16968396fe35454d30b4a8
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11587
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

include/babeltrace2/types.h: remove unused `bt_event_header_field`

I don't even know what that is or was.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I79b0d778bd7faa043161788f5157822fbc775083

cpp-common/bt2/wrap.hpp: add a few missing wrap() overloads

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ie06e54e2be2ed7732903c6e6d274aa21801696c6

Fix: bt2::CommonOptionField::hasField(): has_value() not available

I forgot this in ca61ecbc0 ("cpp-common/bt2: use
`bt2::OptionalBorrowedObject` where possible").

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Icb522b0e5a8a73c1899035f820e5d332d6b123d8

bt2/clock-class.hpp: "clock class offset" -> "clock offset"

It really is the offset a clock (clock class instance).

Also, "offset" -> "offset from origin".

This is in preparation of CTF 2 support (including libbabeltrace2
changes), where the concept of origin is more defined.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Id623085ae2194a452d2b9b07a8be17395324a5d5

cpp-common/bt2c: add bt2c::contains()

This new function template returns whether or not some STL container
contains some value instead of using the awkward find() and end()
methods each time.

Similar to new STL contains() methods of C++20.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Idea480f9001272dfaf1dc0df60251983be8f3962

README.adoc: update string_view link

Not using `string_view` Standalone anymore.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ib3f0ab3ae289218c713d59c99f523c54c46df696

cpp-common: replace bstd::string_view with nonstd::string_view

This patch replaces the underlying implementation of string_view wrapped
by `bt2s::string_view` with string-view-lite [1] from the same author as
the other nonstd classes we already use.

string view lite is an implementation of `std::string_view` [2] for
C++98 and up.

This change is motivated by a desire to standardise on one provider for
'nonstd' header libraries and the fact that the current implementation
we use fails to build on SLES12 and it's easier to replace it with a
working and maintained implementation than it is to debug it.

[1]: https://github.com/martinmoene/string-view-lite
[2]: https://en.cppreference.com/w/cpp/header/string_view

Change-Id: I1f9a9d62f3de35d939f514a47898a5d1b3ff0099
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12002
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests: fix readonly variables error with bash 4.4

Local variables are always visible to child functions, when they are
declared readonly and the same variable name is reused this results in
an error with bash 4.4.

As a workaround, rename the affected variables to fix the following
errors:

    ./tests/utils/utils.sh: line 222: args: readonly variable
    ./tests/utils/utils.sh: line 303: extra_details_args: readonly variable

Change-Id: I7321a9940a2e69bede363acddbd5f0465a3b1433
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/12000
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

tests: fix unbound variables in env.sh

When running a bash test script manually, the '_set_var_def' function
expands the variables using their simple form resulting in an unbound
variable error if they are undefined. Use the Default values form
instead in the eval to fix these errors:

    tests/utils/env.sh: line 12: BT_TESTS_AWK_BIN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_GREP_BIN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_PYTHON_BIN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_PYTHON_CONFIG_BIN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_SED_BIN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_CC_BIN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_ENABLE_ASAN: unbound variable
    tests/utils/env.sh: line 12: BT_TESTS_ENABLE_PYTHON_PLUGINS: unbound variable

Change-Id: Ic4b2a3b97bd6a4d776ab6898959742ef77988332
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11999
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib/conds/utils.cpp: condMain(): unset `BABELTRACE_EXEC_ON_ABORT`

This test willingly makes libbabeltrace2 abort, therefore
`BABELTRACE_EXEC_ON_ABORT` gets executed each time, and we don't want
that in the testing context.

condMain() is the closest to where the abort occurs: this means you may
run `tests/lib/conds/conds-triggers` directly and
`BABELTRACE_EXEC_ON_ABORT` won't impact the program.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I72f21cfcbe2ec8b1f48ec0703c42b3b1d710283c
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11818
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

tests/lib: C++ify run-in and condition trigger code

Change the design of the "run in" test util.

Currently, the util exposes separate functions taking a function pointer
(for all contexts where it's possible to run code in),

Change it to a single function accepting a reference to an object of
type `RunIn`, a class with virtual methods corresponding to each
context.  Clients are expected to define classes derived from `RunIn`
and override only the methods they need.

One advantage of this is that it allows a client to override multiple
methods in order to test a scenario that requires executing code in
multiple contexts.  And it allows it to keep some data in the derived
class to use across the callbacks.

Adjust `tests/lib/conds/utils.{cpp,hpp}`, which is based on `RunIn`.
Replace the open struct `cond_trigger` with:

 - a base class `CondTrigger`, with a virtual pure `operator()`.
 - an implementation `SimpleCondTrigger`, which executes a simple
   callback in `operator()`.
 - an implementation `RunInCondTrigger`, which calls `runIn` in
   `operator()`, with a user-provided `RunIn` object.

Update `conds-triggers.cpp`, which is based on `utils.{cpp,hpp}`.
Implement the condition triggers using the C++ bindings.

Do some more miscellaneous C++ification in `utils.cpp` and
`conds-triggers.cpp`.

Change-Id: I483dd1a49bc7fb1e1fc1b19e0fc01b97d4ea627f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11795
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib: use `sink.utils.dummy` in `utils/run-in.cpp`

Instead of implementing another dummy sink.

Note that when executed manually, test programs using the `runIn` util
(e.g. `test-fields-bin`) must be executed through
`tests/utils/run-in-py-env.sh`, for the `utils` plugin to be found.

Change-Id: Ib40480089c7dea35fddc7144b0c99873723f8fe8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11824
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

build: factor out `pluginarchive` function to `src/Makefile.common.inc`

A subsequent patch will need to bundle a plugin in a test executable,
requiring the same command line used by the CLI to bundle plugins in the
`babeltrace2` executable, when `--enable-built-in-plugins` is used.
Move the `pluginarchive` "function" and `PLUGINS_PATH` definition to a
new file, `src/Makefile.common.inc`, and include that file from
`src/cli/Makefile.am`.

Change-Id: I36a8d6191deb82e5bceab3f5b038f69626ecdfe2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11830
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add `findPlugin()`

Add the `findPlugin()` function, allowing one to find a plugin by name.
The default parameter values used are the same as those used in the
Python bindings.

Change-Id: I659b5b0f0ae18965bbcacdac3c4e0c146c7348e4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11823
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add C++ plugin bindings

Add C++ bindings around `bt_plugin`.  There is only the const version
(`ConstPlugin`), because there is no need for a non-const plugin.

Get the scalar properties of a plugin using the `name`, `description`,
`author`, `license` and `path` methods.

Get the version of a plugin using the `version` method.

Get the component classes provided by the plugin using the
`sourceComponentClasses`, `filterComponentClasses` and
`sinkComponentClasses` methods.  These methods return proxy objects that
can be iterated on.  They also defined an `operator[]` method to access
component classes by name.

Change-Id: I5121c7c54a8058e5ca116618472ec8bb63f3a825
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11822
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: move findAllPluginsFromDir() to `plugin-load.hpp`

All "find plugin(s)" function will go in that file.

Change-Id: Ie81a35d8a253dafef2fd696c64341609b0e4960b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11821
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: move `ConstPluginSet` to `plugin-set.hpp`

A subsequent patch will introduce `bt2::ConstPlugin`.  It makes more
sense to have `bt2::ConstPluginSet` in `plugin-set.hpp`.

Change-Id: I84996f34aec325eb2336335a73fdb5e857253c96
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11820
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

bt2: compile `native_bt.c` with `-Wno-undef`

As explained in the comment, work around a problem with SWIG 4.2.0.

Change-Id: Ia95fc1e4929591a0a16df48892b05f5e5df46be3
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11849
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Michael Jeanson <mjeanson@efficios.com>

CONTRIBUTING.adoc: update the "C++ usage" section

Add a subsection about `src/cpp-common` and its contents.

Improve "Coding convention" subsection following our latest convention.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: Ifa6eb57492b9434388889297b77e0835f9f98114
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11853
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>

tests/lib: create and manipulate query executor using C++ bindings in `tests/run-in.cpp`

Change-Id: Ice0533691242cc584de24d60a212c740747c4a56
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11809
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add C++ query executor bindings

Add C++ bindings for query executors.

Create a query executor with the `bt2::QueryExecutor::create()` static
methods (with or without query data).

Perform a query with the `bt2::QueryExecutor::query()` method.

Change-Id: I1db634dfd423b031be7577291d4de02b7fb0df5b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11808
Tested-by: jenkins <jenkins@lttng.org>

tests/lib: create and manipulate graph using C++ bindings in `utils/run-in.cpp`

Change-Id: I63852856cce4d68cb81ae56b8dab67029392dbac
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11807
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add C++ graph bindings

Add C++ bindings to create and manipulate graphs.

Create `bt2::Graph` objects with the `bt2::Graph::create()` static
method.

Add components to graphs with the `bt2::Graph::addComponent()`
methods.  There are overloads of this methods for sources, filters and
sinks, and with and without initialization data.

Connect ports with the `bt2::Graph::connectPorts()` method.  The method
does not (yet) provide access to the connection object returned by the
lib.

Run a graph with `bt2::Graph::run()` or `bt2::Graph::run_once()`.

Change-Id: I92719f9dd6e8c77ded20d1bb4a5ddd2a03e8cf0d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11806
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib: create component classes using C++ bindings in `utils/run-in.cpp`

Change-Id: I449799599a5e0d3b1f4ad1864c027b5e60886cda
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11805
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: make `SinkCompClsBridge::userCompFromLibSelfCompPtr` public

`SinkCompClsBridge::userCompFromLibSelfCompPtr` needs to be public for
`CompClsBridgeWithInputPorts::inputPortConnected` to access it, for
instance.

Here's the error I got when trying to use `SinkCompClsBridge` in a
following patch, which lead to this fix:

      CXX      utils/run-in.lo
    In file included from /home/smarchi/src/babeltrace/src/cpp-common/bt2/component-class.hpp:12,
                     from /home/smarchi/src/babeltrace/tests/lib/utils/run-in.cpp:10:
    /home/smarchi/src/babeltrace/src/cpp-common/bt2/plugin-dev.hpp: In instantiation of 'static bt_component_class_port_connected_method_status bt2::internal::CompClsBridgeWithInputPorts<SpecCompClsBridgeT, LibTypesT>::inputPortConnected(typename LibTypesT::SelfComp*, bt_self_component_port_input*, const bt_port_output*) [with SpecCompClsBridgeT = bt2::internal::SinkCompClsBridge<{anonymous}::DummySink>; LibTypesT = bt2::internal::SinkCompClsLibTypes; bt_component_class_port_connected_method_status = bt_component_class_port_connected_method_status; typename LibTypesT::SelfComp = bt_self_component_sink; bt_self_component_port_input = bt_self_component_port_input; bt_port_output = bt_port_output]':
    /home/smarchi/src/babeltrace/src/cpp-common/bt2/component-class.hpp:477:88:   required from 'static bt2::internal::CommonSinkComponentClass<LibObjT>::Shared bt2::internal::CommonSinkComponentClass<LibObjT>::create() [with UserCompClsT = {anonymous}::DummySink; LibObjT = bt_component_class_sink; Shared = bt2::SharedObject<bt2::internal::CommonSinkComponentClass<bt_component_class_sink>, bt_component_class_sink, bt2::internal::SinkComponentClassRefFuncs>]'
    /home/smarchi/src/babeltrace/tests/lib/utils/run-in.cpp:141:72:   required from here
    /home/smarchi/src/babeltrace/src/cpp-common/bt2/plugin-dev.hpp:160:59: error: 'static UserCompClsT& bt2::internal::CompClsBridge<UserCompClsT, LibTypesT>::userCompFromLibSelfCompPtr(_LibSelfCompPtr) [with UserCompClsT = {anonymous}::DummySink; LibTypesT = bt2::internal::SinkCompClsLibTypes; _LibSelfCompPtr = bt_self_component_sink*]' is inaccessible within this context
      160 |             SpecCompClsBridgeT::userCompFromLibSelfCompPtr(libSelfCompPtr)
          |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
    /home/smarchi/src/babeltrace/src/cpp-common/bt2/plugin-dev.hpp:62:26: note: declared here
       62 |     static UserCompClsT& userCompFromLibSelfCompPtr(const _LibSelfCompPtr libSelfCompPtr) noexcept
          |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~

Change-Id: If7dabf6280f3d861854dd21fa92f785f7176bd5e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11804
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add component class creation methods

Add `create()` methods to `CommonSourceComponentClass`,
`CommonFilterComponentClass` and `CommonSinkComponentClass`, allowing
the user to create component classes at run time from some class that
derives from `UserSourceComponent`, `UserFilterComponent` and
`UserSinkComponent`.

The user component class (`UserComponentT`) must provide a static member
`name` of type `const char *`.  It can also provide static members named
`description` and `help`, also of type `const char *`.

Change-Id: I3bd550fd90a2a75d8154d29d00bf0bf4f9b1fd3e
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11817

cpp-common/bt2: add C++ component class bindings

Add C++ bindings for component classes.

Similar to how C++ bindings for components work, the
`CommonComponentClass` type is implicitly constructible from the
specialized component class types, so that it's possible to pass a
`SourceComponentClass` to something expecting a `ComponentClass`, for
instance.

Get a component class' name, description or help with the methods of the
same name.

Change-Id: Ia6301f4b37f4f86036f6e09cc2aaf49d7028c6fc
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11803

cpp-common/bt2: move user component class bases to `component-class-dev.hpp`

It will become possible to use these classes to create component classes
at runtime, not only in the context of plugins.

Change-Id: I3507a8025fa4e8af6bdb42f2be053dd43f3c2eaa
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11814
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: move component class bridges to `internal/comp-cls-bridge.hpp`

The bridges are going to be used when creating component classes at
runtime, not only in the context of plugins.

Change-Id: If6d04531ee660692d1a6eb84950a584530a23566
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11813
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib: C++ify `conds/utils.cpp` a bit

Change `utils.cpp` to fit a bit more our C++ style.

 - use an anonymous namespace
 - use camel-case for functions
 - use `bt2s::span` for the list of triggers
 - declare functions as `noexcept`

I didn't update the contents of `utils.hpp`, because I expect this to
change in some following patches, while I expect `utils.cpp` to stay
pretty much as-is.

Change-Id: I9dc01a22b3e9ceb2d90cd35c9f6ca93d1afe248f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11794
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

tests/lib: C++ify `conds/conds-triggers.cpp`

 - use an anonymous namespace for local stuff
 - use bt2 C++ bindings
 - rename functions to camel case
 - mark functions as `noexcept`

Change-Id: Id31e3703eb48662cc3090d57247fb16bcea0d7f8
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11797
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib: C++ify `test-fields-bin.cpp`

 - use the C++ bindings
 - rename `test_string_clear` to `testStringClear`
 - use an anonymous namespace
 - declare testStringClear as `noexcept`
 - use constexpr

I checked that the test still managed to catch the bug fixed in
0022a87819b0 ("Fix: clear_string_field(): set first character to 0").

Change-Id: I3631b22f9e70ea5db620ce0597d04e5035bfa91d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11793
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

tests/lib: pass C++ wrapper types to `RunIn` callbacks

Pass C++ wrapper types to `RunInCompClsInitFunc`,
`RunInCompClsQueryFunc` and `RunInMsgIterClsInitFunc` instead of C
library types.

Adjust callers and callees in a trivial way.

Change-Id: I3d6fcee8e0239976483995affcd7e95fb5fa12ef
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11796
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: make `ConstComponentPorts::operator[](bt2c::CStringView)` return an `OptionalBorrowedObject`

The library functions that borrow ports by name return `NULL` when
no port with such name exist.  Change
`ConstComponentPorts::operator[](bt2c::CStringView)` to return an
`OptionalBorrowedObject` to model that in C++.

Change-Id: I2fafb509622e324980b88b70735e7beeb25f7fb4
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11802
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add const_cast when setting user data

If the user data type is specified as a const type,
`static_cast<void *>` will not work.  Fix that by doing a static_cast to
`const void *` then a const_cast to `void *`.

Change-Id: Ic39c9c25da1899defe4edf8c8e800297fbf2fb2d
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11799
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>

cpp-common/bt2: add missing return in `SelfComponentPort::data`

Change-Id: Ib381d8ee919206361f81721ca418b7fdba330c9c
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11792
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add `SelfComponent::createClockClass`

Add the C++ binding to create a clock class from a self component.

Change-Id: I83bab751520458a7c39982df70a71ba214317428
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11810
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add `SelfComponent::createTraceClass`

Add the C++ binding to create a trace class from a self component.

Change-Id: Iaa5ad98bb0dfce7ac8ab7d3c51446cf4ad387b29
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11791
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: add message creation methods to `SelfMessageIterator`

Add methods on `SelfMessageIterator` to create all possible kinds of
messages.

Change-Id: I44b5be4e0783affef619983530d8af619560569f
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11790
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: fix trivial-ish mistakes in plugin-dev.hpp

Fix a few problems that were found by exercising the `plugin-dev.hpp`
code a bit more.

    ⚾ Use public inheritance in `SinkCompClsBridge`.
    ⚾ Add return statement in happy path of
       `SinkCompClsBridge::graphIsConfigured`.
    ⚾ Use `DataT&` as the parameter type to `_addOutputPort` and
       `_addInputPort` methods, matching what
       `Self*Component::add*Port` expects.
    ⚾ Call `_outputPortConnected` instead of `outputPortConnected` in
       `UserSourceComponent::outputPortConnected`, which otherwise results
       in infinite recursion.

Change-Id: Ieab12436c4b85b5a33195be0ea388b3f545f07cd
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11789
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>

cpp-common/bt2: `User*Component`: pass query method data to user `_query` methods

Make `User*Component::query()` pass down the query method data down to
user methods.

Child classes of `UserSourceComponent`, `UserFilterComponent` and
`UserSinkComponent` can pass a template parameter to indicate the type
of query method data they wish to receive.

`UserComponent` defines a `QueryData` public member using the type
received as a template parameter.  `CompClsBridge::query` uses this type
to cast the query method data, received from the lib as a `void *`, to
that type.

Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Change-Id: If9f776dbaa723dd65391e3ea57c3067f53f52dc4
Reviewed-on: https://review.lttng.org/c/babeltrace/+/11788
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
Tested-by: jenkins <jenkins@lttng.org>