Generate dataclass ordering methods only on the decorated class

Summary:
Pyrefly synthesized `__lt__`/`__le__`/`__gt__`/`__ge__` (plus `__eq__`/`__ne__`) on every class carrying ordered dataclass metadata, including plain subclasses that only inherit it. At runtime only the decorated class gets these methods, and subclasses inherit them. This caused two problems:
- Plain subclasses showed signatures typed against themselves (`(self: C, other: C)` rather than `D`'s).
- A user override between the dataclass and a plain subclass was hidden. For example, a `__ge__(self, other: object)` defined on an intermediate class still produced a false `unsupported-operation` error on its subclasses.

The methods are now only synthesized when the class's dataclass metadata is its own (`!is_inherited`). With that, and with `total_ordering` no longer inventing comparison methods (previous diff), a normal member lookup reports the methods a class really uses. So `ordered-dataclass-inheritance` now uses that lookup instead of its own walk over class bodies.

___

landed-with-radar-review

Differential Revision: D126992834

fbshipit-source-id: b870886b6f15041b9a9ab780f61068c017e22b3a

Author: connernilsen

pyrefly/lib/alt/class/dataclass.rs

@@ -223,7 +223,9 @@ impl<'ctx, 'answer, Ans: LookupAnswer> AnswersSolver<'ctx, 'answer, Ans> {
             ClassSynthesizedField::new_classvar(self.heap.mk_class_type(dataclass_fields_type)),
         );
 
-        if dataclass.kws.order {
+        // Only the decorated class gets these methods at runtime. Subclasses that merely inherit
+        // the metadata inherit the methods, including any override defined in between.
+        if dataclass.kws.order && !dataclass.is_inherited {
             fields.extend(self.get_dataclass_rich_comparison_methods(cls));
         }
         if dataclass.kws.match_args {

pyrefly/lib/alt/solve.rs

@@ -3310,9 +3310,7 @@ impl<'ctx, 'answer, Ans: LookupAnswer> AnswersSolver<'ctx, 'answer, Ans> {
 
     /// Stdlib dataclass ordering methods only compare instances of the exact same class, so
     /// comparing instances of a class and its base raises `TypeError` when both fall back to such
-    /// generated methods. Which methods a class uses is resolved by walking its MRO through class
-    /// bodies, because pyrefly also synthesizes ordering methods on classes that merely inherit
-    /// dataclass metadata, which would hide user-defined overrides from a member lookup.
+    /// generated methods.
     fn check_ordered_dataclass_inheritance(
         &self,
         cls: &Class,
@@ -3324,29 +3322,33 @@ impl<'ctx, 'answer, Ans: LookupAnswer> AnswersSolver<'ctx, 'answer, Ans> {
         if metadata.is_new_type() || metadata.dataclass_metadata().is_none() {
             return;
         }
-        // The class whose generated exact-class ordering method `c` uses for `op`, if any.
+        // The class whose generated exact-class ordering method `c` uses for `op`, if any. A
+        // member that its defining class does not declare in its body was synthesized there; it
+        // is a generated exact-class method only if that class has its own ordered stdlib
+        // dataclass metadata.
         let generator_for = |c: &Class, op: &Name| -> Option<Class> {
-            let mro = self.get_mro_for_class(c);
-            for k in iter::once(c).chain(mro.ancestors_no_object().iter().map(|a| a.class_object()))
+            let defining_class = self
+                .get_class_member_with_defining_class(c, op)?
+                .defining_class;
+            if self
+                .get_class_fields(&defining_class)
+                .is_some_and(|f| f.contains(op))
             {
-                if self.get_class_fields(k).is_some_and(|f| f.contains(op)) {
-                    return None;
-                }
-                if let Some(dm) = self.get_metadata_for_class(k).dataclass_metadata()
-                    && !dm.is_inherited
-                    && dm.kws.order
-                {
-                    return matches!(
-                        dm.kind,
-                        DataclassKind::Dataclass {
-                            is_stdlib_dataclass: true,
-                            ..
-                        }
-                    )
-                    .then(|| k.dupe());
-                }
+                return None;
             }
-            None
+            let dm = self
+                .get_metadata_for_class(&defining_class)
+                .dataclass_metadata()?;
+            (dm.kws.order
+                && !dm.is_inherited
+                && matches!(
+                    dm.kind,
+                    DataclassKind::Dataclass {
+                        is_stdlib_dataclass: true,
+                        ..
+                    }
+                ))
+            .then_some(defining_class)
         };
         // `cls() < base()` tries `cls.__lt__` and then the reflected `base.__gt__`, so it fails
         // when both are generated. User-defined methods are assumed to accept mixed instances.

pyrefly/lib/test/dataclasses.rs

@@ -1308,6 +1308,32 @@ class E(C):  # E: Cannot safely extend dataclass `D` with `order=True`
     "#,
 );
 
+// Only the decorated class gets generated ordering methods at runtime; subclasses inherit them.
+testcase!(
+    test_ordering_methods_inherited_by_subclass,
+    r#"
+from dataclasses import dataclass
+from typing import reveal_type
+@dataclass(order=True)
+class D:
+    x: int
+
+class C(D):  # E: Cannot safely extend dataclass `D` with `order=True`
+    pass
+
+reveal_type(C.__lt__)  # E: revealed type: (self: D, other: D) -> bool
+
+class OverridesGe(D):  # E: Cannot safely extend dataclass `D` with `order=True`
+    def __ge__(self, other: object) -> bool:
+        return True
+
+class InheritsGe(OverridesGe):  # E: Cannot safely extend dataclass `D` with `order=True`
+    pass
+
+InheritsGe(1) >= 3
+    "#,
+);
+
 testcase!(
     test_parent_dataclass_with_order_overridden,
     r#"

pyrefly/lib/test/decorators.rs

@@ -590,7 +590,12 @@ class OwnLt(D):  # E: Cannot safely extend dataclass `D` with `order=True`
     def __lt__(self, other: object) -> bool:
         return True
 
-reveal_type(OwnLt.__gt__)  # E: revealed type: (self: OwnLt, other: OwnLt) -> bool
+reveal_type(OwnLt.__gt__)  # E: revealed type: (self: D, other: D) -> bool
+
+# `OwnLt` still uses `D`'s generated `__gt__`, so comparing it with `OrderedOverOwnLt` can fail.
+@dataclass(order=True)
+class OrderedOverOwnLt(OwnLt):  # E: Cannot safely extend dataclass `D` with `order=True`
+    y: int = 0
 "#,
 );
 
@@ -615,6 +620,32 @@ reveal_type(B.__ge__)  # E: revealed type: (self: B, other: A) -> bool
 "#,
 );
 
+// Methods that `total_ordering` fills in on a mixin are user-defined as far as the dataclass is
+// concerned, so they replace the dataclass's generated methods that come later in the MRO.
+testcase!(
+    test_total_ordering_mixin_before_ordered_dataclass,
+    r#"
+from dataclasses import dataclass
+from functools import total_ordering
+
+@dataclass(order=True)
+class D:
+    x: int
+
+@total_ordering
+class Mix:
+    def __lt__(self, other: object) -> bool:
+        return True
+
+class C(Mix, D):
+    pass
+
+@dataclass(order=True)
+class E(C):
+    y: int = 0
+"#,
+);
+
 testcase!(
     test_total_ordering_inherited_rich_cmp,
     r#"