[ty] Fix standalone expression type retrieval in presence of cycles

[sharkdp]

Summary

When entering an infer_expression_types cycle from TypeInferenceBuilder::infer_standalone_expression, we might get back a TypeInference::cycle_fallback(…) that doesn't actually contain any new types, but instead it contains a cycle_fallback_type which is set to Some(Type::Never). When calling self.extend(…), we therefore don't really pull in a type for the expression we're interested in. This caused us to panic if we tried to call self.expression_type(…) after self.extend(…).

The proposed fix here is to retrieve that type from the nested TypeInferenceBuilder directly, which will correctly fall back to cycle_fallback_type.

Details

I minimized the second example from #17792 a bit further and used this example for debugging:

from __future__ import annotations

class C: ...

def f(arg: C):
    pass

x, _ = f(1)

assert x

This is self-referential because when we check the assignment statement x, _ = f(1), we need to look up the signature of f. Since evaluation of annotations is deferred, we look up the public type of C for the arg parameter. The public use of C is visibility-constraint by "x" via the assert statement. While evaluating this constraint, we need to look up the type of x, which in turn leads us back to the x, _ = f(1) definition.

The reason why this only showed up in the relatively peculiar case with unpack assignments is the code here:

ruff/crates/ty_python_semantic/src/types/infer.rs

Lines 2709 to 2718 in 78b4c3c

	fn infer_target<F>(&mut self, target: &ast::Expr, value: &ast::Expr, infer_value_expr: F)
	where
	F: Fn(&mut TypeInferenceBuilder<'db>, &ast::Expr) -> Type<'db>,
	{
	let assigned_ty = match target {
	ast::Expr::Name(_) => None,
	_ => Some(infer_value_expr(self, value)),
	};
	self.infer_target_impl(target, assigned_ty);
	}

For a non-unpack assignment like x = f(1), we would not try to infer the right-hand side eagerly. Instead, we would enter a infer_definition_types cycle that handles the situation correctly. For unpack assignments, however, we try to infer the type of value (f(1)) and therefore enter the cycle via standalone_expression_type => infer_expression_type.

closes #17792

Test Plan

• New regression test
• Made sure that we can now run successfully on scipy => see [ty] Move 'scipy' to list of 'good' projects #17850

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[MichaReiser]

Nice find and thanks for adding an inline comment!