Disable clang-analyzer-core.UndefinedBinaryOperatorResult warning because it produces a false positive in a Cap’n Proto header:
0/usr/include/kj/async-inl.h:609:37: warning: The left operand of '+' is a garbage value [clang-analyzer-core.UndefinedBinaryOperatorResult]
1 609 | return *(void**)(*(char**)obj + voff);
This was reported by fanquake in #33256 and was previously addressed in https://github.com/bitcoin-core/libmultiprocess/pull/184/commits/76313450c2c4aa70cf5c443dc2b33c621a565fb5 which changed the analyzer result to be a warning instead of an error. PR https://github.com/capnproto/capnproto/pull/2334 was also merged upstream to prevent this in future versions of Cap’n Proto.
Unfortunately it does not seem possible suppress the false-positive warning from this header without turning off the check for bitcoin code as well. The header is included with -isystem so it is treated as a third party header, but clang-tidy has a longstanding issue discussed in https://reviews.llvm.org/D26418 where it ignores -isystem and ignores HeaderFilterRegex and ExcludeHeaderFilterRegex directives if it decides that errors are associated with the “main file” of the translation unit, which is the case here. (See isInMainFile in https://github.com/llvm/llvm-project/pull/91400/files)
The tidy error is a false positive from clang-analyzer (https://clang-analyzer.llvm.org/) warning that the vtable pointer *(char**)obj is a garbage value rather than a valid memory address. The analyzer has no way of knowing it could be a valid address since it’s only valid due to assumptions about the ABI.
The purpose of the code is to get a starting function address that can be passed to addr2line from a lambda or function object. The function GetFunctorStartAddress calls a helper PtmfHelper::apply to get the starting function address from a pointer-to-member-function value pointing at the operator() method. The helper needs to handle virtual methods, so it checks if the pointer is virtual by testing its low-order bit, and if set, assumes the first bytes of the object are a vtable pointer, and does pointer arithmetic with the vtable address. Clang-tidy complains about this because it does not know the vtable address is valid, assuming incorrectly it is a “garbage value”.
This PR is part of the process separation project.
