diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2021-12-10 22:41:26 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-12-10 22:41:26 +0100 |
| commit | 2784051c11c07c204b9ac3891739b20298939a3d (patch) | |
| tree | 9420fd7f9b9905ba3de104c2e187b20eb4025cb7 /src/test/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs | |
| parent | 1d36c6ac2e169728ab2537a5b711360fbd1f8732 (diff) | |
| parent | 4b0a9c9bc3e30215366cb1106645e5ddcfa93b92 (diff) | |
| download | rust-2784051c11c07c204b9ac3891739b20298939a3d.tar.gz rust-2784051c11c07c204b9ac3891739b20298939a3d.zip | |
Rollup merge of #91697 - dtolnay:lossyfromstr, r=Mark-Simulacrum
Delete Utf8Lossy::from_str This whole type is marked as being for str internals only, but this constructor is never used by str internals. If you had a &str already and wanted to lossy display it or iterate its lossy utf8 chunks, you would simply not use Utf8Lossy because the whole &str is known to be one contiguous valid utf8 chunk. If code really does need to obtain a value of type &Utf8Lossy somewhere, and has only a &str, `Utf8Lossy::from_bytes(s.as_bytes())` remains available. As currently implemented, there is no performance penalty relative to `from_str` i.e. the Utf8Lossy does not "remember" that it was constructed using `from_str` to bypass later utf8 decoding.
Diffstat (limited to 'src/test/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs')
0 files changed, 0 insertions, 0 deletions
