[Bug][IDE]: Panic in subset.rs: assertion left == right failed

[connernilsen]

Describe the Bug

Hit panic in the IDE when testing out narwhals-dev with _pandas_like/dataframe.py open and making a change in _compliant/dataframe.py.

Changing EagerDataFrame in _compliant and checking its type from the import statement in _pandas_like caused the following panic.

2025-05-14 14:11:00.554 [info] Thread panicked, shutting down: panicked at fbcode/pyrefly/pyrefly/lib/solver/subset.rs:996:9:
assertion `left == right` failed
  left: 1
 right: 2
Backtrace:

2025-05-14 14:11:00.597 [info]    0: fbpyrefly::exit_on_panic::{closure#0}
             at ./fbcode/pyrefly/pyrefly/bin/facebook/main.rs:103:37
   1: std::panicking::rust_panic_with_hook
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/alloc/src/boxed.rs:1990:9
   2: std::panicking::begin_panic_handler::{closure#0}
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/std/src/panicking.rs:704:13
   3: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::begin_panic_handler::{closure#0}, !>
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/std/src/sys/backtrace.rs:168:18
   4: rust_begin_unwind
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/std/src/panicking.rs:695:5
   5: core::panicking::panic_fmt
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/core/src/panicking.rs:75:14
   6: core::panicking::assert_failed_inner
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/core/src/panicking.rs:425:17
   7: core::panicking::assert_failed::<usize, usize>
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/core/src/panicking.rs:380:5
   8: <pyrefly::solver::solver::Subset<pyrefly::state::state::TransactionHandle>>::check_targs
             at ./fbcode/pyrefly/pyrefly/lib/solver/subset.rs:996:9
   9: <pyrefly::solver::solver::Subset<pyrefly::state::state::TransactionHandle>>::is_subset_eq_impl
             at ./fbcode/pyrefly/pyrefly/lib/solver/subset.rs:786:34
  10: <pyrefly::solver::solver::Subset<pyrefly::state::state::TransactionHandle>>::is_subset_eq
             at ./fbcode/pyrefly/pyrefly/lib/solver/solver.rs:628:18
  11: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::callable_infer_params
             at ./fbcode/pyrefly/pyrefly/lib/solver/solver.rs:507:9
  12: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::callable_infer
             at ./fbcode/pyrefly/pyrefly/lib/alt/callable.rs:714:17
  13: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::call_infer
             at ./fbcode/pyrefly/pyrefly/lib/alt/call.rs:501:17
  14: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::expr_infer_type_no_trace::{closure#14}
             at ./fbcode/pyrefly/pyrefly/lib/alt/expr.rs:1375:29
  15: <<pyrefly::alt::answers::AnswersSolver<_>>::map_over_union::Data<pyrefly::state::state::TransactionHandle, <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::distribute_over_union<<pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::expr_infer_type_no_trace::{closure#14}>::{closure#0}>>::go
             at ./fbcode/pyrefly/pyrefly/lib/alt/answers.rs:759:22
  16: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::expr_infer_type_no_trace
             at ./fbcode/pyrefly/pyrefly/lib/alt/answers.rs:804:9
  17: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::expr_infer_type_info_with_hint
             at ./fbcode/pyrefly/pyrefly/lib/alt/expr.rs:834:34
  18: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::expr
             at ./fbcode/pyrefly/pyrefly/lib/alt/expr.rs:119:9
  19: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::binding_to_type
             at ./fbcode/pyrefly/pyrefly/lib/alt/solve.rs:1847:36
  20: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::binding_to_type_info
             at ./fbcode/pyrefly/pyrefly/lib/alt/solve.rs:1559:33
  21: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::solve_binding
             at ./fbcode/pyrefly/pyrefly/lib/alt/solve.rs:974:29
  22: <pyrefly::graph::calculation::Calculation<alloc::sync::Arc<pyrefly::types::type_info::TypeInfo>, pyrefly::types::types::Var>>::calculate_with_recursive::<<pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::get_idx<pyrefly::binding::binding::Key>::{closure#0}, <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::get_idx<pyrefly::binding::binding::Key>::{closure#1}>
             at ./fbcode/pyrefly/pyrefly/lib/alt/traits.rs:116:9
  23: <pyrefly::alt::answers::AnswersSolver<pyrefly::state::state::TransactionHandle>>::get_idx::<pyrefly::binding::binding::Key>
             at ./fbcode/pyrefly/pyrefly/lib/alt/answers.rs:643:22
  24: <pyrefly::alt::answers::Answers>::solve::<pyrefly::state::state::TransactionHandle>
             at ./fbcode/pyrefly/pyrefly/lib/alt/answers.rs:426:25
  25: <pyrefly::state::steps::Step>::step_solutions::<pyrefly::state::state::TransactionHandle>
             at ./fbcode/pyrefly/pyrefly/lib/state/steps.rs:194:25
  26: <<pyrefly::state::steps::Step>::compute<pyrefly::state::state::TransactionHandle>::{closure#4}::{closure#0} as core::ops::function::FnOnce<(&pyrefly::state::steps::Context<pyrefly::state::state::TransactionHandle>,)>>::call_once::{shim:vtable#0}
             at ./fbcode/pyrefly/pyrefly/lib/state/steps.rs:99:27
  27: <pyrefly::state::state::Transaction>::demand
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/alloc/src/boxed.rs:1976:9
  28: <pyrefly::util::task_heap::TaskHeap<pyrefly::state::steps::Step, pyrefly::util::arc_id::ArcId<pyrefly::state::state::ModuleDataMut>>>::work::<<pyrefly::state::state::Transaction>::work::{closure#0}>
             at ./fbcode/pyrefly/pyrefly/lib/state/state.rs:922:13
  29: <rayon_core::job::HeapJob<<rayon_core::scope::Scope>::spawn<<pyrefly::util::thread_pool::ThreadPool>::spawn_many<<pyrefly::state::state::Transaction>::run_step::{closure#1}>::{closure#0}::{closure#0}>::{closure#0}> as rayon_core::job::Job>::execute
             at ./fbcode/pyrefly/pyrefly/lib/state/state.rs:921:9
  30: <rayon_core::registry::WorkerThread>::wait_until_cold
             at ./third-party/rust/vendor/rayon-core-1.12.1/src/job.rs:64:9
  31: <rayon_core::registry::ThreadBuilder>::run
             at ./third-party/rust/vendor/rayon-core-1.12.1/src/registry.rs:769:13
  32: std::sys::backtrace::__rust_begin_short_backtrace::<<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}, ()>
             at ./third-party/rust/vendor/rayon-core-1.12.1/src/registry.rs:98:20
  33: <<std::thread::Builder>::spawn_unchecked_<<rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{closure#0}, ()>::{closure#1} as core::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/std/src/thread/mod.rs:559:17
  34: <std::sys::pal::unix::thread::Thread>::new::thread_start
             at ./xplat/rust/toolchain/sysroot/1.86.0/library/alloc/src/boxed.rs:1976:9
  35: start_thread
             at /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/nptl/pthread_create.c:434:8
  36: __clone3
             at /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81:0

Codebase

No response

Other Attempts

No response

[yangdanny97]

This appears to be in the subtyping logic, what change did you make to that class, and are you able to make a minimal repro?

[kinto0]

According to OP he changed the name of the class to something else. I'm trying this and can't reproduce it.

[stroxler]

I know where the problem is coming from to a moderate level of detail, but I can't figure out a probable root cause

Line 996 is a tparams comparison inside self.targs, whose only caller is the ClassType vs ClassType code

It looks like the only possible scenario leading to this panic is that

 self.type_order.as_superclass(got, want.class_object())

results in

Some(got)

and got (the second one) has 1 type argument whereas want has 2 type arguments.

But the implementation of as_superclass relies on get_ancestor, which checks for exact equality of the two class objects, and then it just performs a substitution. And the type parameters are part of the class object, so equality of class objects should ensure that the tparam lengths are the same.

As far as I can tell, that means that either:

• we are constructing a ClassType with the wrong number of targs relative to the number of tparams (most likely in MRO)
• the substitute operation is somehow changing the number of type arguments

Neither of these seems likely to me intuitively, but my guess is that it's the base class traversal causing it: I'm nearly certain that sustitute can't do this because it's implemented as a map operation, whereas it's much harder to be certain we cannot construct a bad ClassType (certainly we can construct one manually, e.g. if stdlib is used improperly)

[stroxler]

Okay I'm reasonably certain now that what's really happening is we have two non-equal Class values that compare as equal in the middle of an incremental update - it is not possible to create a ClassType with a mismatched targs arity, so this is the only way to get a mismatch that I can see.

The Class equality check is based on a lookup key, not on structure, so it's pretty easy to see how this could potentially occur if we have a mix of updated and dirty modules.

Fixing it probably means understanding incremental updates at a good level of detail because we need to work out whether this is an avoidable state that incremental should have caught, or we actually need to handle dirty states with mismatched tparam arities on the same class.