-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
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
string fmt bug on nightly #43765
Comments
it also passes for
|
bisection log
|
...and that exhausts the nightlies. We're down to |
It looks like this was caused by #42613 cc @stepancheg. The println!("a{:#<5}b", ::std::path::Path::new("").display()); Prints |
thanks for diagnosing. It would be worth adding some unit tests around |
I've sent a PR for this at #43830 |
Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy`, but this was updated in rust-lang#42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (rust-lang#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags), but this should solve the regression for all "real world" use cases of paths and such. The door's also still open for handling these flags in the future! Closes rust-lang#43765
std: Respect formatting flags for str-like OsStr Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy`, but this was updated in #42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags), but this should solve the regression for all "real world" use cases of paths and such. The door's also still open for handling these flags in the future! Closes #43765
Historically many `Display` and `Debug` implementations for `OsStr`-like abstractions have gone through `String::from_utf8_lossy`, but this was updated in rust-lang#42613 to use an internal `Utf8Lossy` abstraction instead. This had the unfortunate side effect of causing a regression (rust-lang#43765) in code which relied on these `fmt` trait implementations respecting the various formatting flags specified. This commit opportunistically adds back interpretation of formatting trait flags in the "common case" where where `OsStr`-like "thing" is all valid utf-8 and can delegate to the formatting implementation for `str`. This doesn't entirely solve the regression as non-utf8 paths will format differently than they did before still (in that they will not respect formatting flags), but this should solve the regression for all "real world" use cases of paths and such. The door's also still open for handling these flags in the future! Closes rust-lang#43765
I develop artifact on nightly and publish using stable, so I am sensitive to changes that happen in nightly but not stable.
Right now the
fmt
functionality seems to be partially broken on nightly. this commit fails the unit test (runningcargo test
)cmd::tests::test_ls::test_cmd_check
:The test prints the expected/result. That printout is:
The difference between the two (that I can spot) is these two lines:
I went into the code to find what generates this formatting, it is in
src/cmd/check.rs
line 234:Oddly, there is a very similar line of code that is used to generate the
Artifacts partof contains at least one recursive reference:
section of the output. That line of code is in the same file, line 159:That line works, the other one doesn't. Why? That I have no clue about...
Meta
This passes (running
cargo test
) onAnd fails on
The text was updated successfully, but these errors were encountered: