-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[ty] Avoid unnecessarily widening generic specializations #20875
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1233,24 +1233,37 @@ impl<'db> Type<'db> { | |
| if yes { self.negate(db) } else { *self } | ||
| } | ||
|
|
||
| /// Remove the union elements that are not related to `target`. | ||
| pub(crate) fn filter_disjoint_elements( | ||
| /// If the type is a union, filters union elements based on the provided predicate. | ||
| /// | ||
| /// Otherwise, returns the type unchanged. | ||
| pub(crate) fn filter_union( | ||
| self, | ||
| db: &'db dyn Db, | ||
| target: Type<'db>, | ||
| inferable: InferableTypeVars<'_, 'db>, | ||
| f: impl FnMut(&Type<'db>) -> bool, | ||
| ) -> Type<'db> { | ||
| if let Type::Union(union) = self { | ||
| union.filter(db, |elem| { | ||
| !elem | ||
| .when_disjoint_from(db, target, inferable) | ||
| .is_always_satisfied() | ||
| }) | ||
| union.filter(db, f) | ||
| } else { | ||
| self | ||
| } | ||
| } | ||
|
|
||
| /// If the type is a union, removes union elements that are disjoint from `target`. | ||
| /// | ||
| /// Otherwise, returns the type unchanged. | ||
| pub(crate) fn filter_disjoint_elements( | ||
| self, | ||
| db: &'db dyn Db, | ||
| target: Type<'db>, | ||
| inferable: InferableTypeVars<'_, 'db>, | ||
| ) -> Type<'db> { | ||
| self.filter_union(db, |elem| { | ||
| !elem | ||
| .when_disjoint_from(db, target, inferable) | ||
| .is_always_satisfied() | ||
| }) | ||
| } | ||
|
|
||
| /// Returns the fallback instance type that a literal is an instance of, or `None` if the type | ||
| /// is not a literal. | ||
| pub(crate) fn literal_fallback_instance(self, db: &'db dyn Db) -> Option<Type<'db>> { | ||
|
|
@@ -11185,9 +11198,9 @@ impl<'db> UnionType<'db> { | |
| pub(crate) fn filter( | ||
| self, | ||
| db: &'db dyn Db, | ||
| filter_fn: impl FnMut(&&Type<'db>) -> bool, | ||
| mut f: impl FnMut(&Type<'db>) -> bool, | ||
| ) -> Type<'db> { | ||
| Self::from_elements(db, self.elements(db).iter().filter(filter_fn)) | ||
| Self::from_elements(db, self.elements(db).iter().filter(|ty| f(ty))) | ||
|
Comment on lines
-11188
to
+11203
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we make the callback take in
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ibraheem's current signature matches the signature for
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 I agree with keeping them consistent, but feel strongly enough about avoiding
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are some
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the last time we discussed it, we decided that it was pretty borderline but that it was probably slightly more efficient for methods like that to take |
||
| } | ||
|
|
||
| pub(crate) fn map_with_boundness( | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The churn here could be avoided if we performed a third specialization, inferring the call expression annotation first before the argument types, but I'm not sure it's worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a TODO below indicating where we'd make the change if we wanted to fix this, so I'm 👍 to this. Though maybe add a TODO comment here, too, calling out that we realize that we reordered the union, and that we know how we'd fix it?