Skip to content

Conversation

@colesbury
Copy link
Contributor

@colesbury colesbury commented Dec 20, 2025

@colesbury
Copy link
Contributor Author

I hate this, but I hate the other options even more.

Copy link
Contributor

@mpage mpage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll end up seeing the warning if clang's analysis gets more capable, right? I guess that's still better than disabling warnings around the block in the default build.

Test failure looks unrelated.

@colesbury
Copy link
Contributor Author

We'll end up seeing the warning if clang's analysis gets more capable, right?

I think it's more a matter of convention than capability. Clang can easily optimize through all these things and this warning is only enabled in optimized builds (not debug builds).

Clang doesn't warn for things like:

if (1) {
}
unreachable_code; // OK

But it warns for:

if ((expr, 1)) {
}
unreachable_code; // warning: code will never be executed [-Wunreachable-code]

But not for:

if ((expr, 1) || (1)) {
}
unreachable_code; // OK

But you can't put that expression in a macro:

#define MACRO (expr, 1) || (1)

if (MACRO) {
}
unreachable_code; // warning: code will never be executed [-Wunreachable-code]

@colesbury colesbury merged commit 7607712 into python:main Dec 20, 2025
87 of 89 checks passed
@colesbury colesbury deleted the gh-120321-unused-code branch December 20, 2025 19:42
cocolato pushed a commit to cocolato/cpython that referenced this pull request Dec 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants