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] Handle StringLiteral truncation #13276

Merged
merged 7 commits into from
Sep 8, 2024

Conversation

dylwil3
Copy link
Contributor

@dylwil3 dylwil3 commented Sep 7, 2024

When a type of the form Literal["..."] would be constructed with too large of a string, this PR converts it to LiteralString instead.

We also extend inference for binary operations to include the case where one of the operands is LiteralString.

Closes #13224

Copy link
Contributor

github-actions bot commented Sep 7, 2024

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Copy link
Contributor

@carljm carljm left a 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!!

Comment on lines 2056 to 2061
(
Type::StringLiteral(_) | Type::LiteralString,
Type::LiteralString,
ast::Operator::Add,
)
| (Type::LiteralString, Type::StringLiteral(_), ast::Operator::Add) => {
Copy link
Contributor

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)?

Copy link
Contributor Author

@dylwil3 dylwil3 Sep 7, 2024

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!

Copy link

codspeed-hq bot commented Sep 7, 2024

CodSpeed Performance Report

Merging #13276 will improve performances by 8.54%

Comparing dylwil3:string-literals (c3c9ac7) with main (a7c9368)

Summary

⚡ 1 improvements
✅ 31 untouched benchmarks

Benchmarks breakdown

Benchmark main dylwil3:string-literals Change
linter/all-with-preview-rules[numpy/globals.py] 883.7 µs 814.1 µs +8.54%

@carljm carljm merged commit e4aa479 into astral-sh:main Sep 8, 2024
20 checks passed
@dylwil3 dylwil3 deleted the string-literals branch September 8, 2024 04:27
@dhruvmanila dhruvmanila added the red-knot Multi-file analysis & type inference label Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[red-knot] Fixes for string literal handling
3 participants