[clang-tidy] readability-implicit-bool-conversion false positive with bool and logical operators in C23

[Chase-san]

The readability-implicit-bool-conversion check incorrectly warns about implicit bool -> int conversion when using bool values with the && operator, even though both operands are scalar types and this is perfectly valid C.

The warning message is misleading - it suggests a type safety issue when this is actually just normal operation of the && operator. If the intent is to enforce a style preference for explicit comparisons, the warning should clearly state that rather than implying a conversion problem.

This only occurs when clangd is set to "-std=c23".

Expected Behavior

No warning should be issued. The C standard explicitly states that && accepts any scalar type, and bool is a scalar type. There is no implicit conversion issue here.

Actual Behavior

"Warning: Implicit conversion 'bool' -> 'int'" on the returns_bool() call when used with &&.

Environment

clangd version: 21.1.4
C standard: C23
Platform: windows

Example Code

bool returns_bool(void) { return true; }

void test(size_t len) {
    // NO WARNING - bool used directly in condition
    while (returns_bool()) {}
    
    // WARNING: "Implicit conversion 'bool' -> 'int'"
    while ((len > 0) && returns_bool()) {}
}

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: None (Chase-san)

The `readability-implicit-bool-conversion` check incorrectly warns about implicit `bool` -> `int` conversion when using `bool` values with the `&&` operator, even though both operands are scalar types and this is perfectly valid C.

The warning message is misleading - it suggests a type safety issue when this is actually just normal operation of the && operator. If the intent is to enforce a style preference for explicit comparisons, the warning should clearly state that rather than implying a conversion problem.

This only occurs when clangd is set to "-std=c23".

Expected Behavior

No warning should be issued. The C standard explicitly states that && accepts any scalar type, and bool is a scalar type. There is no implicit conversion issue here.

Actual Behavior

"Warning: Implicit conversion 'bool' -> 'int'" on the returns_bool() call when used with &&.

Environment

clangd version: 21.1.4
C standard: C23
Platform: windows

Example Code

bool returns_bool(void) { return true; }

void test(size_t len) {
    // NO WARNING - bool used directly in condition
    while (returns_bool()) {}
    
    // WARNING: "Implicit conversion 'bool' -> 'int'"
    while ((len > 0) && returns_bool()) {}
}

[AaronBallman]

I think this is behaving the way the check is documented to behave. Specifically:

boolean expression/literal to integer (conversion from boolean to a single bit bitfield is explicitly allowed),

There is such a conversion here. returns_bool returns a bool data type, but (len >0) yields an int datatype (see C23 6.5.9p7). So the operands to && are int and bool, hence there's an implicit conversion from bool to int being reported.

So I don't think this is a false positive, unless I'm missing something.

However, you do not get this diagnostic in C99 mode with _Bool though and that surprises me: https://godbolt.org/z/vTPsGMn9x

[Chase-san]

I thought that too at first. But it happens if both sides of the && are explicitly bool (such as by cast) as well.

Doing a explicit check of == true fixes this, as does an explicit cast to int. But that shouldn't be needed.

[AaronBallman]

I thought that too at first. But it happens if both sides of the && are explicitly bool (such as by cast) as well.

Ah, yeah, that's a bug IMO.

Doing a explicit check of == true fixes this, as does an explicit cast to int. But that shouldn't be needed.

Agreed, particularly for that case.

[zeyi2]

However, you do not get this diagnostic in C99 mode with _Bool though and that surprises me

I think it's because the check require LangOpt.Bool to work, which seems to be false in C99.

I think it is reasonable to change this from return LangOpts.Bool; to return LangOpts.Bool || LangOpts.C99;. I'll open a Pull Request to fix both the C23 and the C99 issue soon :)