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

[red-knot] Infer Todo, not Unknown, for PEP-604 unions in annotations #13908

Merged
merged 2 commits into from
Oct 25, 2024
Merged

[red-knot] Infer Todo, not Unknown, for PEP-604 unions in annotations #13908

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
36f7362
[red-knot] Infer `Todo`, not `Unknown`, for PEP-604 unions in annotat…
AlexWaygood Oct 24, 2024
6a9cc35
fixups
AlexWaygood Oct 25, 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
10 changes: 10 additions & 0 deletions crates/red_knot_python_semantic/resources/mdtest/assignment/annotations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,3 +22,13 @@ x: int = "foo" # error: [invalid-assignment] "Object of type `Literal["foo"]` i
x: int
x = "foo" # error: [invalid-assignment] "Object of type `Literal["foo"]` is not assignable to `int`"
```

## PEP-604 annotations not yet supported

```py
def f() -> str | None:
return None

# TODO: should be `str | None` (but Todo is better than `Unknown`)
reveal_type(f()) # revealed: @Todo
```
7 changes: 7 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 @@ -220,6 +220,9 @@ fn declarations_ty<'db>(
} else {
first
};
// Make sure not to emit spurious errors relating to `Type::Todo`,
// since we only infer this type due to a limitation in our current model
conflicting.retain(|ty| !ty.is_todo());
if conflicting.is_empty() {
Ok(declared_ty)
} else {
Expand Down Expand Up @@ -292,6 +295,10 @@ impl<'db> Type<'db> {
matches!(self, Type::Never)
}

pub const fn is_todo(&self) -> bool {
matches!(self, Type::Todo)
}

pub const fn into_class_literal_type(self) -> Option<ClassType<'db>> {
match self {
Type::ClassLiteral(class_type) => Some(class_type),
Expand Down
10 changes: 6 additions & 4 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 @@ -3471,6 +3471,12 @@ impl<'db> TypeInferenceBuilder<'db> {
Type::Todo
}

// TODO PEP-604 unions
ast::Expr::BinOp(binary) => {
self.infer_binary_expression(binary);
Type::Todo
Copy link
Contributor

Choose a reason for hiding this comment

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

I think actually supporting this would take only like three lines here, plus some tests 😆 maybe a good task for @charliermarsh

Copy link
Member

Choose a reason for hiding this comment

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

I can do it!

}

// Forms which are invalid in the context of annotation expressions: we infer their
// nested expressions as normal expressions, but the type of the top-level expression is
// always `Type::Unknown` in these cases.
Expand All @@ -3482,10 +3488,6 @@ impl<'db> TypeInferenceBuilder<'db> {
self.infer_named_expression(named);
Type::Unknown
}
ast::Expr::BinOp(binary) => {
self.infer_binary_expression(binary);
Type::Unknown
}
ast::Expr::UnaryOp(unary) => {
self.infer_unary_expression(unary);
Type::Unknown
Expand Down
Loading