NoReturn behaviour change and unintuitive error that looks like a bug

[Avasam]

Hi!
I was about to open a bug for a NoReturn type narrowing regression in 1.1.300 but then noticed:

[...] it also produces somewhat inconsistent type evaluation results because a function whose type is inferred to be NoReturn by the type checker will not be treated as such if it is called elsewhere in the program

Indeed I just got hit by that inconsistent type evaluation. All my return types are implicit return types (when not writing a library with a contractual API) so I can fully leverage type inference and not have to constantly tweak return type annotations.

I have exit_program method that cleans everything up before calling sys.exit(). It looks something like this (shortened version, just for context):

def exit_program():
    if self.update_auto_control:
        self.update_auto_control.terminate()
    self.capture_method.close(self)
    if a0 is not None:
        a0.accept()
    if self.is_auto_controlled:
        # stop main thread (which is probably blocked reading input) via an interrupt signal
        os.kill(os.getpid(), signal.SIGINT)
    sys.exit()

# Simulates LiveSplit quitting without asking.
# This also more gracefully exits LiveSplit
# Users can still manually save their settings
if a0 is None:
    exit_program()

# [...] some code later
a0.ignore()

Easy fix, just add -> NoReturn. But it does raise the concern that it looks like a bug and seems inconsistent when I see:


and

I understand that

This results in a big speed improvement for some (unannotated) code bases

, just voicing concern over a very confusing and inconsistent type reporting. Maybe having Unknown instead of NoReturn as the revealed type for implicit NoReturn would be fine? That's how it acts anyway. And/or a more visible way for the user to know infered return type doesn't work for NoReturn

[erictraut]

Yes, you'll need to explicitly annotate NoReturn types going forward if you depend on the NoReturn affecting code flow analysis (type narrowing, reachability, etc.).

And yes, I agree that it seems somewhat inconsistent. That was my hesitation in making this change. But it's a huge performance win, so I think it's the right tradeoff. NoReturn functions and methods are relatively rare, so it shouldn't be much of a burden to annotate them.

Other type checkers like mypy and pyre don't perform return type inference in any manner, so pyright is already going well beyond what they do.