Fix a bug in narrow limit

Summary:
The existing handling of the narrow depth limit is usesless! We wind up clearing
narrows whenever we're about to set a narrow, which is actually a no-op:
- We've already gotten the previous narrow when we computed the new narrow
- And then we clear the narrows, but we immediately overwrite it with the new
  narrow
- That means we haven't done anything at all in terms of how the bindings work,
  all we're accomplishing is writing to the same struct field twice in
  succession

In addition, we know that 512 narrows is very likely too much, it will consume
a prohibitively large amount of stack space. The examples we've seen where the
limit gets hit are always generated files with a huge number of narrows at the
top level (and we probably would do best not narrowing at all for all such examples
seen so far), so I think a limit of 100 makes good sense - in practice I don't
think non-generated code would hit this limit, but it saves a lot more stack
usage when we do hit it.

This commit changes the logic so that we intercept narrowing depth in `idx()` and
we just ignore narrows at that point. The resulting behavior will be a bit different
because now we'll completely ignore narrows when we hit the limit (as opposed to
trying to reset at the raw value and then start narrowing again). I don't know
if this behavior is better per se but I think it's easier for a user to understand,
and again I think the limit is probably only going to be hit on generated code
anyway in practice.

Reviewed By: migeed-z

Differential Revision: D91717810

fbshipit-source-id: 173319aec29d11232ff31b3b457b8316636c1ddf

Author: stroxler

pyrefly/lib/binding/scope.rs

@@ -472,7 +472,10 @@ impl Flow {
 /// Bound names can accumulate facet narrows from long assignment chains (e.g. huge
 /// literal dictionaries). Limiting how many consecutive narrows we remember keeps
 /// the flow graph shallow enough to avoid recursive explosions in the solver.
-const MAX_FLOW_NARROW_DEPTH: usize = 512;
+///
+/// When this limit is reached, lookups return the base value instead of the narrow
+/// chain, breaking the recursion. This is checked in `FlowInfo::idx()`.
+const MAX_FLOW_NARROW_DEPTH: usize = 100;
 
 /// Flow information about a name. At least one of `narrow` and `value` will always
 /// be non-None (although in some cases the value may have FlowStyle::Uninitialized,
@@ -563,12 +566,14 @@ impl FlowInfo {
         }
     }
 
-    fn clear_narrow(&mut self) {
-        self.narrow = None;
-        self.narrow_depth = 0;
-    }
-
     fn idx(&self) -> Idx<Key> {
+        // When the narrow depth limit is exceeded, return the base value instead
+        // of the narrow chain to break recursion in the solver.
+        if self.narrow_depth >= MAX_FLOW_NARROW_DEPTH
+            && let Some(FlowValue { idx, .. }) = &self.value
+        {
+            return *idx;
+        }
         match (&self.narrow, &self.value) {
             (Some(FlowNarrow { idx, .. }), _) => *idx,
             (None, Some(FlowValue { idx, .. })) => *idx,
@@ -1679,11 +1684,7 @@ impl Scopes {
                 e.insert(FlowInfo::new_narrow(idx));
             }
             Entry::Occupied(mut e) => {
-                let mut info = e.get().clone();
-                if info.narrow_depth >= MAX_FLOW_NARROW_DEPTH {
-                    info.clear_narrow();
-                }
-                *e.get_mut() = info.updated_narrow(idx, in_loop);
+                *e.get_mut() = e.get().updated_narrow(idx, in_loop);
             }
         }
     }

pyrefly/lib/test/subscript_narrow.rs

@@ -404,13 +404,12 @@ def use2(mapping: NotDict) -> None:
 
 // This test verifies behavior related to MAX_FLOW_NARROW_DEPTH in scope.rs.
 // By assigning to the same key repeatedly, we increment the narrow depth.
-// The depth limit should break the narrow chain to prevent stack overflow,
-// but currently the limit (512) is too high and the check happens too late.
+// After exceeding the depth limit (100), the narrow chain is broken and we
+// fall back to the base type to prevent stack overflow during solving.
 testcase!(
-    bug = "MAX_FLOW_NARROW_DEPTH check is ineffective; should limit to ~100 and check in idx()",
     test_many_consecutive_subscript_assigns,
     r#"
-from typing import assert_type, Literal
+from typing import assert_type
 
 def test() -> None:
     d: dict[str, int] = {}
@@ -519,9 +518,8 @@ def test() -> None:
     d["k"] = 102
     d["k"] = 103
     d["k"] = 104
-    # After 105 assignments, the narrow depth limit should be exceeded and we
-    # should fall back to `int`. But currently we still track Literal[104]
-    # because MAX_FLOW_NARROW_DEPTH=512 is too high and the check is ineffective.
-    assert_type(d["k"], Literal[104])
+    # After 105 assignments, the narrow depth limit (100) is exceeded and we
+    # fall back to `int` instead of tracking the literal value.
+    assert_type(d["k"], int)
 "#,
 );