[ty] Prefer reflected operators by runtime class

Author: charliermarsh

crates/ty_python_semantic/resources/mdtest/binary/instances.md

@@ -218,6 +218,54 @@ class C(B): ...
 reveal_type(A() + C())  # revealed: MyString
 ```
 
+## Reflected precedence uses runtime classes
+
+`IntFlag` values are commonly accumulated into a mask that starts at the integer zero. At runtime,
+the first `|=` produces a `Permission`, because reflected-method precedence depends on the operands'
+runtime classes. The enum literal is not a subtype of the specific integer literal `0`, but its
+runtime class is a strict subclass of `int`:
+
+```py
+from enum import IntFlag, auto
+
+class Permission(IntFlag):
+    READ = auto()
+    WRITE = auto()
+
+def permissions_for(editable: bool) -> Permission:
+    permissions = 0
+    permissions |= Permission.READ
+    reveal_type(permissions)  # revealed: Literal[Permission.READ]
+
+    if editable:
+        permissions |= Permission.WRITE
+
+    return permissions
+```
+
+## Bounded TypeVars do not have an exact runtime class
+
+The upper bound of a TypeVar is not necessarily its runtime class. The bound therefore cannot be
+used to decide whether the right-hand operand's reflected method takes precedence:
+
+```py
+from typing import Literal, TypeVar
+
+class Base:
+    def __add__(self, other: object) -> Literal["base"]:
+        return "base"
+
+class Child(Base):
+    def __radd__(self, other: object) -> Literal["child"]:
+        return "child"
+
+T = TypeVar("T", bound=Base)
+
+def add_child(left: T) -> Literal["base"]:
+    reveal_type(left + Child())  # revealed: Literal["base"]
+    return left + Child()
+```
+
 ## Reflected precedence 2
 
 If the right-hand operand is a subtype of the left-hand operand, but does not override the reflected

crates/ty_python_semantic/src/types/call.rs

@@ -62,13 +62,28 @@ impl<'db> Type<'db> {
         //
         // [1] https://docs.python.org/3/reference/datamodel.html#object.__radd__
 
-        // Technically we don't have to check left_ty != right_ty here, since if the types
-        // are the same, they will trivially have the same implementation of the reflected
-        // dunder, and so we'll fail the inner check. But the type equality check will be
-        // faster for the common case, and allow us to skip the (two) class member lookups.
+        // Reflected-method precedence is based on the operands' runtime classes, not on whether
+        // one value type is a subtype of the other. This matters for literals: an enum literal can
+        // have a class that is a strict subclass of `int` even though it is not a subtype of a
+        // specific integer literal.
+        //
+        // Technically, the type equality check is not required for correctness: equal value types
+        // have the same runtime class and reflected implementation. It provides a fast path for
+        // the common case and avoids the runtime-class checks and two class member lookups below.
+        let right_is_strict_subclass = left_ty != right_ty
+            && match (left_ty.nominal_class(db), right_ty.nominal_class(db)) {
+                (Some(left_class), Some(right_class))
+                    if !left_ty.is_type_var() && !right_ty.is_type_var() =>
+                {
+                    left_class.class_literal(db) != right_class.class_literal(db)
+                        && right_class.is_subclass_of(db, left_class)
+                }
+                _ => right_ty.is_subtype_of(db, left_ty),
+            };
+
         let left_class = left_ty.to_meta_type(db);
         let right_class = right_ty.to_meta_type(db);
-        if left_ty != right_ty && right_ty.is_subtype_of(db, left_ty) {
+        if right_is_strict_subclass {
             let reflected_dunder = op.reflected_dunder();
             let rhs_reflected = right_class.member(db, reflected_dunder).place;
             // TODO: if `rhs_reflected` is possibly unbound, we should union the two possible