The cause of the warning is not the different implementation of assert but bool's. The checker reports cases when the false / zero literal is from a macro expansion e.g. assert(sys::IsLittleEndianHost && "Unexpected host endianness").
I can add exceptions based on the name of the macro containing the false literal. My ideas so far: false, FALSE, False, zero, ZERO, Zero. Please suggest more if you can.

Handling macros 'false', 'FALSE', 'False' seems reasonable. Not sure about "zero" though. Did you see them being used somewhere?

It was just an idea but now I think zero shouldn't be included in the exceptions since I didn't found it used as an assert condition.

I'll reuse the bug instead of closing it: there's one more case where the check complains on assert(false)/assert(0):

void abort() {}
#define assert(x) if (!(x)) abort()

void f() {
#define ASSERT0 assert(0)
ASSERT0;
}

*** Bug llvm/llvm-bugzilla-archive#23355 has been marked as a duplicate of this bug. ***

Friendly ping. Szabolcs, are you going to have time to tackle this?

We use the pretty common idiom of

switch (something) {
case 0:
assert(!"This shouldn't be able to happen");
break;
case 1: ...normal handling etc
}

e.g. in case()s that ought not to be reached. misc-static-assert tags these as "replaceable with static_assert", which of course they're not, being run-time dependent on the 'something'. This seems to be a manifestation of the same bug here?

Re: assert(!"This shouldn't be able to happen");, this should be fixed in r304657, thanks to Florian Gross.

One more problem: it complains on the code like this:

#define ASAN_REGION_IS_POISONED(addr, size) (0)
assert(!ASAN_REGION_IS_POISONED(data, size));

Bumped into same issue. We use our own assert macro and following cases trigger warning:

#define IM_ASSERT(_COND) assert(_COND)

IM_ASSERT(0);
IM_ASSERT(0 && "Some message");

mentioned in issue llvm/llvm-bugzilla-archive#23355

@rokups Have you found a workaround for your example? We have a similar usage that you have described.

Probably not. It was a long while ago, i do not remember for sure, sorry

Original issue looks to be fixed by 43a298c.
Issue with IM_ASSERT is not.