What if an unreachable statement is within another unreachable statement?

I am not exactly sure what you are asking for.

Is this an example that fits your question?

[case testAvoidUnreachableCodeInUnreachableCodeWithPartialType]
# flags: --warn-unreachable --python-version 3.11

x = None
y = None
while x is None and y is None:
    reveal_type(x)  # N: Revealed type is "None"
    reveal_type(y)  # N: Revealed type is "None"
    if x is None and y is not None:
        x = 1  # E: Statement is unreachable
        if y is None:
            y = 1

[builtins fixtures/bool.pyi]

In this case, the results are the same for 1.15 and the current state of this PR.

something like this:

x = None
y = None
while True:
    if x is not None:
        print("a")
        if y is not None:
            print("b")  # this is unreachable
    x = 1

(I haven't run the PR on this so I'm not sure the result, but it should warn about unreachablity. mypy 1.15 does. I'm worried this change won't)

This example should print b. Is there a typo?

I edited it afterwards, it shouldn't anymore.

Yes, you were totally right. The large temporarily unreachable code section shadowed the persistent unreachable code section. I added your test case and extended the current logic a bit. It's late now, so I'll postpone double-checking until tomorrow.

Can you see any more potential pitfalls?

I again looked at it. To me, the logic appears a little special, but clear and straightforward. Of course, I cannot exclude that there are more special cases my solution does not cover. So I wait for the next review.

Why can't this just use the last round of unreachability warnings?

That is a good question. I initially implemented it so in 229e4a6. However, in the last function definition of test case testNewRedefineTryStatement, the first response to reveal_type does provide complete information, but the second (and final) response does not:

def f4() -> None:
    while int():
        try:
            x = 1
            if int():
                x = ""
                break
            if int():
                while int():
                    if int():
                        x = None
                        break
        finally:
            reveal_type(x) # N: Revealed type is "Union[builtins.int, builtins.str, None]" \
                           # N: Revealed type is "Union[builtins.int, None]"

I have no experience with the new --allow-redefinition-new option so far, and have not tried to investigate why this happens. I just extended my approach in c24c950.

Wouldn't that case also allow something not allowed for str? Eg does that error for:

if x is not None:
  print(x + 5)

Above the reveal_type

Oh, after re-reading, it seems that I have not hit the point of your question. Another try: There might be some scope for optimisations. However, I am unsure what can possibly happen when running Mypy with different configurations (like in the f4 example discussed above), so I preferred to implement this part of the approach as robustly as possible.

On the other hand it's possible to be too robust: mypy only prints the errors for the last round right? So it's possible (through some bug elsewhere, like forgetting to propagate line numbers maybe?) to have unreachable code in the last run that isn't marked -- and so have no signal that the code there isn't checked.

On the other other hand, just using the last iteration's unreachability errors might be wrong in presence of bugs like in f4, but it's simpler (and implementation is trivial to get right) and could never mislead the user about what code could get errors.

Basically I think it's better to match the semantics of how error reporting happens (ie during the last round of checking) then to have only one type of error be correct in face of bugs.

Edit: actually I might be wrong about my assumptions here, let me play with your PR a bit and I'll update this.

My bad; the -warn-unreachable flag was missing in the test case. Now I get both Statement is unreachable and Revealed type is "builtins.str". However, the same happens when I check the modified test with Mypy-Master. Therefore, I don't know if this actually points to a flaw in my current approach. I will investigate tomorrow....

...I had no time for a detailed investigation yet, but I tend to think the problem with the currently discussed test case has nothing to do with this PR, because the response to reveal_type and the unreachable error for the same line happen at the same iteration step.

Maybe the first hint on the cause for this discrepancy: expr.node.type = Union[builtins.int, builtins.str, None] but TypeChecker.lookup_type(expr) = Union[builtins.int, None].

@JukkaL do you think types getting narrower between iterations (see previous comments) should be allowed?

If not, then could this PR simply suppress all output and only print out the last iteration?

Maybe I misunderstand, but that sounds like reverting the "fix part" of this PR.

This is the current behaviour with the proposed changes to Mypy:

y = None
while y is None:
    reveal_type(y)  # None
    if y is None:
        y = []
    y.append(1)
    reveal_type(y)  # list[int]

The responses to reveal_type are the result of the first iteration step. In the second iteration step, the whole loop's body is unreachable.

I think @tyralla is right, and just printing out the last iteration is not the right thing to do. I'll still need to experiment with this however.