Repository navigation
fix: prevent newlines around quotes in macro invocations - #7157
penguinawesome1 wants to merge 4 commits into
Conversation
rustbot
added
the
S-waiting-on-review
7bc8e47 to
2d6da3a
Compare
| // Handle special case where there is one argument, | ||
| // a string literal containing a newline. | ||
| if let [MacroArg::Expr(expr)] = arg_vec.as_slice() { | ||
| if let ast::ExprKind::Lit(lit) = expr.kind { | ||
| if lit.kind == LitKind::Str && lit.symbol.as_str().contains("\n") { | ||
| let rw = format!("{}(\"{}\")", macro_name, lit.symbol); | ||
| return match position { | ||
| MacroPosition::Item => Ok(format!("{};", rw)), | ||
| _ => Ok(rw), | ||
| }; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Remark: this feels very special-cased and somewhat strange to me. I agree the existing formatting doesn't seem great, but I'm not convinced special-casing here makes sense either.
There was a problem hiding this comment.
I agree that the special case in macros.rs seems out of place.
I was trying to figure out where function macros and normal functions diverged, since they both call rewrite in overflow.rs.
I figured out that it's due to this code here:
Lines 485 to 489 in ff02051
Interestingly, the only reason foo and foo! are different is because the exclamation point is included in the identifier length. When tab spaces are 4, foo is shorter than 4, so only it was eligible for overflow. This means my solution shouldn't exclusively target macros, but should affect functions too.
Instead of modifying that, I just made it so literals can sometimes overflow (when a single argument contains a newline in edition 2027).
2d6da3a to
75205d0
Compare
This comment has been minimized.
This comment has been minimized.
| ast::ExprKind::Lit(lit) => { | ||
| context.config.style_edition() >= StyleEdition::Edition2027 | ||
| && args_len == 1 | ||
| && lit.kind == LitKind::Str | ||
| && lit.symbol.as_str().contains('\n') | ||
| } |
There was a problem hiding this comment.
Shouldn't we also check that the first line of the string literal fits within max_width?
Can you add some test cases where the first line of the string literal is at exactly the max_width after reformatting and then max_width + 1.
There was a problem hiding this comment.
I added the test cases, and the formatter moves the string to a new line once the line reaches max_width - 1.
Is this intentional, or possibly a known issue? To my understanding, it should only do that once the line exceeds max_width.
ytmimi
added
S-waiting-on-author
53ce7c1 to
0f2d98f
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@rustbot ready |
rustbot
added
S-waiting-on-review
This branch has not been deployed
4 participants
Fixes formatting for string literals that contain a newline in macro invocations.
Closes #5029
Used to review Rust syntax and for a sanity check (reminded me to use
as_strinstead ofto_string).