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.

Sign up for GitHub

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

Jump to bottom

red-knot: infer and display ellipsis type #13124

Merged
merged 3 commits into from
Aug 27, 2024
Merged

red-knot: infer and display ellipsis type #13124

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bf33754
red-knot: infer and display ellipsis type
chriskrycho Aug 26, 2024
f83a6f5
red-knot: simplify handling for Ellipsis type
chriskrycho Aug 27, 2024
44248a7
Update crates/red_knot_python_semantic/src/types/infer.rs
carljm Aug 27, 2024
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
6 changes: 6 additions & 0 deletions crates/red_knot_python_semantic/src/types.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,8 @@ pub enum Type<'db> {
LiteralString,
/// A bytes literal
BytesLiteral(BytesLiteralType<'db>),
/// `...`
EllipsisType,
// TODO protocols, callable types, overloads, generics, type vars
}

Expand Down Expand Up @@ -297,6 +299,10 @@ impl<'db> Type<'db> {
// TODO defer to Type::Instance(<bytes from typeshed>).member
Type::Unknown
}
Type::EllipsisType => {
// TODO: attribute lookup on Ellipsis type
Type::Unknown
}
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure this needs to be its own variant in the Type enum... it's conceptually just an instance of types.EllipsisType. types.EllipsisType was only exposed on Python 3.10+, but typeshed already provides a nice little compatibility workaround for us here: https://github.com/python/typeshed/blob/f58dac1d62d33bb2255b762783d06463c40f5065/stdlib/builtins.pyi#L1849-L1865

(builtins.Ellipsis is the same object as ...)

>>> ...
Ellipsis
>>> Ellipsis
Ellipsis
>>> Ellipsis is ...
True

Copy link
Member

Choose a reason for hiding this comment

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

One interesting way in which ... is special is that it's a singleton: it is the only instance of types.EllipsisType that there is, or that there could be. But that can be thought of as just a sealed type that has exactly one member, and we've yet to implement a generalised way of handling sealed types. (We'll need them to tackle enums in Python!) See #12694.

}
}

Expand Down
1 change: 1 addition & 0 deletions crates/red_knot_python_semantic/src/types/display.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,6 +55,7 @@ impl Display for DisplayType<'_> {
escape.bytes_repr().write(f)?;
f.write_str("]")
}
Type::EllipsisType => write!(f, "EllipsisType"),
}
}
}
Expand Down
19 changes: 17 additions & 2 deletions crates/red_knot_python_semantic/src/types/infer.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1337,8 +1337,7 @@ impl<'db> TypeInferenceBuilder<'db> {
&mut self,
_literal: &ast::ExprEllipsisLiteral,
) -> Type<'db> {
// TODO Ellipsis
Type::Unknown
Type::EllipsisType
chriskrycho marked this conversation as resolved.
Show resolved Hide resolved
}

fn infer_tuple_expression(&mut self, tuple: &ast::ExprTuple) -> Type<'db> {
Expand Down Expand Up @@ -2470,6 +2469,22 @@ mod tests {
Ok(())
}

#[test]
fn ellipsis_type() -> anyhow::Result<()> {
let mut db = setup_db();

db.write_dedented(
"src/a.py",
"
x = ...
",
)?;

assert_public_ty(&db, "src/a.py", "x", "EllipsisType");

Ok(())
}

#[test]
fn resolve_union() -> anyhow::Result<()> {
let mut db = setup_db();
Expand Down
Loading