Fixed a bug that resulted in incorrect type narrowing when using an in expression and the LHS operand is of type type. This situation requires some special casing.

msfterictraut · msfterictraut · commit 991d8e787f11 · 2022-07-03T10:16:01.000-07:00
diff --git a/packages/pyright-internal/src/analyzer/typeGuards.ts b/packages/pyright-internal/src/analyzer/typeGuards.ts
@@ -1460,6 +1460,12 @@ function narrowTypeForContains(evaluator: TypeEvaluator, referenceType: Type, co
             return referenceSubtype;
         }
 
+        // Handle "type" specially.
+        if (isClassInstance(concreteReferenceType) && ClassType.isBuiltIn(concreteReferenceType, 'type')) {
+            canNarrow = false;
+            return referenceSubtype;
+        }
+
         if (evaluator.assignType(elementType, concreteReferenceType)) {
             return referenceSubtype;
         }
diff --git a/packages/pyright-internal/src/tests/samples/typeNarrowingIn1.py b/packages/pyright-internal/src/tests/samples/typeNarrowingIn1.py
@@ -95,3 +95,10 @@ def func5(x: str | None, y: int | None, z: dict[str, str]):
         reveal_type(y, expected_text="int | None")
     else:
         reveal_type(y, expected_text="Never")
+
+
+def func6(x: type):
+    if x in (str, int, float, bool):
+        reveal_type(x, expected_text="type")
+    else:
+        reveal_type(x, expected_text="type")

Original file line number	Diff line number	Diff line change
`@@ -1460,6 +1460,12 @@ function narrowTypeForContains(evaluator: TypeEvaluator, referenceType: Type, co`
`1460`	`1460`	`return referenceSubtype;`
`1461`	`1461`	`}`
`1462`	`1462`
	`1463`	`+ // Handle "type" specially.`
	`1464`	`+ if (isClassInstance(concreteReferenceType) && ClassType.isBuiltIn(concreteReferenceType, 'type')) {`
	`1465`	`+ canNarrow = false;`
	`1466`	`+ return referenceSubtype;`
	`1467`	`+ }`
	`1468`	`+`
`1463`	`1469`	`if (evaluator.assignType(elementType, concreteReferenceType)) {`
`1464`	`1470`	`return referenceSubtype;`
`1465`	`1471`	`}`