bloom: silence CHECK_ASSERTION_SIDE_EFFECTS false positive

Using gcc 15, compiling with CHECK_ASSERTION_SIDE_EFFECTS=1 causes a
complaint about this line in bloom.c having a side effect:

	assert(version == 1 || version == 2);

I think this is pretty clearly a false positive, as those comparisons
should not have side effects. The side-effect checker uses a magic
definition of assert() that relies on the compiler's optimizer to drop a
reference to an otherwise unused variable. And for whatever reason, gcc
chooses not to do so here under -O2 (side note: if you have -O0 in your
CFLAGS, that naturally creates many more false positives!).

This code has been around for a while, but nobody seems to have noticed
because we use an older version of the compiler in our static-analysis
ci job, and it does not complain. Presumably very few people run this
check locally on their more modern compilers.

Let's silence the false positive to avoid confusion for anyone running
locally, and to make it possible to upgrade the image we use for our
static-analysis job.

We could just switch to our custom ASSERT() here, but I think we can
improve the code by integrating the assertion into the if/else cascade.
That avoids repeating the logic about which versions are acceptable.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

bloom.c

@@ -605,10 +605,10 @@ int bloom_filter_contains_vec(const struct bloom_filter *filter,
 uint32_t test_bloom_murmur3_seeded(uint32_t seed, const char *data, size_t len,
 				   int version)
 {
-	assert(version == 1 || version == 2);
-
 	if (version == 2)
 		return murmur3_seeded_v2(seed, data, len);
-	else
+	else if (version == 1)
 		return murmur3_seeded_v1(seed, data, len);
+	else
+		BUG("unexpected bloom version: %d", version);
 }