Summary

Function calls are relevant for control flow analysis because they may return Never/NoReturn, and can therefore be terminal. In order to support this, we record ReturnsNever(…) constraints during semantic index building for statement-level calls (in almost all situations). These constraints keep track of the call expression such that they can be evaluated during reachability analysis and type narrowing.

For example, if we see a call f(a, b, c), we keep track of this full call expression. The return type could depend on the arguments (overloads, generics), so to determine if a call is terminal, we need to evaluate the full call expression.

For performance reasons, this analysis contained a short-cut where we looked at the return type annotation of the invoked callable (f). Under certain conditions, we could immediately see that a call would definitely be terminal. This previously helped with performance, but is now apparently detrimental.

The optimization recently caused problems for generic function calls, so we had to exclude those. It now turns out there was another bug, as I figured out by looking at the ecosystem results on this PR. When the callable expression could not be upcasted to a callable type, we assumed that the call would never be terminal. However, if the callable itself is Never, that should also be considered a terminal call. This can happen in unreachable code. Consider this rather weird case, that I extracted from a hydpy ecosystem hit:

from typing import Never, Literal


def fail() -> Never:
    raise


def _(x: Literal["a", "b"]):
    if x == "a":
        if 1 + 1 == 2:
            return
        fail()
    if x == "b":
        return

    reveal_type(x)

On main, the revealed type of x is Literal["a"], which is wrong. Since the fail() call itself happens in unreachable code, we infer Never for fail itself, and therefore considered the if x == "a" branch to not be terminal. On this branch, that bug is fixed and we correctly reveal Never for the type of x.

So the idea here is to get rid of this optimization all together and to simply evaluate the full call expression in all cases, which also makes this much easier to reason about.

(I find the AlwaysFalse/AlwaysTrue-answer of this evaluation very rather confusing, because it's sort of negated twice; I plan to change this in a follow-up)

Performance

We previously merged #19867 to address a performance problem in this part of the codebase. It seems to me that the original problem was related to the short-cut path, but I'm not sure if this could bring back the lock congestion problem.

In any case, this PR seems to be a performance win across the board on our usual benchmarks. And there is also a small decrease in memory usage.

Ecosystem impact

The disappearing diagnostics all seem to be related to cases like above, where the terminal call happened in unreachable code.

Test Plan

Existing tests.