rustfmt joins numbers separated by dot and whitespace

[mbillingr]

Describe the bug

Rustfmt joins numbers separated by whitespace and dots.

For example:

let x = 1 . 2;  // before rustfmt: field access (syntax error)
let x = 1.2;  // after rustfmt

I think this is a bug because it changes the meaning of the program from field access (although erroneous) to float literal.
Although the user probably intended to write a float literal, I don't think it's the job of rustfmt to fix our errors (or is it?) 😃

This bothers me because in my particular case I have a macro that produces S-expressions in a syntax as close as possible to Scheme's.
Rustfmt changes a correct

let pair = sexpr![(1 . 2)];  // before rustfmt: intended to be two numbers separated by a dot

into a broken

let pair = sexpr![(1.2)];  // after rustfmt: unintended float

To Reproduce

Run Rustfmt on this playground

Expected behavior

I'd prefer if rustfmt did not change the first case, and it really should not break my macro use.

Meta

• rustfmt version: 1.4.37-nightly (2021-04-03 0bd2b19), rustfmt 1.4.36-stable (7de6968 2021-02-07)
• From where did you install rustfmt?: playground, rustup
• How do you run rustfmt: playground, cargo fmt, intellij

[calebcartwright]

Thanks for reaching out and including all the relevant information!

I think this is a bug because it changes the meaning of the program from field access (although erroneous) to float literal.
Although the user probably intended to write a float literal, I don't think it's the job of rustfmt to fix our errors (or is it?) smiley

rustfmt's sole job is to reformat inputs according to the prescriptions codified in the Style Guide for each respective AST node; the developers probable intent with invalid code is completely orthogonal.

In the case of the first snippet (the local assignment), the initializer expression is indeed parsed as field access so rustfmt correctly applies the formatting rules for field exprs. The fact that the resulting output happens to be a valid float is just a side effect of the nature of the developers original invalid syntax, and that's not a bug in rustfmt nor anything we can viably work around nor would we want to attempt to do so.

and it really should not break my macro use.

Understand your perspective here, but it's also true that rustfmt still only has very minimal support for formatting macros. I'd advise using brace delimiters instead ({) because with paren and bracket delimiters rustfmt attempts to format things as if they were "normal" Rust code, which in the case of your macro call goes back to a successfully produced field expr node and the corresponding formatting rules being applied

[mbillingr]

Thanks for responding!

... not a bug in rustfmt nor anything we can viably work around...

Fair enough. I had hoped this could be considered a bug that, if resolved, would incidentally fix my actual issue (the macro).
I'm curious if #4808 is somehow related...

I'd advise using brace delimiters instead ({) ...

Oh right! Thank you for the advice, this works well enough for me!