Cannot return NoReturn from function calling function from another package which returns NoReturn

[layday]

The following produces an error on line 7:

# pyright: strict

from typing import NoReturn

import click

def foo() -> NoReturn:  # Error: Function with declared type of "NoReturn" cannot return "None"
    ctx = click.get_current_context()
    reveal_type(ctx.exit)
    ctx.exit()  # This returns "NoReturn".


def bar() -> NoReturn:
    ...


def baz() -> NoReturn:  # Ok
    bar()

I haven't opened a bug report because I haven't attempted to reproduce it with other third-party modules/packages, so I do not know if it's an issue with click; but it might be worth investigating.

[erictraut]

This is a limitation in the way that pyright's code flow engine works. It is technically a bug, but I don't see a way to address it, and I've marked similar bugs as "won't fix" in the past.

Here's the problem. The types of some symbols (such as ctx above) requires the type engine to perform code flow analysis. It does this by evaluating the code flow graph. The code flow graph, in turn, is potentially influenced by call expressions that do not return. So there's a chicken-and-egg problem where the code flow graph is needed to evaluate a type but the type is needed to understand the code flow graph. I broke that dependency in most common cases by writing special-case evaluation code to detect no-return call expressions in common (simple) situations without invoking the full type evaluator. But there are limits to this approach.

In your example above, the type of ctx must be inferred because it has no type annotation. If you add a type annotation, the special-case logic will be able to evaluate the type of ctx.exit, and the error will go away.

ctx: Context = click.get_current_context()

I'll continue to think about ways to make this code more robust, but it is an edge case, so I'm reluctant to significantly complicating the code flow engine or slowing down all code analysis to address it. In the meantime, I consider it a known limitation with a straightforward workaround.

[layday]

Thanks for explaining and for providing the workaround. It also happens when instantiating a Context directly, i.e. ctx = Context() must be annotated with ctx: Context = Context(), if that is at all easier to fix.