On Sun, Sep 10, 2023 at 01:08:11AM +0200, Rubén Justo wrote:

GIT_TEST_PASSING_SANITIZE_LEAK=true and GIT_TEST_SANITIZE_LEAK_LOG=true
use internnlly the --invert-exit-code machinery.  Therefore if the user
wants to use --invert-exit-code in combination with them, the result
will be confusing.

For the same reason, we are already using BAIL_OUT if the user tries to
combine GIT_TEST_PASSING_SANITIZE_LEAK=check with --invert-exit-code.

Let's do the same for GIT_TEST_PASSING_SANITIZE_LEAK=true and
GIT_TEST_SANITIZE_LEAK_LOG=true.

OK, so we are trying to find a case where the user is triggering
--invert-exit-code themselves and complaining. But in the code...

You can see at the top of the context that we will set
invert_exit_code=t ourselves, which will then complain here:

 	if test_bool_env GIT_TEST_SANITIZE_LEAK_LOG false
 	then
+		if test -n "$invert_exit_code"
+		then
+			BAIL_OUT "cannot use --invert-exit-code and GIT_TEST_SANITIZE_LEAK_LOG=true"
+		fi
+
 		if ! mkdir -p "$TEST_RESULTS_SAN_DIR"
 		then
 			BAIL_OUT "cannot create $TEST_RESULTS_SAN_DIR"

That varible-set in the earlier context is from running in "check" mode.
So:

  make GIT_TEST_PASSING_SANITIZE_LEAK=check GIT_TEST_SANITIZE_LEAK_LOG=true

will now always fail. But this is the main way you'd want to run it
(enabling the leak log catches more stuff, and the log-check function
you touch in patch 2 already covers check mode).

So I think you'd have to hoist your check above the if/else for setting
up PASSING_SANITIZE_LEAK modes.

-Peff