-
Notifications
You must be signed in to change notification settings - Fork 1k
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] Handle StringLiteral truncation #13276
Conversation
|
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.
This is excellent, thank you!!
( | ||
Type::StringLiteral(_) | Type::LiteralString, | ||
Type::LiteralString, | ||
ast::Operator::Add, | ||
) | ||
| (Type::LiteralString, Type::StringLiteral(_), ast::Operator::Add) => { |
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.
Given that match arms are checked in order, and we already handled (StringLiteral, StringLiteral, Add)
above, can we simplify this pattern to ((StringLiteral | LiteralString), (StringLiteral | LiteralString), Add)
?
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.
Good idea! I guess if someone changed around the order one of the unit tests would fail, so this seems pretty safe.
Done!
CodSpeed Performance ReportMerging #13276 will improve performances by 8.54%Comparing Summary
Benchmarks breakdown
|
When a type of the form
Literal["..."]
would be constructed with too large of a string, this PR converts it toLiteralString
instead.We also extend inference for binary operations to include the case where one of the operands is
LiteralString
.Closes #13224