Enum type matching issues in pyright 1.1.363

[kkom]

Describe the bug

We started to see a new type error in pyright 1.1.363. When type matching against enums using a match statement under some circumstances we see a false positive lack-of-exhaustiveness error.

I imagine it's related to this change:

Fixed bug that results in incorrect type evaluation behavior within class body of an enum class when one enum member is used to define another enum member. This involved a significant rewrite of the logic involving enum symbol evaluation.

I'm not sure if our original code is sound or not – however it's certainly a very convenient pattern.

Code or Screenshots

from enum import Enum


class MyEnum(Enum):
    ONE = "one"

    def to_int(
        self,
    ) -> int:  # error: Function with declared return type "int" must return value on all code paths, "None" is incompatible with "int" (reportReturnType)
        match self:  # error: Cases within match statement do not exhaustively handle all values, Unhandled type: "MyEnum*", If exhaustive handling is not intended, add "case _: pass" (reportMatchNotExhaustive)
            case self.ONE:
                return 1

VS Code extension or command-line

pyright 1.1.363 via the CLI

[erictraut]

Thanks for the bug report, and apologies for the regression.

I rewrote major portions of pyright's enum support in version 1.1.363 to accommodate some non-standard behaviors in the EnumMeta class that were previously handled incorrectly. Pyright's unit tests for enums are pretty comprehensive, but the use case in your code sample is missing from the tests. That allowed the regression to slip in unnoticed. I'll work on a fix and improve the unit tests to cover this case.

[erictraut]

This is addressed in pyright 1.1.364.