Rollup of 6 pull requests
Successful merges:
- #51143 (Specify that packed types must derive, not implement, Copy)
- #51226 (Make Layout's align a NonZeroUsize)
- #51297 (Fix run button style)
- #51306 (impl Default for &mut str)
- #51312 (Clarify the difference between get_mut and into_mut for OccupiedEntry)
- #51313 (use type name in E0599 enum variant suggestion)
Failed merges:
Clarify the difference between get_mut and into_mut for OccupiedEntry
The examples for both hash_map::OccupiedEntry::get_mut and
hash_map::OccupiedEntry::into_mut were almost identical. This led to some
confusion over the difference, namely why you would ever use get_mut when
into_mut gives alonger lifetime. Reddit thread:
https://www.reddit.com/r/rust/comments/8a5swr/why_does_hashmaps
This commit adds two lines and a comment to the example, to show that the
entry object can be re-used after calling get_mut.
Closes https://github.com/rust-lang/rust/issues/49745
Make Layout's align a NonZeroUsize
This PR makes the `Layout`'s align field a `NonZeroUsize` since it cannot ever be zero, not even while building a `Layout`. It also contains some drive-by minor cleanups over the docs and the code, like updating the documented error types, or using the `size()` and `align()` methods instead of accessing the fields directly (the latter was required for the `NonZeroUsize` change anyways).
r? @SimonSapin
cc @Amanieu
The examples for both hash_map::OccupiedEntry::get_mut and
hash_map::OccupiedEntry::into_mut were almost identical. This led
to some confusion over the difference, namely why you would ever
use get_mut when into_mut gives alonger lifetime. Reddit thread:
https://www.reddit.com/r/rust/comments/8a5swr/why_does_hashmaps
This commit adds two lines and a comment to the example, to show
that the entry object can be re-used after calling get_mut.
Fix typos of ‘ambiguous’
I had trouble finding this code because of the typo after it was [referenced in a tweet](https://twitter.com/bstrie/status/1002751044605153280). Also fixes an identical but unrelated typo in a comment.
Add as_nanos function to Duration
Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an `as_nanos` function to expose the capability.
Fix building rustc on and for musl hosts.
This fixes all problems I had when trying to compile rustc on a musl-based distribution (with `crt-static = false` in `config.toml`).
This is a fixed version of what ended up being #50105, making it possible to compile rustc on musl targets.
The differences to the old (now merged and subsequently reverted) pull request are:
- The commit (6d9154a830) that caused the regression for which the original commits were reverted in #50709 is left out. This means the corresponding bug #36710 is still not fixed with `+crt-static`.
- The test for issue 36710 is skipped for musl targets (until the issue is properly fixed).
- Building cargo-vendor if `crt-static = false` is needed was broken (cargo-vendor links to some shared libraries if they exist on the system and this produces broken binaries with `+crt-static`)
CC @alexcrichton
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`
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("")`.
Jorge Aparicio