bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
Turn `INCOMPLETE_FEATURES` into lint
We do this because it is annoying to see the warning when building rustc and because this is better from a "separation of concerns" POV.
The drawback to this change is that this will respect `--cap-lints`.
Also note that this is not a buffered lint so if there are fatal parser errors then the lint will not trigger.
r? @varkor
Right now, the order is as follows:
`pop_front()`
`push_front()`
`push_back()`
`pop_back()`
`swap_remove_back()`
`swap_remove_front()`
I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this:
`pop_front()`
`pop_back()`
`push_front()`
`push_back()`
`swap_remove_front()`
`swap_remove_back()`
The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.
Rollup of 15 pull requests
Successful merges:
- #60066 (Stabilize the type_name intrinsic in core::any)
- #60938 (rustdoc: make #[doc(include)] relative to the containing file)
- #61884 (Stablize Euclidean Modulo (feature euclidean_division))
- #61890 (Fix some sanity checks)
- #62528 (Add joining slices of slices with a slice separator, not just a single item)
- #62707 (Add tests for overlapping explicitly dropped locals in generators)
- #62735 (Turn `#[global_allocator]` into a regular attribute macro)
- #62822 (Improve some pointer-related documentation)
- #62887 (Make the parser TokenStream more resilient after mismatched delimiter recovery)
- #62921 (Add method disambiguation help for trait implementation)
- #62930 (Add test for #51559)
- #62942 (Use match ergonomics in Condvar documentation)
- #62977 (Fix inconsistent highlight blocks.)
- #62978 (Remove `cfg(bootstrap)` code for array implementations)
- #62981 (Add note suggesting to borrow a String argument to find)
Failed merges:
- #62964 (clarify and unify some type test names)
r? @ghost
Add joining slices of slices with a slice separator, not just a single item
https://github.com/rust-lang/rust/issues/27747#issuecomment-294525391
> It's kinda annoying to be able to join strings with a str (which can have multiple chars), but joining a slice of slices, you can only join with a single element.
This turns out to be fixable, with some possible inference regressions.
# TL;DR
Related trait(s) are unstable and tracked at https://github.com/rust-lang/rust/issues/27747, but the `[T]::join` method that is being extended here is already stable.
Example use of the new insta-stable functionality:
```rust
let nested: Vec<Vec<Foo>> = /* … */;
let separator: &[Foo] = /* … */; // Previously: could only be a single &Foo
nested.join(separator)
```
Complete API affected by this PR, after changes:
```rust
impl<T> [T] {
pub fn concat<Item: ?Sized>(&self) -> <Self as Concat<Item>>::Output
where Self: Concat<Item>
{
Concat::concat(self)
}
pub fn join<Separator>(&self, sep: Separator) -> <Self as Join<Separator>>::Output
where Self: Join<Separator>
{
Join::join(self, sep)
}
}
// The `Item` parameter is only useful for the the slice-of-slices impl.
pub trait Concat<Item: ?Sized> {
type Output;
fn concat(slice: &Self) -> Self::Output;
}
pub trait Join<Separator> {
type Output;
fn join(slice: &Self, sep: Separator) -> Self::Output;
}
impl<T: Clone, V: Borrow<[T]>> Concat<T> for [V] {
type Output = Vec<T>;
}
impl<T: Clone, V: Borrow<[T]>> Join<&'_ T> for [V] {
type Output = Vec<T>;
}
// New functionality here!
impl<T: Clone, V: Borrow<[T]>> Join<&'_ [T]> for [V] {
type Output = Vec<T>;
}
impl<S: Borrow<str>> Concat<str> for [S] {
type Output = String;
}
impl<S: Borrow<str>> Join<&'_ str> for [S] {
type Output = String;
}
```
# Details
After https://github.com/rust-lang/rust/pull/62403 but before this PR, the API is:
```rust
impl<T> [T] {
pub fn concat<Separator: ?Sized>(&self) -> T::Output
where T: SliceConcat<Separator>
{
SliceConcat::concat(self)
}
pub fn join<Separator: ?Sized>(&self, sep: &Separator) -> T::Output
where T: SliceConcat<Separator>
{
SliceConcat::join(self, sep)
}
}
pub trait SliceConcat<Separator: ?Sized>: Sized {
type Output;
fn concat(slice: &[Self]) -> Self::Output;
fn join(slice: &[Self], sep: &Separator) -> Self::Output;
}
impl<T: Clone, V: Borrow<[T]>> SliceConcat<T> for V {
type Output = Vec<T>;
}
impl<S: Borrow<str>> SliceConcat<str> for S {
type Output = String;
}
```
By adding a trait impl we should be able to accept a slice of `T` as the separator, as an alternative to a single `T` value.
In a `some_slice.join(some_separator)` call, trait resolution will pick an impl or the other based on the type of `some_separator`. In `some_slice.concat()` however there is no separator, so this call would become ambiguous. Some regression in type inference or trait resolution may be acceptable on principle, but requiring a turbofish for every single call to `concat` isn’t great.
The solution to that is splitting the `SliceConcat` trait into two `Concat` and `Join` traits, one for each eponymous method. Only `Join` would gain a new impl, so that `some_slice.concat()` would not become ambiguous.
Now, at the trait level the `Concat` trait does not need a `Separator` parameter anymore. However, simply removing it causes one of the impls not to be accepted anymore:
```rust
error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates
--> src/liballoc/slice.rs:608:6
|
608 | impl<T: Clone, V: Borrow<[T]>> Concat for [V] {
| ^ unconstrained type parameter
```
This makes sense: if `[V]::concat` is a method that is itself not generic, then its return type (which is the `Concat::Output` associated type) needs to be determined based on solely `V`. And although there is no such type in the standard library, there is nothing stopping another crate from defining a `V` type that implements both `Borrow<[Foo]>` and `Borrow<[Bar]>`. It might not be a good idea, but it’s possible. Both would apply here, and there would be no way to determine `T`.
This could be a warning sign that this API is too generic. Perhaps we’d be better off having one less type variable, and only implement `Concat for [&'_ [T]]` and `Concat for [Vec<T>]` etc. However this aspect of `[V]::concat` is already stable, so we’re stuck with it.
The solution is to keep a dummy type parameter on the `Concat` trait. That way, if a type has multiple `Borrow<[_]>` impls, it’ll end up with multiple corresponding `Concat<_>` impls.
In `impl<S: Borrow<str>> Concat<str> for [S]`, the second occurrence of `str` is not meaningful. It could be any type. As long as there is only once such type with an applicable impl, trait resolution will be appeased without demanding turbofishes.
# Joining strings with `char`
For symmetry I also tried adding this impl (because why not):
```rust
impl<S: Borrow<str>> Join<char> for [S] {
type Output = String;
}
```
This immediately caused an inference regression in a dependency of rustc:
```rust
error[E0277]: the trait bound `std::string::String: std::borrow::Borrow<[std::string::String]>` is not satisfied
--> /home/simon/.cargo/registry/src/github.com-1ecc6299db9ec823/getopts-0.2.19/src/lib.rs:595:37
|
595 | row.push_str(&desc_rows.join(&desc_sep));
| ^^^^ the trait `std::borrow::Borrow<[std::string::String]>` is not implemented for `std::string::String`
|
= help: the following implementations were found:
<std::string::String as std::borrow::Borrow<str>>
= note: required because of the requirements on the impl of `std::slice::Join<&std::string::String>` for `[std::string::String]`
```
In the context of this code, two facts are known:
* `desc_rows` is a `Vec<String>`
* `desc_sep` is a `String`
Previously the first fact alone reduces the resolution of `join` to only one solution, where its argument it expected to be `&str`. Then, `&String` is coerced to `&str`.
With the new `Join` impl, the first fact leavs two applicable impls where the separator can be either `&str` or `char`. But `&String` is neither of these things. It appears that possible coercions are not accounted for, in the search for a solution in trait resolution.
I have not included this new impl in this PR. It’s still possible to add later, but the `getopts` breakage does not need to block the rest of the PR. And the functionality easy for end-user to duplicate: `slice_of_strings.join(&*char_separator.encode_utf8(&mut [0_u8, 4]))`
The `&*` part of that last code snippet is another case of the same issue: `encode_utf8` returns `&mut str` which can be coerced to `&str`, but isn’t when trait resolution is ambiguous.
Rename .cap() methods to .capacity()
As mentioned in #60316, there are a few `.cap()` methods, which seem out-of-place because such methods are called `.capacity()` in the rest of the code.
This PR renames them to `.capacity()` but leaves `RawVec::cap()` in there for backwards compatibility.
I didn't try to mark the old version as "deprecated", because I guess this would cause too much noise.
