Suggest {var:?} when finding {?:var} in inline format strings
#106805
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @TaKO8Ki (or someone else) soon. Please see the contribution instructions for more information. |
rustbot
added
S-waiting-on-review
Nilstrieb
changed the title
{var:?} when finding {:?var} in inline format strings
|
Thanks! Yes, something like this is the correct approach. If you intend to make more changes with more suggestions then feel free, but you can also land just this change first if you prefer. |
|
We moved the tests from |
If it is OK, then let's just land this one first. Then I can use some time to tinker with the full idea while maybe grabbing one or two other issues to really learn the ropes. |
That's a roger. Will do later today - just on my way out the door. Thanks :) |
rustbot
added
A-meta
|
Some changes occurred in need_type_info.rs cc @lcnr
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
There seems to have been an issue with rebasing on top of master. You'll have to rebase interactively on top of master while discarding any commits that you didn't intend to include in the PR. Let us know if you need assistance doing so. |
I would love some assistance with this. For some reason, me and |
|
Ah, looks like you managed to figure it out :) |
Thanks for the link. I think I sort of stumbled over the way to solve it. I hope that did the trick and I will be more careful in the future :) |
estebank
changed the title
{var:?} when finding {:?var} in inline format strings{var:?} when finding {?:var} in inline format strings
|
@TaKO8Ki Hi, I have been told it would be OK to ping you after a few weeks. Do you know when you will get time to review this? No need to jump on it now if you don't have the time. |
|
@madsravn, can you add the tests requested in #106805 (comment) ? Also, do you mind rebasing and squashing the commit history into one or two PRs -- all those "Adding" and tweaking commits just clutters up the git history 😄 Afterwards, I think this can be approved, as Esteban had noted above. |
| @@ -0,0 +1,5 @@ | |||
| fn main() { | |||
| let bar = 3; | |||
| format!("{?:}", bar); //~ ERROR invalid format string: expected format parameter to occur after `:` | |||
There was a problem hiding this comment.
tiny nitpick, take it or leave it -- it's easier to read, in my opinion, when the error follows the line in question, using ~^ like:
| format!("{?:}", bar); //~ ERROR invalid format string: expected format parameter to occur after `:` | |
| format!("{?:}", bar); | |
| //~^ ERROR invalid format string: expected format parameter to occur after `:` |
There was a problem hiding this comment.
I have squashed the commits - hadn't tried that before. Was surprisingly easy.
And nitpicks are awesome. Those are what changes "good" to "great".
Done
Adding Adding Fixing small issues for PR Adding tests Removing unused binding Changing the wording on note Fixing PR comment
|
@bors r+ rollup |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#106575 (Suggest `move` in nested closure when appropriate) - rust-lang#106805 (Suggest `{var:?}` when finding `{?:var}` in inline format strings) - rust-lang#107500 (Add tests to assert current behavior of large future sizes) - rust-lang#107598 (Fix benchmarks in library/core with black_box) - rust-lang#107602 (Parse and recover from type ascription in patterns) - rust-lang#107608 (Use triple rather than arch for fuchsia test-runner) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Adding alignment to the cases to test for specific error messages. Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`. Pinging people who chimed in last time ( rust-lang#106805 ): `@estebank` , `@compiler-errors` and `@Nilstrieb`
Adding alignment to the cases to test for specific error messages. Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`. Pinging people who chimed in last time ( rust-lang#106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
Rollup merge of rust-lang#119712 - madsravn:parsing-errors, r=estebank Adding alignment to the cases to test for specific error messages. Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`. Pinging people who chimed in last time ( rust-lang#106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
Adding alignment to the cases to test for specific error messages. Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`. Pinging people who chimed in last time ( rust-lang/rust#106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
Adding alignment to the cases to test for specific error messages. Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`. Pinging people who chimed in last time ( rust-lang/rust#106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
Adding alignment to the cases to test for specific error messages. Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`. Pinging people who chimed in last time ( rust-lang/rust#106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
Fixes #106572
This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.
Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.