This test case has been removed a while ago because it allegedly was broken. But I don't think it is (at least I couldn't reproduce any failure on Linux). Let's give it another chance `:)`
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
After #26694, the overloaded operator and "impl not known at method lookup time" cases started triggering the lint.
I've also added checks for overloaded autoderef and method calls via paths (i.e. `T::method()`).
All new 8 test cases did not trigger the lint before #26694.
r? @huonw
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.
Fix quadratic behavior in StrSearcher in reverse search with periodic
needles.
This commit adds the missing pieces for the "short period" case in
reverse search. The short case will show up when the needle is literally
periodic, for example "abababab".
Two way uses a "critical factorization" of the needle: x = u v.
Searching matches v first, if mismatch at character k, skip k forward.
Matching u, if mismatch, skip period(x) forward.
To avoid O(mn) behavior after mismatch in u, memorize the already
matched prefix.
The short period case requires that |u| < period(x).
For the reverse search we need to compute a different critical
factorization x = u' v' where |v'| < period(x), because we are searching
for the reversed needle. A short v' also benefits the algorithm in
general.
The reverse critical factorization is computed quickly by using the same
maximal suffix algorithm, but terminating as soon as we have a location
with local period equal to period(x).
This adds extra fields crit_pos_back and memory_back for the reverse
case. The new overhead for TwoWaySearcher::new is low, and additionally
I think the "short period" case is uncommon in many applications of
string search.
The maximal_suffix methods were updated in documentation and the
algorithms updated to not use !0 and wrapping add, variable left is now
1 larger, offset 1 smaller.
Use periodicity when computing byteset: in the periodic case, just
iterate over one period instead of the whole needle.
Example before (rfind) after (twoway_rfind) benchmark shows the removal
of quadratic behavior.
needle: "ab" * 100, haystack: ("bb" + "ab" * 100) * 100
```
test periodic::rfind ... bench: 1,926,595 ns/iter (+/- 11,390) = 10 MB/s
test periodic::twoway_rfind ... bench: 51,740 ns/iter (+/- 66) = 386 MB/s
```
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
