| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Mark ascii methods on primitive types stable in 1.23.0 not 1.21.0.
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
|
|
|
|
Fix documentation for DecodeUtf16Error
Fixes #46307
|
|
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
|
|
Fixes #46307
|
|
Stabilize some `ascii_ctype` methods
As discussed in #39658, this PR stabilizes those methods for `u8` and `char`. All inherent `ascii_ctype` for `[u8]` and `str` are removed as we prefer the more explicit version `s.chars().all(|c| c.is_ascii_())`.
This PR doesn't modify the `AsciiExt` trait. There, the `ascii_ctype` methods are still unstable. It is planned to remove those in the future (I think). I had to modify some code in `ascii.rs` to properly implement `AsciiExt` for all types.
Fixes #39658.
|
|
The changes didn't land in time for 1.23 and stabilizations won't
be backported to beta.
|
|
Also adds #![deny(missing_debug_implementations)] so they don't get
missed again.
|
|
The feature of those methods was renamed to "ascii_ctype_on_intrinsics".
|
|
|
|
|
|
We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.
|
|
|
|
This is done in order to deprecate AsciiExt eventually.
|
|
In <https://github.com/rust-lang/rust/pull/42998>, we added an
uninstantiable type for the internal `UNICODE_VERSION` value,
`UnicodeVersion`, but it was not made public to the outside of the
crate, resulting in the value becoming less useful. Here we make the
type accessible from the outside.
Also add a run-pass test to make sure the type and value can be accessed
as intended.
|
|
|
|
Fixes #41701.
|
|
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
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
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
|
|
[libstd_unicode] Change UNICODE_VERSION to use u32
Looks like there's no strong reason to keep these values at `u64`.
With the current plans for the Unicode Standard, `u8` should be enough for the next 200 years. To stay on the safe side, I'm using `u16` here. I don't see a reason to go with anything machine-dependent/more-efficient.
|
|
Stabilizes:
* `<char>::escape_debug`
* `std::char::EscapeDebug`
Closes #35068
|
|
Create named struct `UnicodeVersion` to use instead of tuple type for
`UNICODE_VERSION` value. This allows user to access the fields with
meaningful field names: `major`, `minor`, and `micro`.
Per request, an empty private field is added to the struct, so it can be
extended in the future without API breakage.
|
|
Use `u32` for version components, as `u64` is just an overkill, and
`u32` is the default type for integers and the default type used for
regular internal numbers.
There's no expectation for Unicode Versions to even reach one thousand
in the next hundered years. This is different from *package versions*,
which may become something auto-generated and exceed human-friendly
range of integer values.
|
|
These show up in rustdoc so need to be correct.
|
|
|
|
add `FromStr` Impl for `char`
fixes #24939.
is it possible to use pub(restricted) instead of using a stability attribute for the internal error representation? is it needed at all?
|
|
|
|
Introduce tidy lint to check for inconsistent tracking issues
This PR
* Refactors the collect_lib_features function to work in a
non-checking mode (no bad pointer needed, and list of
lang features).
* Introduces checking whether unstable/stable tags for a
given feature have inconsistent tracking issues, as in,
multiple tracking issues per feature.
* Fixes such inconsistencies throughout the codebase.
|
|
This commit
* Refactors the collect_lib_features function to work in a
non-checking mode (no bad pointer needed, and list of
lang features).
* Introduces checking whether unstable/stable tags for a
given feature have inconsistent tracking issues.
* Fixes such inconsistencies throughout the codebase.
|
|
|
|
|
|
impl Clone for .split_whitespace()
Use custom closure structs for the predicates so that the iterator's
clone can simply be derived. This should also reduce virtual call
overhead by not using function pointers.
Fixes #41655
|
|
The only place this Python script is used is inside the libstd_unicode
crate, so lets move it there.
|
|
|
|
Use custom closure structs for the predicates so that the iterator's
clone can simply be derived. This should also reduce virtual call
overhead by not using function pointers.
|
|
|
|
Original headline of SplitWhitespace's description is more descriptive as to what it contains and iterates over.
|
|
|
|
|
|
|
|
Corrected very minor documentation detail about Unicode and Japanese
Japanese half-width and full-width romaji characters do have upper and lowercase according Unicode (but other Japanese characters do not). For example,
` assert_eq!('\u{FF21}'.to_lowercase().collect::<String>(),"\u{FF41}");`
r? @steveklabnik
|
|
|
|
This was never established as a convention we should follow in the 'More
API Documentation Conventions' RFC:
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md
|
|
|
|
It was only accessible through the `#[unstable]` crate std_unicode.
It has never been used in the compiler or standard library
since 47e7a05a28c9662159af2d2e0f2b7efc13fa09cb added it in 2012
“for OS API interop”.
It can be replaced with a one-liner:
```rust
fn is_utf16(slice: &[u16]) -> bool {
std::char::decode_utf16(s.iter().cloned()).all(|r| r.is_ok())
}
```
|
|
… instead of one of each of libcore and libstd_unicode.
Move the `utf8_char_width` function to `core::str`
under the `str_internals` unstable feature.
|
|
The versions show up in rustdoc.
|
