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

Improve API exposed on ExprStringLiteral nodes #16192

Merged
merged 1 commit into from
Feb 17, 2025
Merged

Conversation

AlexWaygood
Copy link
Member

Summary

This PR makes the following changes:

  • It adjusts various callsites to use the new ast::StringLiteral::contents_range() method that was introduced in Reduce memory usage of Docstring struct #16183. This is less verbose and more type-safe than using the ast::str::raw_contents() helper function.
  • It adds a new ast::ExprStringLiteral::as_unconcatenated_literal() helper method, and adjusts various callsites to use it. This addresses @MichaReiser's review comment at Reduce memory usage of Docstring struct #16183 (comment). There is no functional change here, but it helps readability to make it clearer that we're differentiating between implicitly concatenated strings and unconcatenated strings at various points.
  • It renames the StringLiteralValue::flags() method to StringLiteralFlags::first_literal_flags(). If you're dealing with an implicitly concatenated string string_node, string_node.value.flags().closer_len() could give an incorrect result; this renaming makes it clearer that the StringLiteralFlags instance returned by the method is only guaranteed to give accurate information for the first StringLiteral contained in the ExprStringLiteral node.
  • It deletes the unused BytesLiteralValue::flags() method. This seems prone to misuse in the same way as StringLiteralValue::flags(): if it's an implicitly concatenated bytestring, the BytesLiteralFlags instance returned by the method would only give accurate information for the first BytesLiteral in the bytestring.

Test Plan

cargo test

@AlexWaygood AlexWaygood added the internal An internal refactor or improvement label Feb 16, 2025
Copy link
Contributor

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

impl ExprStringLiteral {
/// Return `Some(literal)` if the string only consists of a single `StringLiteral` part
/// (indicating that it is not implicitly concatenated). Otherwise, return `None`.
pub fn as_unconcatenated_literal(&self) -> Option<&StringLiteral> {
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I wonder if it should be as_only_literal to align with first_literal but I'm fine with either.

Copy link
Member

Choose a reason for hiding this comment

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

I think I'd prefer to use as_single_literal / as_only_literal instead as reading unconcatenated and matching against Single confused me at the first glance

Copy link
Member Author

Choose a reason for hiding this comment

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

I weakly prefer the current name as I think it makes it clearer that the method is used to differentiate between strings that are implicitly concatenated and ones that aren't

Copy link
Member Author

@AlexWaygood AlexWaygood Feb 17, 2025

Choose a reason for hiding this comment

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

Oh shoot, I didn't see Dhruv's message until after I merged — sorry. I'll rename it as a followup, since you both dislike the current name!

impl ExprStringLiteral {
/// Return `Some(literal)` if the string only consists of a single `StringLiteral` part
/// (indicating that it is not implicitly concatenated). Otherwise, return `None`.
pub fn as_unconcatenated_literal(&self) -> Option<&StringLiteral> {
Copy link
Member

Choose a reason for hiding this comment

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

I think I'd prefer to use as_single_literal / as_only_literal instead as reading unconcatenated and matching against Single confused me at the first glance

@AlexWaygood AlexWaygood merged commit b6b1947 into main Feb 17, 2025
21 checks passed
@AlexWaygood AlexWaygood deleted the alex/contents-range branch February 17, 2025 07:58
dcreager added a commit that referenced this pull request Feb 18, 2025
* main: (60 commits)
  [`refurb`] Manual timezone monkeypatching (`FURB162`) (#16113)
  [`pyupgrade`] Do not upgrade functional TypedDicts with private field names to the class-based syntax (`UP013`) (#16219)
  Improve docs for PYI019 (#16229)
  Refactor `CallOutcome` to `Result` (#16161)
  Fix minor punctuation errors (#16228)
  Include document specific debug info (#16215)
  Update server to return the debug info as string (#16214)
  [`airflow`] Group `ImportPathMoved` and `ProviderName` to avoid misusing (`AIR303`) (#16157)
  Fix unstable formatting of trailing end-of-line comments of parenthesized attribute values (#16187)
  Ignore source code actions for a notebook cell (#16154)
  Add FAQ entry for `source.*` code actions in Notebook (#16212)
  red-knot: move symbol lookups in `symbol.rs` (#16152)
  better error messages while loading configuration `extend`s (#15658)
  Format `index.css` (#16207)
  Improve API exposed on `ExprStringLiteral` nodes (#16192)
  Update Rust crate tempfile to v3.17.0 (#16202)
  Update cloudflare/wrangler-action action to v3.14.0 (#16203)
  Update NPM Development dependencies (#16199)
  Update Rust crate smallvec to v1.14.0 (#16201)
  Update Rust crate codspeed-criterion-compat to v2.8.0 (#16200)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal An internal refactor or improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants