Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reportMatchNotExhaustive false negative when variables used with *rest #1004

Open
GuiltiTer opened this issue Jan 19, 2025 · 0 comments
Open
Labels
type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules upstream bug a bug that also exists in pyright but has not been raised upstream

Comments

@GuiltiTer
Copy link

GuiltiTer commented Jan 19, 2025

The linter for the following code indicates that the match statement is not exhaustive and inferred return type is str | None:

def f(names: list[str]) -> str:
    match names:
        case []:
            return ""
        case [a]:
            return f"{a}"
        case [a, b]:
            return f"{a}, {b}"
        case [a, b, *rest]:
            return f"{a}, {b}, {len(rest)}"
basedpyright: Cases within match statement do not exhaustively handle all values Unhandled type: "list[str]"
  If exhaustive handling is not intended, add "case _: pass" [reportMatchNotExhaustive]

The names argument matches empty, one-element, two-element, and n + 2 elements, which exhaustes all the possible list constructions.

by adding another arm to the match statement, the linter stops complaining:

case [*xs]: 
    ...
@KotlinIsland KotlinIsland added the type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules label Jan 19, 2025
@DetachHead DetachHead changed the title The false nonexhaustive match statement reportMatchNotExhaustive false negative when variables used with *rest Jan 20, 2025
@DetachHead DetachHead added the upstream bug a bug that also exists in pyright but has not been raised upstream label Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type checking / linting issues relating to existing diagnostic rules or proposals for new diagnostic rules upstream bug a bug that also exists in pyright but has not been raised upstream
Projects
None yet
Development

No branches or pull requests

3 participants