Skip to content
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

[red-knot] Fix .to_instance() for union types #13319

Merged
merged 2 commits into from
Sep 10, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 20 additions & 2 deletions crates/red_knot_python_semantic/src/types.rs
Original file line number Diff line number Diff line change
Expand Up @@ -445,12 +445,30 @@ impl<'db> Type<'db> {
}

#[must_use]
pub fn to_instance(&self) -> Type<'db> {
pub fn to_instance(&self, db: &'db dyn Db) -> Type<'db> {
match self {
Type::Any => Type::Any,
Type::Unknown => Type::Unknown,
Type::Never => Type::Never,
Type::Class(class) => Type::Instance(*class),
_ => Type::Unknown, // TODO type errors
Type::Union(union) => union.map(db, |element| element.to_instance(db)),
// TODO: we can probably do better here: --Alex
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - it should just be a map over the elements resulting in a new intersection, as far as positive elements of the intersection go. But negative elements make it a bit tricky. I think maybe they would just get discarded, but I need to think about it more. Doesn't need to be handled in this PR, anyway.

Type::Intersection(_) => Type::Unknown,
// TODO: converting to `Unknown` here is probably correct,
// but should result in a diagnostic reporting the use of an unbound name:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This diagnostic should be handled by just visiting all Name exprs with Load context and checking if their type is unbound, it shouldn't be handled in every method of Type where we see an Unbound. So I'm not sure we need a TODO for it here.

(TBH I'm getting more and more convinced that Unbound should not be a Type variant at all.)

Type::Unbound => Type::Unknown,
// TODO: calling `.to_instance()` on any of these should result in a diagnostic,
// since they already indicate that the object is an instance of some kind:
Type::BooleanLiteral(_)
| Type::BytesLiteral(_)
| Type::Function(_)
| Type::Instance(_)
| Type::Module(_)
| Type::IntLiteral(_)
| Type::StringLiteral(_)
| Type::Tuple(_)
| Type::LiteralString
| Type::None => Type::Unknown,
}
}

Expand Down
24 changes: 13 additions & 11 deletions crates/red_knot_python_semantic/src/types/infer.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1457,9 +1457,11 @@ impl<'db> TypeInferenceBuilder<'db> {
ast::Number::Int(n) => n
.as_i64()
.map(Type::IntLiteral)
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance()),
ast::Number::Float(_) => builtins_symbol_ty(self.db, "float").to_instance(),
ast::Number::Complex { .. } => builtins_symbol_ty(self.db, "complex").to_instance(),
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance(self.db)),
ast::Number::Float(_) => builtins_symbol_ty(self.db, "float").to_instance(self.db),
ast::Number::Complex { .. } => {
builtins_symbol_ty(self.db, "complex").to_instance(self.db)
}
}
}

Expand Down Expand Up @@ -1573,7 +1575,7 @@ impl<'db> TypeInferenceBuilder<'db> {
}

// TODO generic
builtins_symbol_ty(self.db, "list").to_instance()
builtins_symbol_ty(self.db, "list").to_instance(self.db)
}

fn infer_set_expression(&mut self, set: &ast::ExprSet) -> Type<'db> {
Expand All @@ -1584,7 +1586,7 @@ impl<'db> TypeInferenceBuilder<'db> {
}

// TODO generic
builtins_symbol_ty(self.db, "set").to_instance()
builtins_symbol_ty(self.db, "set").to_instance(self.db)
}

fn infer_dict_expression(&mut self, dict: &ast::ExprDict) -> Type<'db> {
Expand All @@ -1596,7 +1598,7 @@ impl<'db> TypeInferenceBuilder<'db> {
}

// TODO generic
builtins_symbol_ty(self.db, "dict").to_instance()
builtins_symbol_ty(self.db, "dict").to_instance(self.db)
}

/// Infer the type of the `iter` expression of the first comprehension.
Expand Down Expand Up @@ -2067,22 +2069,22 @@ impl<'db> TypeInferenceBuilder<'db> {
(Type::IntLiteral(n), Type::IntLiteral(m), ast::Operator::Add) => n
.checked_add(m)
.map(Type::IntLiteral)
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance()),
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance(self.db)),

(Type::IntLiteral(n), Type::IntLiteral(m), ast::Operator::Sub) => n
.checked_sub(m)
.map(Type::IntLiteral)
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance()),
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance(self.db)),

(Type::IntLiteral(n), Type::IntLiteral(m), ast::Operator::Mult) => n
.checked_mul(m)
.map(Type::IntLiteral)
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance()),
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance(self.db)),

(Type::IntLiteral(n), Type::IntLiteral(m), ast::Operator::Div) => n
.checked_div(m)
.map(Type::IntLiteral)
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance()),
.unwrap_or_else(|| builtins_symbol_ty(self.db, "int").to_instance(self.db)),

(Type::IntLiteral(n), Type::IntLiteral(m), ast::Operator::Mod) => n
.checked_rem(m)
Expand Down Expand Up @@ -2311,7 +2313,7 @@ impl<'db> TypeInferenceBuilder<'db> {
name.ctx
);

self.infer_name_expression(name).to_instance()
self.infer_name_expression(name).to_instance(self.db)
}

ast::Expr::NoneLiteral(_literal) => Type::None,
Expand Down
Loading