panic: "too many cycle iterations" when checking simple loop

[timc-passiv]

error[panic]: Panicked at /root/.cargo/git/checkouts/salsa-e6f3bb7c2a062968/53421c2/src/function/execute.rs:633:9 when checking `/home/timc/arbeit/portal/pst-data-portal-web/partner_portal/src/partner_portal/notifier/notification_handler.py`: `infer_definition_types(Id(92b8)): execute: too many cycle iterations`
info: This indicates a bug in ty.
info: If you could open an issue at https://github.com/astral-sh/ty/issues/new?title=%5Bpanic%5D, we'd be very appreciative!
info: Platform: linux x86_64
info: Version: 0.0.21
info: Args: ["ty", "check"]
info: run with `RUST_BACKTRACE=1` environment variable to show the full backtrace information
info: query stacktrace:
   0: infer_expression_types_impl(Id(c875))
             at crates/ty_python_semantic/src/types/infer.rs:224
   1: infer_definition_types(Id(92c2))
             at crates/ty_python_semantic/src/types/infer.rs:70
   2: infer_scope_types_impl(Id(84a8))
             at crates/ty_python_semantic/src/types/infer.rs:187
   3: check_file_impl(Id(1009))
             at crates/ty_project/src/lib.rs:594


Found 1 diagnostic
WARN A fatal error occurred while checking some files. Not all project files were analyzed. See the diagnostics list above for details.

File being checked attached - has had no errors reported with earlier ty versions.

notification_handler.py

[sharkdp]

Thank you for reporting this.

Here is a minimal reproducer:

x = None
for _ in range(10):
    x = 0 if x is None else x + 1

[charliermarsh]

Seems like this can be fixed with:

diff --git a/crates/ty_python_semantic/src/types/set_theoretic.rs b/crates/ty_python_semantic/src/types/set_theoretic.rs
index 5cec8af50e..9e3791a767 100644
--- a/crates/ty_python_semantic/src/types/set_theoretic.rs
+++ b/crates/ty_python_semantic/src/types/set_theoretic.rs
@@ -88,7 +88,9 @@ impl<'db> UnionType<'db> {
         elements
             .into_iter()
             .fold(
-                UnionBuilder::new(db).cycle_recovery(true),
+                UnionBuilder::new(db)
+                    .cycle_recovery(true)
+                    .recursively_defined(RecursivelyDefined::Yes),
                 |builder, element| builder.add(element.into()),
             )
             .build()

[mtshiba]

OK, I've found the exact cause.
It's because the type of x grows infinitely, like Literal[0, 1, 2, 3, ...]. However, this pattern should have been guarded against by UnionType::recursively_defined: RecursivelyDefined.
The problem is the iteration where Literal[...] has exactly 1 element. In this case, Literal[0] is no longer a union type, so recursively_defined is not inherited.
The reason this pattern wasn't detected before (but is now detected by loop control flow) is probably because implicit attribute inference always combines Unknown, so only union types appear.