Exhaustiveness Checks Fail on Singleton Enums

[dylanmann]

When an enum only has one value, exhaustiveness checks don't work properly. The reason I want to do this is I am adding a new enum that will grow over time, and want to make sure that when new values are added to the enum, they get handled by downstream code.

To Reproduce

import enum
from typing_extensions import assert_never

class MyEnum(enum.Enum):
    foo = "foo"

def foo(x: MyEnum) -> int:
    match x:
        case MyEnum.foo:
            return 1

    assert_never(x)

Expected Behavior

I expect this to typecheck with no errors

Actual Behavior

mypy test.py
test.py:14: error: Argument 1 to "assert_never" has incompatible type "MyEnum"; expected "NoReturn"  [arg-type]
Found 1 error in 1 file (checked 1 source file)

Note that changing the original to the following results in a clean run, so the issue here seems to be that the enum only has one member.

import enum
from typing_extensions import assert_never

class MyEnum(enum.Enum):
    foo = "foo"
    bar = "bar"

def foo(x: MyEnum) -> int:
    match x:
        case MyEnum.foo:
            return 1
        case MyEnum.bar:
            return 2

    assert_never(x)

Your Environment

• Mypy version used: mypy 0.991 (compiled: yes)
• Mypy command-line flags: N/A
• Mypy configuration options from mypy.ini (and other config files): N/A
• Python version used: 3.10.4

[AlexWaygood]

Reposting what I posted in #14264 (a duplicate of this issue):

It looks like the bug is specific to pattern-matching; mypy has no problems with this version of the same function using if/else idioms (and it will correctly identify the else branch as unreachable if you add a call to reveal_type):

from enum import Enum, auto

from typing_extensions import assert_never


class Color(Enum):
    Red = auto()


def f(color: Color) -> None:
    if color is Color.Red:
        print("red")
    else:
        assert_never(color)

https://mypy-play.net/?mypy=latest&python=3.11&gist=ca293bc0ccb5ec9c77af029f0c95360e

[superosku]

Whats the status of this bug? Any plans to get it fixed?

[AlexWaygood]

Whats the status of this bug? Any plans to get it fixed?

As with many issues in open-source software, it looks like the status is we're waiting for a volunteer to come along and propose a fix for the issue! Would you be interested in working on it @superosku? :)

[superosku]

I am interested in working on it :)

Since I am not familiar with the mypy codebase. Would you @AlexWaygood have any pointers on where on the codebase should I start looking into this?

[AlexWaygood]

Would you @AlexWaygood have any pointers on where on the codebase should I start looking into this?

Not sure; I'm not too familiar with how mypy does exhaustiveness checks. Some areas of mypy's codebase that might be relevant:

• The bits relating to pattern-matching: https://github.com/python/mypy/blob/master/mypy/checkpattern.py
• The bits relating to enums:
  • https://github.com/python/mypy/blob/master/mypy/semanal_enum.py
  • https://github.com/python/mypy/blob/master/mypy/plugins/enums.py
• The bits relating to code reachability: https://github.com/python/mypy/blob/master/mypy/reachability.py

You could also look through previous PRs implementing reachability/exhaustiveness checks for pattern-matching, and see which parts of the codebase they touched.

[superosku]

Thanks @AlexWaygood ! Opened a PR here: #16966