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] Make Type::in_type_expression() exhaustive #15048

Open
AlexWaygood opened this issue Dec 18, 2024 · 0 comments
Open

[red-knot] Make Type::in_type_expression() exhaustive #15048

AlexWaygood opened this issue Dec 18, 2024 · 0 comments
Labels
help wanted Contributions especially welcome red-knot Multi-file analysis & type inference

Comments

@AlexWaygood
Copy link
Member

Type::in_type_expression() already errors for some types that are invalid in type expression contexts:

// TODO: Should emit a diagnostic
Type::KnownInstance(KnownInstanceType::Annotated) => Err(InvalidTypeExpressionError {
invalid_expressions: smallvec::smallvec![InvalidTypeExpression::BareAnnotated],
fallback_type: Type::Unknown,
}),
Type::KnownInstance(KnownInstanceType::Literal) => Err(InvalidTypeExpressionError {
invalid_expressions: smallvec::smallvec![InvalidTypeExpression::BareLiteral],
fallback_type: Type::Unknown,
}),
Type::Todo(_) => Ok(*self),
_ => Ok(todo_type!(
"Unsupported or invalid type in a type expression"
)),

However, there are many other types that are invalid in type expression contexts. We should remove the final fallback branch from this match statement and make it exhaustive so that all typing errors are correctly reported.

I expect that many invalid types can be covered by a single branch. Doing so might require changing this method so that its return type is std::fmt::Arguments rather than &'static str:

impl InvalidTypeExpression {
const fn reason(self) -> &'static str {
match self {
Self::BareAnnotated => "`Annotated` requires at least two arguments when used in an annotation or type expression",
Self::BareLiteral => "`Literal` requires at least one argument when used in a type expression",
}
}
}

@AlexWaygood AlexWaygood added help wanted Contributions especially welcome red-knot Multi-file analysis & type inference labels Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Contributions especially welcome red-knot Multi-file analysis & type inference
Projects
None yet
Development

No branches or pull requests

1 participant