-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add test for #8855 #8857
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
Add test for #8855 #8857
Conversation
r? @flip1995 (rust-highfive has picked a reviewer for you, use r? to override) |
Thanks for this. As you pointed out in #9349 this is closely related to the other format/write/print PRs. So I'll mark this a |
☔ The latest upstream changes (presumably #9349) made this pull request unmergeable. Please resolve the merge conflicts. |
to_string_in_format_args
false positive
#9349 does seem to have resolved the issue. I think the only question that remains is whether you would like this PR's test. |
Ah great! Thanks for revisiting this. I would have gone back to this once the write.rs rewrite was merged. We definitely want the regression test. @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fix #8855
Here is what I think is going on.
First, the expression
format!("{:>6} {:>6}", a, b.to_string())
expands to:When I dump the expressions that get past the call to
has_string_formatting
here, I see more than I would expect.In particular, I see this subexpression of the above:
This suggests to me that more expressions are getting past this call to
FormatArgsExpn::parse
than should.Those expressions are then visited, but no
::core::fmt::rt::v1::Argument
s are found and pushed here.As a result, the expressions appear unformatted, hence, the false positive.
My proposed fix is to restrict
FormatArgsExpn::parse
so that it only matchesCall
expressions.cc: @akanalytics
changelog: none