-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
std: Respect formatting flags for str-like OsStr #43830
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks like a good stopgap to me. I might want to take a shot at fixing this more thouroughly in the future.
src/libstd_unicode/lossy.rs
Outdated
@@ -153,7 +153,21 @@ impl<'a> Iterator for Utf8LossyChunksIter<'a> { | |||
|
|||
impl fmt::Display for Utf8Lossy { | |||
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { | |||
// If we're the empty string then our iterato won't actually yield |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iterato
-> iterator
|
||
#[test] | ||
fn display_format_flags() { | ||
assert_eq!(format!("a{:#<5}b", Path::new("").display()), "a#####b"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for adding these tests!
one of the issues with formatting non-utf8 strings (in the future) is what do we even do? Invalid characters are... invalid, so how many "spaces" do they take? (I assume zero) |
You'd just need to match the behavior of: Lines 1111 to 1149 in adbce60
to_string_lossy . So each replacement character just counts as 1.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this will also need to be applied to Wtf8
for it to work on Windows:
rust/src/libstd/sys_common/wtf8.rs
Lines 441 to 463 in adbce60
impl fmt::Display for Wtf8 { | |
fn fmt(&self, formatter: &mut fmt::Formatter) -> fmt::Result { | |
let wtf8_bytes = &self.bytes; | |
let mut pos = 0; | |
loop { | |
match self.next_surrogate(pos) { | |
Some((surrogate_pos, _)) => { | |
formatter.write_str(unsafe { | |
str::from_utf8_unchecked(&wtf8_bytes[pos .. surrogate_pos]) | |
})?; | |
formatter.write_str(UTF8_REPLACEMENT_CHARACTER)?; | |
pos = surrogate_pos + 3; | |
}, | |
None => { | |
formatter.write_str(unsafe { | |
str::from_utf8_unchecked(&wtf8_bytes[pos..]) | |
})?; | |
return Ok(()); | |
} | |
} | |
} | |
} | |
} |
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
cb0cf8c
to
742ca0c
Compare
Fixed typo and updated wtf-8 as well |
actually oops this is libs sooo r? @aturon |
@bors: p=1 (beta backport) |
Discussed and decided for backport today |
We discussed as well that we should have a tracking bug for support all formatting flags here, so I've opened #44048 |
@bors: r+ |
📌 Commit 742ca0c has been approved by |
⌛ Testing commit 742ca0c with merge 036d625939a7cf53e708ec02aa847d2a62c235d1... |
💔 Test failed - status-appveyor |
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
☀️ Test successful - status-appveyor, status-travis |
Historically many
Display
andDebug
implementations forOsStr
-likeabstractions have gone through
String::from_utf8_lossy
, but this was updatedin #42613 to use an internal
Utf8Lossy
abstraction instead. This had theunfortunate side effect of causing a regression (#43765) in code which relied on
these
fmt
trait implementations respecting the various formatting flagsspecified.
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 candelegate to the formatting implementation for
str
. This doesn't entirely solvethe 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