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?

[casetestAvoidUnreachableCodeInUnreachableCodeWithPartialType]# flags: --warn-unreachable --python-version 3.11x=Noney=NonewhilexisNoneandyisNone:reveal_type(x)# N: Revealed type is "None"reveal_type(y)# N: Revealed type is "None"ifxisNoneandyisnotNone:x=1# E: Statement is unreachableifyisNone:y=1[builtinsfixtures/bool.pyi]

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

something like this:

x=Noney=NonewhileTrue:ifxisnotNone:print("a")ifyisnotNone:print("b")# this is unreachablex=1

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

This example should printb. 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 in229e4a6. However, in the last function definition of test casetestNewRedefineTryStatement, the first response toreveal_type does provide complete information, but the second (and final) response does not:

deff4()->None:whileint():try:x=1ifint():x=""breakifint():whileint():ifint():x=Nonebreakfinally: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 inc24c950.

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

ifxisnotNone:print(x+5)

Above thereveal_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 thef4 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 inf4, 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 bothStatement is unreachable andRevealed 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 toreveal_type and theunreachable 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] butTypeChecker.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 suppressall 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=NonewhileyisNone:reveal_type(y)# NoneifyisNone:y= []y.append(1)reveal_type(y)# list[int]

The responses toreveal_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.