clang-tidy warnings when using SUBCASE

[bilderbuchi]

I am seeing unexpected warnings from clang-tidy in my test code. It seems to boil down to variables being used in nested macros TEST_CASE and SUBCASE

For example, inside a TEST_CASE, I declare int myint;, define myint inside a SUBCASE, and then use it later on in the TEST_CASE body, I get e.g. warning: 1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage].

Is that a known issue, or am I having unreasonable expectations? I could not find anything in the issue tracker.

I'm using doctest 2.4.10 and clang-tidy 15.0.7

I managed to get a reproducer:

// Compile with g++ myprogram.cpp
// Check with clang-tidy myprogram.cpp --config="" --
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include "doctest.h"

int factorial(int number) { return number <= 1 ? number : factorial(number - 1) * number; }

TEST_CASE("1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage]")
{
   int input;
   int output;

   SUBCASE("Scenario A")
   {
      input  = 3;
      output = 6;
   }
   // more SUBCASEs here in reality, setting up different combinations of inputs and outputs...
   // this line gives warning: 1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage]
   CHECK(factorial(input) == output);
}

Originally posted by @bilderbuchi in #748 (comment)

[JWleo]

Clang tidy supports a wide variety of checks. Many of them are to a few degree based on opinion. Not all of them apply to every project.
if you think it's not reasonable to warn, so f**k it and delete this fool warning of opinion in clang-tidy

[bilderbuchi]

You're surely entitled to your opinion (and I agree with you that clang-tidy has some warnings that can be regarded opinion-like), but personally appreciate it and I do think it's reasonable and important that clang-tidy warns me if I am using an uninitialized value, so I don't consider this a "fool warning" or "opinion".
In this case the warning comes from even "deeper", the clang static analyzer, not clang-tidy itself.

The questions here are more if doctest is doing some shenanigans with macros that should be avoided (i.e. they are a real potential issue that should be flagged), or if doctest uses some macro usage pattern that the clang static analyzer does not (yet) recognize (so, a false positive), and if said pattern can be avoided (and/or an issue filed upstream with said pattern laid out clearly).