Regression in the Debug formatter

[pietroalbini]

The Debug formatter output was recently changed in #30967 to always include a decimal point, and apparently some crates' test suites depends on the exact output of the formatter. I don't know if it's worth to revert the change, but I reported it just in case.

• caldyn regressed from stable to beta (crater log)
• earlgrey regressed from stable to beta (crater log 1 and crater log 2)
• euclid regressed from stable to beta (crater log 1 and crater log 2), but it's fixed on master
• expecttest regressed from stable to beta (crater log), but it's fixed on master
• mkv regressed from stable to beta (crater log)
• postgis regressed from stable to beta (crater log)
• pretty_assertions regressed from stable to beta (crater log), but it's fixed on master
• scanlex regressed from stable to beta (crater log)
• spectral regressed from stable to beta (crater log)
• vectors regressed from stable to beta (crater log)

cc @dtolnay @Luthaf @rodolf0

[pietroalbini]

euclid and expecttest are also affected (but euclid now it's fixed on master).

cc @zummenix

[sfackler]

We make zero guarantees as to what Debug implementations look like.

[Luthaf]

I'm fine with this, I'll change my tests =)

[zummenix]

I'll change my tests too. @pietroalbini thanks for cc me!

[pietroalbini]

mkv is also affected. cc @vi

[pietroalbini]

postgis is also affected. cc @andelf @pka
pretty_assertions is also affected. cc @colin-kiegel
scanlex is also affected. cc @stevedonovan

[colin-kiegel]

Thanks for the heads up!

If you want to restore "consistent" behaviour across old and future rust versions, you can just replace {:?} with either {:.0?} or {:.1?}. This way you can still write testcases that depend on the exact debug output for floats:

print!("{:?}",   0.0); // stable: "0",   nightly "0.0"
print!("{:.0?}", 0.0); // stable: "0",   nightly "0"
print!("{:.1?}", 0.0); // stable: "0.0", nightly "0.0"

[vi]

Shall there be a [clippy] lint against using Debug output for assert_eq!?

[pietroalbini]

This also affects spectral (crater log). cc @cfrancia
This also affects vectors (crater log). cc @deepthought

[stevedonovan]

Yes, it's foolish to depend on exact Debug representations, and I will fix accordingly. There was a similar situation in Lua 5.3 when the default formating for floats changed - broke a lot of naive code.

[Mark-Simulacrum]

Closing as not a bug; we do not expect to make any changes here.

[sunjay]

Broke the tests in the turtle crate too. Any of our tests using should_panic broke because they were relying on the entire message which included a formatted struct.

#[test]
#[should_panic(expected = "Invalid color: Color { red: NaN, green: 0, blue: 0, alpha: 0 }. See the color module documentation for more information.")]
fn rejects_invalid_background_color() {
    // ...
}

Not a huge deal this time because there were just a few tests like that, but this really shouldn't be taken lightly either. Any breaking change, no matter how small for you can be really frustrating for someone else who doesn't see it coming.

Yes, it's foolish to depend on exact Debug representations, and I will fix accordingly. There was a similar situation in Lua 5.3 when the default formating for floats changed - broke a lot of naive code.

In this case, for should_panic, we only get to pass in a naive string, so of course changes like this will break a test like that. We don't even get to set formatting options so any of the workarounds suggested will not work. I'm including the debug representation in what I am testing because I want to make sure that its values match what I expect. Changing is a big deal and it broke my code in a way I really couldn't have prevented.

We make zero guarantees as to what Debug implementations look like.

I'm fine with this, because it makes sense to me too, but as I said earlier I don't think any breaking change should be taken too lightly just because no explicit guarantees have been made. It's clear from this issue that a lot of people were relying on that being a certain way.