Reachability/exhaustiveness checking for match statements

[JukkaL]

Currently this generates a false positive, since mypy doesn't recognize that all the possible values are processed by the match statement:

# Error: Missing return statement
def f(x: int | str) -> int:
    match x:
        case str(v):
            return 0
        case int(v):
            return 1
    # We can't reach here, but mypy doesn't know it

This has the same issue as well:

# Error: Missing return statement
def f(x: int | str) -> int:
    match x:
        case str(v):
            return 0
        case v:
            return 1

[JukkaL]

@freundTech Did you have a work-in-progress implementation of exhaustiveness checking? If you have, it would be great if you could create a PR -- maybe I or somebody else can help finish it?

[freundTech]

There is a working exhaustiveness checking implementation in https://github.com/freundTech/mypy (feature-match-stmt-exhaustiveness branch. I made it the default branch)

I could make a PR from that branch, but it would need major rebasing. It's probably better to cherry-pick the relevant commits to a new branch instead of rebasing all of it.

The implementation works, but I'm not really happy with it's design. It checks all patterns twice. First ignoring guard statements in order to infer rough types for capture patterns (capture patterns need to be inferred before a guard statement can use them) and then a second time with guard patterns to infer more accurate types and narrow the capture patterns.

I did this because I thought that mypy couldn't broaden a variable's type after it was inferred. Later I found out that it can do that, but didn't have enough time to redo my implementation.

An example to illustrate the problem:

x: object

match x:
    case int(c) if c < 5:
        pass
    case str(c):
        pass

c should be inferred as int | str. To know this we need to look at both cases. Before checking the second case we need to check the first case. Checking the first case includes checking the guard. Checking the guard required c to be inferred first.

[JukkaL]

Thanks! Cherry-picking from your branch and potentially tweaking parts of the implementation sounds reasonable. The branch also suggests that we could split this into at least two separate PRs: first one adds basic support and second one adds better support for enums (and literal types).

[JukkaL]

There's some relevant discussion starting from this comment: #10191 (comment)

Here's my summary of the ideas discussed above (these can be moved to follow-up issues):

• case _: assert False could generate an error if it's reachable
• We could have a per-module strictness flag that generates an error if mypy can't prove that a match statement covers all values exhaustively

[erictraut]

For what it's worth, here's another discussion on this topic: microsoft/pyright#2569.

I'm personally not a fan of using assert False for this purpose. There are other reasons why someone might want to use assert False in their code. A type checker should not generate errors if it see an assert False statement because it doesn't violate any type rules. I'd prefer to standardize on assert_never and add it to one of the stdlib stubs.

I'm wondering if this is the same issue as what I am experiencing?

def testing_return(test: str) -> str:
    match test:
        case "test":
            return test
        case "testing":
            return test

if __name__ == "__main__":
    print(testing_return("test"))

results in:
test.py:1: error: Missing return statement

it seems even valid match case blocks in python 3.10 results in mypy giving the missing return statement error.

[JelleZijlstra]

@Pavocracy that error is correct. The function does not return a value if test is any string other than "test" or "testing".

(It doesn't matter that you only call the function with "test" as an argument. Mypy essentially checks each function in isolation.)

@JelleZijlstra so mypy will always complain at match blocks that dont contain case _: ?

I did not know that, thank you for the information!

Just to clarify incase this ever shows up in a search result. Simply adding a case _: didn't fix my error.
I now understand I was using the match case incorrectly. I need to made modifications in the match block and have the return statement after the match block.

[freundTech]

@Pavocracy Once this issue is solved using a case _: with a return should also work.
Then you could also type test as Literal["test", "testing"] instead of adding another return. That let's mypy know that only "test" and "testing" are valid inputs for this function