Fixes#25022
This adapts the deriving mechanism to not repeat bounds for the same type parameter. To give an example: for the following code:
```rust
#[derive(Clone)]
pub struct FlatMap<I, U: IntoIterator, F> {
iter: I,
f: F,
frontiter: Option<U::IntoIter>,
backiter: Option<U::IntoIter>,
}
```
the latest nightly generates the following impl signature:
```rust
impl <I: ::std::clone::Clone,
U: ::std::clone::Clone + IntoIterator,
F: ::std::clone::Clone>
::std::clone::Clone for FlatMap<I, U, F> where
I: ::std::clone::Clone,
F: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone
```
With these changes, the signature changes to this:
```rust
impl <I, U: IntoIterator, F> ::std::clone::Clone for FlatMap<I, U, F> where
I: ::std::clone::Clone,
F: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone
```
(Nothing in the body of the impl changes)
Note that the second impl is more permissive, as it doesn't have a `Clone` bound on `U` at all. There was a compile-fail test that failed due to this. I don't understand why we would want the old behaviour (and nobody on IRC could tell me either), so please tell me if there is a good reason that I missed.
This removes some of the more casual language.
The only outright goofiness I couldn't bear to remove is "these modules are the bedrock upon which all of Rust is forged, and they have mighty names like `std::slice` and `std::cmp`", which I believe the greatest sentence I have ever created.
Only `make -j4` takes ~50 mins
`make check` bumps it up to ~1hr 30min
Travis seems more than happy to let this happen.
Time limits appear to be meaningless.
Similar to the previous PR, it's easy to tell how much your PR definitely builds by checking the current logs or just considering how long it's been building for.
- Fix#26968 by noting the difference between ".." and "_" more explicitly
- Change one of the examples to show the match-all behaviour of ".."
- Merge "Ignoring variants" and "Ignoring bindings" sections into the latter
part of #24407
I'm not sure whether I should be trying to explain the general rule in the E0210 explanation or just point people to the RFC. However, if we go with the latter option I think that the RFC will need to be revised slightly, since it is not quite as gentle as I would like.
Also, the link to RFC 1023 is not the correct one (it should be https://github.com/rust-lang/rfcs/blob/master/text/1023-rebalancing-coherence.md), but the correct one is too long. I'm aware of @michaelsproul's PR https://github.com/rust-lang/rust/pull/26290 from awhile back, but it doesn't seem to be working. Has there not been a new snapshot yet?
#27360 removed a padding field full of uint8_t's, but didn't remove
the use. This didn't get picked up presumably because (a) bors
doesn't have any BSD builders, and/or (b) #[cfg]'d out blocks don't
get linted.
```
rustc: x86_64-unknown-freebsd/stage1/lib/rustlib/x86_64-unknown-freebsd/lib/liblibc
src/liblibc/lib.rs:1099:42: 1099:49 error: unused import, #[deny(unused_imports)] on by default
src/liblibc/lib.rs:1099 use types::common::c99::{uint8_t, uint32_t, int32_t};
^~~~~~~
error: aborting due to previous error
fatal runtime error: Could not unwind stack, error = 159555904
```
this makes the second code block consistent with the first code block -- other than being in reversed order, the first code block claims b is u16 and c is u32, whereas the second code block claims the opposite. seems to be an obvious typo.
Most errors generated by resolve might be caused by
not-yet-resolved glob imports. This changes the behavior of the
resolve imports algorithms to not fail prematurally on first
error, but instead buffer intermediate errors and report them
only when stuck.
Fixes#18083
bors
Steve Klabnik
Michael Woerister
Simonas Kazlauskas
Alexis Beingessner
Guillaume Gomez
Tshepang Lekhonkhobe
Jonathan Hansford
Vadim Chugunov
Manish Goregaokar
Agoston Szepessy
Brian Anderson
Simon Sapin
Pascal Hertleif
Jan Likar
Kieran Hunt
Daniel Albert
mitaa
Mickaël Salaün
Dave Huseby
Peter Atashian
Victor Berger