I noticed this during a routine CI config update (#364). Details on Cirrus. The update currently sidesteps this by sticking with a distro that still uses llvm 14, but sooner or later this will need resolving. The exact set of errors depends on the clang-tidy version, but the good news is that it's just a handful. In the above run:
/broker/caf/libcaf_core/caf/config_value.hpp:550:7: error: Undefined or garbage value returned to caller [clang-analyzer-core.uninitialized.UndefReturn,-warnings-as-errors]
return std::move(*val);
^
/broker/caf/libcaf_core/caf/config_value.hpp:106:5: error: 1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage,-warnings-as-errors]
set(std::forward<T>(x));
^
As these straddle Broker and CAF I'm not sure how to proceed — seems Broker's clang-tidy run should not complain about things it finds in CAF, since CAF has its own clang-tidy setup. I can't tell if Broker is doing anything wrong in its use of those CAF APIs.
One idea I had was to treat the CAF headers as system headers, so there's a way to mute their findings, but I couldn't get that to work.
I noticed this during a routine CI config update (#364). Details on Cirrus. The update currently sidesteps this by sticking with a distro that still uses llvm 14, but sooner or later this will need resolving. The exact set of errors depends on the clang-tidy version, but the good news is that it's just a handful. In the above run:
As these straddle Broker and CAF I'm not sure how to proceed — seems Broker's clang-tidy run should not complain about things it finds in CAF, since CAF has its own clang-tidy setup. I can't tell if Broker is doing anything wrong in its use of those CAF APIs.
One idea I had was to treat the CAF headers as system headers, so there's a way to mute their findings, but I couldn't get that to work.