| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Remove or hide deprecated unstable SipHasher{13,24}
Deprecated since Rust 1.13.0.
|
|
|
|
|
|
Wrapping<T> now implements:
count_ones, count_zeros, leading_zeros,
trailing_zeros, rotate_left, rotate_right, swap_bytes, from_be,
from_le, to_be, to_le, and pow
where T is:
u8, u16, u32, u64, usize, i8, i16, i32, i64, or isize.
Docs were written for all these methods, as well as examples. The
examples mirror the ones on u8, u16, etc... for consistency.
Closes #32463
|
|
Add hexadecimal formatting of integers with fmt::Debug
This can be used for integers within a larger types which implements Debug (possibly through derive) but not fmt::UpperHex or fmt::LowerHex.
```rust
assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]");
assert!(format!("{:02X?}", b"Foo\0") == "[46, 6F, 6F, 00]");
```
RFC: https://github.com/rust-lang/rfcs/pull/2226
The new formatting string syntax (`x?` and `X?`) is insta-stable in this PR because I don’t know how to change a built-in proc macro’s behavior based of a feature gate. I can look into adding that, but I also strongly suspect that keeping this feature unstable for a time period would not be useful as possibly no-one would use it during that time.
This PR does not add the new (public) `fmt::Formatter` proposed in the API because:
* There was some skepticism on response to this part of the RFC
* It is not possible to implement as-is without larger changes to `fmt`, because `Formatter` at the moment has no easy way to tell apart for example `Octal` from `Binary`: it only has a function pointer for the relevant `fmt()` method.
If some integer-like type outside of `std` want to implement this behavior, another RFC will likely need to propose a different public API for `Formatter`.
|
|
|
|
Fixes #27730
|
|
|
|
It has been deprecated for about one release cycle.
|
|
(This was buggy before https://github.com/rust-lang/rust/pull/46882)
|
|
These will eventually be removed
(though the NonZero<T> lang item will likely stay).
|
|
|
|
|
|
RFC: https://github.com/rust-lang/rfcs/pull/2307
|
|
|
|
lifetimes)
|
|
|
|
|
|
It stays in libcore rather than being private in HashMap’s module
because it shares code with the deprecated *stable* `SipHasher` type.
|
|
|
|
It is still used by the deprecated *stable* `SipHasher` type.
|
|
|
|
for numeric types
The code using a slice of that buffer is only ever going to use
bytes that are subsequently initialized.
|
|
Before ebf9e1aaf6, it was used for Display::fmt, but ebf9e1aaf6 replaced
that with a faster implementation, and nothing else uses it.
|
|
|
|
Make `assert` a built-in procedural macro
Makes `assert` macro a built-in one without touching its functionality. This is a prerequisite for RFC 2011 (#44838).
|
|
Rollup of 17 pull requests
- Successful merges: #48706, #48875, #48892, #48922, #48957, #48959, #48961, #48965, #49007, #49024, #49042, #49050, #48853, #48990, #49037, #49049, #48972
- Failed merges:
|
|
|
|
|
|
Stabilize inclusive range (`..=`)
Stabilize the followings:
* `inclusive_range` — The `std::ops::RangeInclusive` and `std::ops::RangeInclusiveTo` types, except its fields (tracked by #49022 separately).
* `inclusive_range_syntax` — The `a..=b` and `..=b` expression syntax
* `dotdoteq_in_patterns` — Using `a..=b` in a pattern
cc #28237
r? @rust-lang/lang
|
|
Reword E0044 and message for `!Send` types
- Reword E0044 help.
- Change error message for types that don't implement `Send`
CC #45092, #46678, #24909, #33307.
|
|
|
|
Stabilize the syntax `a..=b` and `..=b`.
|
|
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
|
|
|
|
|
|
|
|
Extend `rustc_on_unimplemented` to match on ADT without evaluating type
arguments.
|
|
- Reword E0044 help.
- Change error message for types that don't implement `Send`
|
|
Stabilise feature(never_type). Introduce feature(exhaustive_patterns)
This stabilizes `!`, removing the feature gate as well as the old defaulting-to-`()` behavior. The pattern exhaustiveness checks which were covered by `feature(never_type)` have been moved behind a new `feature(exhaustive_patterns)` gate.
|
|
|
|
Add missing examples
r? @QuietMisdreavus
|
|
|
|
|
|
Replace feature(never_type) with feature(exhaustive_patterns).
feature(exhaustive_patterns) only covers the pattern-exhaustives checks
that used to be covered by feature(never_type)
|
|
Move ascii::escape_default to libcore
As requested in #46409, the `ascii::escape_default` method has been added to the core library. All I did was copy over the `std::ascii` module file, remove the (redundant) `AsciiExt` trait, and change some of the documentation to match. None of the tests were changed.
I wasn't sure how to handle the annotations. For `EscapeDefault` and `escape_default()`, I changed them to `#[unstable(feature = "core_ascii", issue = "46409")]`. Is that alright? Or should I leave them as they were?
|
|
This can be used for integers within a larger types which implements Debug
(possibly through derive) but not fmt::UpperHex or fmt::LowerHex.
```rust
assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]");
assert!(format!("{:02X?}", b"Foo\0") == "[46, 6F, 6F, 00]");
```
RFC: https://github.com/rust-lang/rfcs/pull/2226
|
|
|
|
Add missing links
|
|
|
