merge unused-extern-crate and unnecessary-extern-crate lints
Extend the `unused_extern_crates` lint to offer a suggestion to remove the extern crate and remove the `unnecessary_extern_crate` lint.
Still a few minor issues to fix:
- [x] this *does* now leave a blank line... (defer to https://github.com/rust-lang/rust/issues/51176)
- idea: extend the span to be replaced by 1 character if the next character is a `\n`
- [x] what about macros? do we need to watch out for that? (defer to https://github.com/rust-lang/rust/issues/48704)
- [x] also it doesn't work for `extern crate foo; fn main() { foo::bar(); }`
- this is subtle: the `foo` might be shadowing a glob import too, can't always remove
- defer to https://github.com/rust-lang/rust/issues/51177
- [x] we also don't do the `pub use` rewrite thang (https://github.com/rust-lang/rust/issues/51013)
Spun off from https://github.com/rust-lang/rust/pull/51010Fixes#50672
r? @alexcrichton
Rollup of 5 pull requests
Successful merges:
- #51135 (Tweak output on E0599 for assoc fn used as method)
- #51152 (Replace `if` with `if and only if` in the definition dox of `Sync`)
- #51262 (Add missing whitespace in num example)
- #51272 (Remove feature flag from fs::read_to_string example)
- #51286 (Pull 1.26.2 release notes into master)
Failed merges:
Replace `if` with `if and only if` in the definition dox of `Sync`
The old text was: "The precise definition is: a type `T` is `Sync` if `&T` is Send."
Since we've also got
```
impl<'a, T> Send for &'a T
where
T: Sync + ?Sized,
```
I purpose we can change the `if` to `if and only if` to make it more precise.
Tweak output on E0599 for assoc fn used as method
- Use suggestion instead of `help` when possible
- Add primary span label
- Remove incorrect `help` suggestion using incorrect syntax
- Do not refer to only one possible candidate as `candidate #1`, refer to it as `the candidate`
This commit is concerned with the case where the user tries to mutably
borrow a mutable reference, thereby triggering an error. Instead of the
existing suggestion to make the binding mutable, the compiler will now
suggest to avoid borrowing altogether.
Simplify HashMap layout calculation by using Layout
`RawTable` uses a single allocation to hold both the array of hashes and the array of key/value pairs. This PR changes `RawTable` to use `Layout` when calculating the amount of memory to allocate instead of performing the calculation manually.
r? @SimonSapin
optimize joining for slices
This improves the speed of string joining up to 3x.
It removes the boolean flag check every iteration, eliminates repeated bounds checks and adds a fast paths for small separators up to a len of 4 bytes
These optimizations gave me ~10%, ~50% and ~80% improvements respectively over the previous speed. Those are multiplicative.
3x improvement happens for the optimal case of joining many small strings together in my microbenchmarks. Improvements flatten out for larger strings of course as more time is spent copying bits around. I've run a few benchmarks [with this code](https://github.com/Emerentius/join_bench). They are pretty noise despite high iteration counts, but in total one can see the trends.
```
len_separator len_string n_strings speedup
4 10 10 2.38
4 10 100 3.41
4 10 1000 3.43
4 10 10000 3.25
4 100 10 2.23
4 100 100 2.73
4 100 1000 1.33
4 100 10000 1.14
4 1000 10 1.33
4 1000 100 1.15
4 1000 1000 1.08
4 1000 10000 1.04
10 10 10 1.61
10 10 100 1.74
10 10 1000 1.77
10 10 10000 1.75
10 100 10 1.58
10 100 100 1.65
10 100 1000 1.24
10 100 10000 1.12
10 1000 10 1.23
10 1000 100 1.11
10 1000 1000 1.05
10 1000 10000 0.997
100 10 10 1.66
100 10 100 1.78
100 10 1000 1.28
100 10 10000 1.16
100 100 10 1.37
100 100 100 1.26
100 100 1000 1.09
100 100 10000 1.0
100 1000 10 1.19
100 1000 100 1.12
100 1000 1000 1.05
100 1000 10000 1.12
```
The string joining with small or empty separators is now ~50% faster than the old concatenation (small strings). The same approach can also improve the performance of joining into vectors.
If this approach is acceptable, I can apply it for concatenation and for vectors as well. Alternatively, concat could just call `.join("")`.
old tests cover the new fast path of str joining already
this adds tests for joining into Strings with long separators (>4 byte) and
for joining into Vec<T>, T: Clone + !Copy. Vec<T: Copy> will be
specialised when specialisation type inference bugs are fixed.
for both Vec<T> and String
- eliminates the boolean first flag in fn join()
for String only
- eliminates repeated bounds checks in join(), concat()
- adds fast paths for small string separators up to a len of 4 bytes
Make the OOM hook return `()` rather than `!`
Per discussion in https://github.com/rust-lang/rust/issues/51245#issuecomment-393651083
This allows more flexibility in what can be done with the API. This also
splits `rtabort!` into `dumb_print` happening in the default hook and
`abort_internal`, happening in the actual oom handler after calling the
hook. Registering an empty function thus makes the oom handler not print
anything but still abort.
Cc: @alexcrichton
Make const decoding thread-safe.
This is an alternative to https://github.com/rust-lang/rust/pull/50957. It's a proof of concept (e.g. it doesn't adapt metadata decoding, just the incr. comp. cache) but I think it turned out nice. It's rather simple and does not require passing around a bunch of weird closures, like we currently do.
If you (@Zoxc & @oli-obk) think this approach is good then I'm happy to finish and clean this up.
Note: The current version just spins when it encounters an in-progress decoding. I don't have a strong preference for this approach. Decoding concurrently is equally fine by me (or maybe even better because it doesn't require poisoning).
r? @Zoxc
