clang-tidy warnings with nested macros

[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 (e.g. TEST_CASE and SUBCASE, or TEST_CASE and CHECK.

For example, in a TEST_CASE, if I define sometype myvar = 42, and myvar is then only used inside CHECK, I get warning: unused variable 'myvar' [clang-diagnostic-unused-variable] .
Or, 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, but I thought I'd ask here first, as I don't have a clean MWE extracted from my codebase yet.

I'm using doctest 2.4.10. Clang-tidy is being run on the code that was just used to run the test suite (on CI) , so I think I'm not hitting #691.

[bilderbuchi]

I managed to get a reproducer for the second kind of warning at least,

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

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

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

The first remains elusive to extract from my real project, I can't seem to figure out a way to build up a minimal reproducer (I want to avoid going top-down and successively removing stuff from the project, but maybe that's the only way).

[bilderbuchi]

...aaand I found the reason for the first problem (unused variables): in my compile_commands.json, the file in question appears twice, because it's part of two build targets, one of which has -DDOCTEST_CONFIG_DISABLE. That generates the first of two compile_commands entries for the file in question.
If I delete the entry with -DDOCTEST_CONFIG_DISABLE, things work as expected. Accidentally, it's the first one, so I guess clang-tidy stops searching when it finds the first instance.

I conclude that my second problem is in fact an instance of #691; I'll try to fix my cmake setup so this problem is avoided -- I hope this only needs a different way of propagating compile definitions.

[bilderbuchi]

Reported one of the problems as #761, the other is actually on my side to solve.