We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
I occasionally write macros that include faux-closure syntax, for example:
macro_rules! map_and_then_print { ($value:expr, |$pat:pat| $map:expr) => {{ let $pat = $value; let s = $map; println!("{}", s); }}; } map_and_then_print!(1, |x| x + 3); // Prints "4"
rustfmt formats the usage as I'd expect:
map_and_then_print!(1, |x| x + 3);
But the declaration gets formatted a bit strangely:
($value:expr, | $pat:pat | $map:expr) => {{
rustfmt doesn't understand that it's supposed to resemble a closure, so it puts a few extra spaces in. I would have expected it to look like this:
($value:expr, |$pat:pat| $map:expr) => {{
Here is rustfmt.toml:
edition = "2018" format_macro_matchers = true
Is this kind of thing in scope for the project?
The text was updated successfully, but these errors were encountered:
It is, though it is not the highest priority and very hard to get it done right.
Sorry, something went wrong.
Confirming this is reproducible with rustfmt 1.5.1-nightly (a451a39d 2022-07-25).
rustfmt 1.5.1-nightly (a451a39d 2022-07-25)
Linking tracking issue for format_macro_matchers #3354
format_macro_matchers
No branches or pull requests
I occasionally write macros that include faux-closure syntax, for example:
rustfmt formats the usage as I'd expect:
But the declaration gets formatted a bit strangely:
rustfmt doesn't understand that it's supposed to resemble a closure, so it puts a few extra spaces in. I would have expected it to look like this:
Here is rustfmt.toml:
Is this kind of thing in scope for the project?
The text was updated successfully, but these errors were encountered: