For Version::Two we don't check the line length of string literals because there's no meaningful way to break them by default. Similarity, I don't think there would be a meaningful way to break a float literal over multiple lines so let's avoid using wrap_str. Same goes for the wrap_str call below.

For reference, here's the code in rewrite_string_lit that I'm referring to:

Could you please elaborate? I guess the statement “there is no meaningful way to break a float literal over multiple lines” is always true, so why would this depend on config version?

BTW, would you say that rewrite_int_lit should be updated as well? It also calls wrap_str unconditionally:

This is a good start, but I'd really like to see us expand on these test cases.

1. Can we move all float_literal_trailing_zero tests to a tests/{source|target}/config/float_literal_trailing_zero directory. Then you can name each test file as the name of the enum variant.
2. To cover all our bases let's add a test case for Preserve. We should only need a target test file for the preserve case since we don't expect formatting to change.
3. Let's try to be as thorough as we can when coming up with test cases. You've already highlighted let bindings, but there are plenty of other places where float literals can be written. A few that come to mind are conditional expressions, struct literals, match patterns, function arguments, array literals, macro calls, etc.

One thing that I'm particularly interested in seeing is what happens when we're at or near the max_width boundary. Does adding the extra 0 correctly wrap a function call or array literal when adding the extra 0 pushes us over the max_width, and do we correctly format on a single line when adding 0 pushes us to exactly the max_width.

Also please tell me if I did the tests right. Three separate test files seem like a lot for such a small feature, but I don't see how else I could check all configurations.

Oh and to answer your question, this is correct. You'll need to create individual test files for each case!

1. Done.
2. Done.
3. I've added one macro and one non-macro example that causes a line wrapping change. Do you think we really need to cover all these cases (conditional expressions, struct literals, match patterns, function arguments, etc.)? To me it feel a bit excessive. And it seems different from the current testing strategy (take hex_literal_case tests as a close example).

Also, we'll need to add a new tracking issue for this one. #3187 isn't a tracking issue. We can certainly add the tracking issue after this PR is merged.

Why don't we create an issue now, so that we don't have to go back and modify the link later?
Is there a document that describes how a tracking issue should look like?