From ef0343189c185f95892f3d4294bcf51243ebafca Mon Sep 17 00:00:00 2001 From: Carl Meyer Date: Thu, 24 Apr 2025 14:41:19 -0700 Subject: [PATCH] [red-knot] add TODO comment in specialization code (#17615) ## Summary As promised, this just adds a TODO comment to document something we discussed today that should probably be improved at some point, but isn't a priority right now (since it's an issue that in practice would only affect generic classes with both `__init__` and `__new__` methods, where some typevar is bound to `Unknown` in one and to some other type in another.) --- crates/red_knot_python_semantic/src/types/generics.rs | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/crates/red_knot_python_semantic/src/types/generics.rs b/crates/red_knot_python_semantic/src/types/generics.rs index 66cd67f263..b1c0355ebf 100644 --- a/crates/red_knot_python_semantic/src/types/generics.rs +++ b/crates/red_knot_python_semantic/src/types/generics.rs @@ -154,6 +154,10 @@ impl<'db> Specialization<'db> { pub(crate) fn combine(self, db: &'db dyn Db, other: Self) -> Self { let generic_context = self.generic_context(db); assert!(other.generic_context(db) == generic_context); + // TODO special-casing Unknown to mean "no mapping" is not right here, and can give + // confusing/wrong results in cases where there was a mapping found for a typevar, and it + // was of type Unknown. We should probably add a bitset or similar to Specialization that + // explicitly tells us which typevars are mapped. let types: Box<[_]> = self .types(db) .into_iter()