That's a nice idea overall. Can I suggest setting the same flag inreachability::infer_reachability_of_if_statement if theif is true and there is noelse? Now we mark all the remaining blocks unreachable, so this flag should also become True there. And then_get_executable_if_block_with_overloads infastparse.py can make use of it...

Now that was one path I found that checks for "unreachable else". There may be more, so maybe introducing a dummy emptyelse is a reasonable alternative to consider?

I tried grepping forelse_body\.is_unreachable and there are only two hits, one mentioned above and one in dataclasses plugin (where this flag won't be helpful?), so maybe_get_executable_if_block_with_overloads is indeed the only other usage site. Or maybe not if there is some other access pattern...

That's a nice idea overall. Can I suggest setting the same flag inreachability::infer_reachability_of_if_statement if theif is true and there is noelse? Now we mark all the remaining blocks unreachable, so this flag should also become True there. And then_get_executable_if_block_with_overloads infastparse.py can make use of it...

Now that was one path I found that checks for "unreachable else". There may be more, so maybe introducing a dummy emptyelse is a reasonable alternative to consider?

I am not sure about this.

Semantic analysis already adds fakeelse_body blocks:

is_unreachable is a pure product of the semantic analysis step, whileunreachable_else is a type checking result that can (at least I think so) frequently change its value (e.g. in repeatedly visited loops). My feeling is that we should keep things separated.

According tomypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅