Skip to content

Suggest use "{}", self.x instead of {self.x} when resolve x as field of self #141213

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

Merged
merged 4 commits into from
May 21, 2025

Conversation

xizheyin
Copy link
Contributor

Fixes #141136

Changes can be seen in the second commit: 9de7fff

r? compiler

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 18, 2025
@Kivooeo
Copy link
Contributor

Kivooeo commented May 19, 2025

Thanks for your fix!
Can we also add tests for println! macro, to make sure that we handling scenarious like println!("{x}") as well

@xizheyin
Copy link
Contributor Author

println! and format! are actually the same, though the additions do get more comprehensive. :)

@Kivooeo
Copy link
Contributor

Kivooeo commented May 20, 2025

Would you mind squashing the commits into one? It helps keep the history cleaner.

Also, while reviewing this, I noticed a small inconsistency in how similar errors are reported for other macros. For example:

Current format! output (really helpful):

error[E0425]: cannot find value `x` in this scope
  --> $DIR/sugg-field-in-format-string-issue-141136.rs:10:31
   |
LL |         let _ = format!("{}", x);
   |                               ^
   |
help: you might have meant to use the available field
   |
LL |         let _ = format!("{}", self.x);

Meanwhile, println! gives:

error[E0425]: cannot find value `x` in this scope
  --> $DIR/sugg-field-in-format-string-issue-141136.rs:11:20
   |
LL |         println!("{x}");
   |                    ^
   |
   = help: you might have meant to use the available field in a format string: `"{}", self.x`

The format! one shows a concrete suggestion inline, while the println! one is more subtle and easy to miss.

This isn’t a blocker for this PR at all, but it got me thinking—maybe in the future we could consider applying similar diagnostics to other macros like writeln!, eprintln!, format_args!, assert!, or panic!. Could be a great follow-up if you're interested (or to track in a separate issue).

Thanks again for the work on this!

@xizheyin
Copy link
Contributor Author

Committing test in the first commit and seeing the commit changes in the second commit will make reviewing easier. Maybe we can wait for @nnethercote to review before squash.

Additionally, for let _ = format!("{}", x);, inline is given because it originally used the “{}”, x format, while println(“{x}”) is not. Note the placement of x.

@Kivooeo
Copy link
Contributor

Kivooeo commented May 20, 2025

Oh, I see now, but I still wonder if this possible to make suggestion like this by any chance

  |
6 |         let _ = format!("{x}");
  |                           ^
  |
help: you might have meant to use the available field
  |
6 |         let _ = format!("{}", self.x);
  | 

@xizheyin
Copy link
Contributor Author

Thank you for your observations. It's not easy because once the parameters become more numerous, we have to deal with the multi-parameter case, which will be much more complicated. For the inline case, I observe that it is almost always changed in-place because it is easy to show the diff. if it is not changed in-place, the diff will be more confusing. I think the current situation is sufficient.

@nnethercote
Copy link
Contributor

This is looking good to me, I will r+ once the suggestions are made. But I definitely want to keep the commits separate; it's helpful for review and also for anyone who might be looking at the commit history in the future.

@nnethercote nnethercote added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2025
@xizheyin
Copy link
Contributor Author

Maybe it is Ok. @rustbot ready

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 21, 2025
@nnethercote
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented May 21, 2025

📌 Commit 84f67a5 has been approved by nnethercote

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 21, 2025
Copy link
Member

Choose a reason for hiding this comment

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

What happens on

struct Foo { x: i32 }

impl Foo {
    fn foo(&self) { _ = {x}; }
}

Does it essentially suggest fn foo(&self) { _ = "{}", self.x } (sic!)?

Copy link
Member

Choose a reason for hiding this comment

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

I've opened issue #141350 to track this regression.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It will give this message.

error[E0425]: cannot find value `x` in this scope
 --> src/main.rs:4:26
  |
4 |     fn foo(&self) { _ = {x}; }
  |                          ^
  |
  = help: you might have meant to use the available field in a format string: `"{}", self.x`

For further improvement, below two suggestions may be better?

The first suggestion is

help: you might have meant to use the available field if in a format string: `"{}", self.x`

and keep the origin suggestion

help: you might have meant to use the available field
  |
4 |     fn foo(&self) { _ = {self.x}; }
  |                          +++++

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, the message as emitted right now (on master) is not correct. It should indeed suggest you might have meant to use the available field as we do on beta/stable.

bors added a commit to rust-lang-ci/rust that referenced this pull request May 21, 2025
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#137759 (Add `std::os::unix::process::CommandExt::chroot` to safely chroot a child process)
 - rust-lang#140994 (replace `cc_detect::cc2ar` with `cc::try_get_archiver`)
 - rust-lang#141213 (Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`)
 - rust-lang#141283 (Allow `x perf` to find rustc.exe on Windows)
 - rust-lang#141284 (Allow trailing comma after argument in query definition)
 - rust-lang#141317 (typeck: catch `continue`s pointing to blocks)
 - rust-lang#141318 (Avoid creating an empty identifer in `Symbol::to_ident_string`.)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit d30f047 into rust-lang:master May 21, 2025
6 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 21, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request May 21, 2025
Rollup merge of rust-lang#141213 - xizheyin:issue-141136, r=nnethercote

Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`

Fixes rust-lang#141136

Changes can be seen in the second commit: rust-lang@9de7fff

r? compiler
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add self. on format!() macro failed
8 participants