Dylan DPC [Mon, 22 Mar 2021 14:21:24 +0000 (15:21 +0100)]
Rollup merge of #82683 - jturner314:int-div-rem-doc-panic, r=nikomatsakis
Document panicking cases for integer division and remainder
This PR documents the cases when integer division and remainder operations panic. These operations panic in two cases: division by zero and overflow.
It's surprising that these operations always panic on overflow, unlike most other arithmetic operations, which panic on overflow only when `debug_assertions` is enabled. The panic on overflow for the remainder is also surprising because a return value of `0` would be reasonable in this case. ("Overflow" occurs only for `MIN % -1`.) Since the panics on overflow are somewhat surprising, they should be documented.
I guess it's worth asking: is panic on overflow (even when `debug_assertions` is disabled) the intended behavior? If not, what's the best way forward?
Dylan DPC [Mon, 22 Mar 2021 14:21:23 +0000 (15:21 +0100)]
Rollup merge of #82374 - clehner:licenses, r=joshtriplett
Add license metadata for std dependencies
These five crates are in the dependency tree of `std` but lack license metadata:
- `alloc`
- `core`
- `panic_abort`
- `panic_unwind`
- `unwind`
Querying the dependency tree of `std` is a useful thing to be able to do, since these crates will typically be linked into Rust binaries. Tools show the license fields missing, as seen in https://github.com/rust-lang/rust/issues/67014#issuecomment-782704534. This PR adds the license field for the five crates, based on the license of the `std` package and this repo as a whole. I also added the `repository` and `descriptions` fields, since those seem useful. For `description`, I copied text from top-level comments for the respective modules - except for `unwind` which has none.
I also note that https://github.com/rust-lang/rust/pull/73530 attempted to add license metadata for all crates in this repo, but was rejected because there was question about some of them. I hope that this smaller change, focusing only on the runtime dependencies, will be easier to review.
bors [Mon, 22 Mar 2021 09:37:50 +0000 (09:37 +0000)]
Auto merge of #82680 - jturner314:div_euclid-docs, r=JohnTitor
Fix inequality in docs for div_euclid
This commit fixes the statement of the inequality that the Euclidean remainder satisfies. (The remainder is guaranteed to be less than abs(rhs), not rhs.) It also rewords the documentation to make it a little easier to read.
(You might wonder why I've written `abs(rhs)` instead of `rhs.abs()`. Two reasons: first, the `rem_euclid` docs use `abs(rhs)` instead of `rhs.abs()`, and second, the absolute value here is the mathematical absolute value, not the the `.abs()` operation which may overflow.)
bors [Mon, 22 Mar 2021 06:45:33 +0000 (06:45 +0000)]
Auto merge of #82855 - jyn514:no-temporaries, r=GuillaumeGomez
Avoid temporary allocations in `render_assoc_item`
`render_assoc_item` came up as very hot in a profile of rustdoc on
`bevy`. This avoids some temporary allocations just to calculate the
length of the header.
This should be a strict improvement, since all string formatting was
done twice before.
Dylan DPC [Mon, 22 Mar 2021 01:20:33 +0000 (02:20 +0100)]
Rollup merge of #83350 - jyn514:llvm-version, r=Mark-Simulacrum
Download a more recent LLVM version if `src/version` is modified
When bumping the bootstrap version, the name of the generated LLVM
shared object file is changed, even though it's the same contents as
before. If bootstrap tries to use an older version, it will get linking
errors:
```
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Compiling rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" ... lots of args ...
= note: /usr/bin/ld: cannot find -lLLVM-12-rust-1.53.0-nightly
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: could not compile `rustdoc-tool`
```
Helps with https://github.com/rust-lang/rust/issues/81930.
Dylan DPC [Mon, 22 Mar 2021 01:20:28 +0000 (02:20 +0100)]
Rollup merge of #82686 - CDirkx:unix-platform, r=m-ou-se
Move `std::sys::unix::platform` to `std::sys::unix::ext`
This moves the operating system dependent alias `platform` (`std::os::{linux, android, ...}`) from `std::sys::unix` to `std::sys::unix::ext` (a.k.a. `std::os::unix`), removing the need for compatibility code in `unix_ext` when documenting on another platform.
This is also a step in making it possible to properly move `std::sys::unix::ext` to `std::os::unix`, as ideally `std::sys` should not depend on the rest of `std`.
Dylan DPC [Mon, 22 Mar 2021 01:20:27 +0000 (02:20 +0100)]
Rollup merge of #82554 - SkiFire13:fix-string-retain-unsoundness, r=m-ou-se
Fix invalid slice access in String::retain
As noted in #78499, the previous fix was technically still unsound because it accessed elements of a slice outside its bounds (even though they were still inside the same allocation). This PR addresses that concern by switching to a dropguard approach.
Dylan DPC [Mon, 22 Mar 2021 01:20:24 +0000 (02:20 +0100)]
Rollup merge of #80771 - thomcc:nonnull-refmut, r=dtolnay
Make NonNull::as_ref (and friends) return refs with unbound lifetimes
# Rationale:
1. The documentation for all of these functions claims that this is what the functions already do, as they all come with this comment:
> You must enforce Rust's aliasing rules, *since the returned lifetime 'a is arbitrarily chosen* and does not necessarily reflect the actual lifetime of the data...
So I think it's just a bug that they weren't this way already. Note that had it not been for this part, I wouldn't be making this PR, so if we decide we won't take this change, I'll follow it up with a docs PR to fix this.
2. This is how the equivalent raw pointer functions behave.
They also take `self` and not `&self`/`&mut self`, but that can't be changed compatibly at this point. This is the next best thing.
3. Without this fix, often code that uses these methods will find it has to expand the lifetime of the result.
(I can't speak for others but even in unsafe-heavy code, needing to do this unexpectedly is a huge red flag -- if Rust thinks something should have a specific lifetime, I assume it's for a reason)
### Can this cause existing code to be unsound?
I'm confident this can't cause new unsoundness since the reference exists for at most its lifetime, but you get a borrow checker error if you do something that would require/allow the reference to exist past its lifetime.
Additionally, the aliasing rules of a reference only applies while the reference exists.
This *must* be the case, as it is required by the rules used by safe code. (That said, the documentation in this file sort of contradicts it, but I think it's just ambiguity between the lifetime `'a` in `&'a T` and lifetime of the `&'a T` reference itself...)
We are increasing the lifetime of these references, but they should already have hard bounds on that lifetime, or they'd have borrow checker errors.
(CC ``@RalfJung`` because I have gone and done the mistake where I say something definitive about aliasing in Rust which is honestly outside the group of things I should make definitive comments about).
# Caveats
1. This is insta-stable (except for on the unstable functions ofc). I don't think there's any other alternative.
2. I don't believe this is a breaking change in practice. In theory someone could be assigning `NonNull::as_ref` to a function pointer of type `fn(&NonNull<T>) -> &T`. Now they'd need to use a slightly different function pointer type which is (probably) incompatible. This seems pathological, but I guess crater could be used if there are concerns.
3. This has no tests. The old version didn't either that I saw. I could add some stuff that fails to compile without it, if that would be useful.
4. Sometimes the NLL borrow checker gives up and decides lifetimes live till the end of the scope, as opposed to the range where they're used. If this change can cause this to happen more, then my soundness rationale is wrong, and it's likely breaking.
bors [Mon, 22 Mar 2021 01:16:29 +0000 (01:16 +0000)]
Auto merge of #79846 - the8472:inplace-tra, r=m-ou-se
Use TrustedRandomAccess for in-place iterators where possible
This can speed up in-place iterators containing simple casts and transmutes from `Copy` types to any type of same size. `!Copy` types can't be optimized since `TrustedRandomAccess` isn't implemented for those iterators.
bors [Sun, 21 Mar 2021 21:54:09 +0000 (21:54 +0000)]
Auto merge of #82834 - nikic:mutable-noalias, r=nagisa
Enable mutable noalias for LLVM >= 12
Enable mutable noalias by default on LLVM 12, as previously known miscompiles have been resolved. Now it's time to find the next one ;)
* The `-Z mutable-noalias` option no longer has an explicit default and accepts `-Z mutable-noalias=yes` and `-Z mutable-noalias=no` to override the LLVM version based default behavior.
* The decision on whether to apply the noalias attribute is moved into rustc_codegen_llvm. rustc_middle only provides us with the necessary information to make the decision.
* `noalias` is not emitted for types that are `!Unpin`, as a heuristic for self-referential structures (see #54878 and #63818).
Nikita Popov [Fri, 19 Mar 2021 21:49:51 +0000 (22:49 +0100)]
Don't compute optimized PointerKind for unoptimized builds
This saves us both the Freeze/Unpin queries, and avoids placing
noalias attributes, which have a compile-time impact on LLVM
even in optnone builds (due to always_inline functions).
The8472 [Tue, 8 Dec 2020 22:21:27 +0000 (23:21 +0100)]
specialize in-place collection further via TrustedRandomAccess
This allows the optimizer to turn certain iterator pipelines such as
```rust
let vec = vec![0usize; 100];
vec.into_iter().map(|e| e as isize).collect::<Vec<_>>()
```
into a noop.
The optimization only applies when iterator sources are `T: Copy`
since `impl TrustedRandomAccess for IntoIter<T>`.
No such requirement applies to the output type (`Iterator::Item`).
Nikita Popov [Thu, 18 Mar 2021 21:44:36 +0000 (22:44 +0100)]
Don't consider !Unpin references as noalias
Such structures may contain self-references, in which case the
same location may be accessible through a pointer that is not
based-on the noalias pointer.
This is still grey area as far as language semantics are concerned,
but checking for !Unpin as an indicator for self-referential
sturctures seems like a good approach for the meantime.
Nikita Popov [Thu, 18 Mar 2021 20:50:28 +0000 (21:50 +0100)]
Move decision aboute noalias into codegen_llvm
The frontend shouldn't be deciding whether or not to use mutable
noalias attributes, as this is a pure LLVM concern. Only provide
the necessary information and do the actual decision in
codegen_llvm.
Joshua Nelson [Sun, 21 Mar 2021 16:10:34 +0000 (12:10 -0400)]
Download a more recent LLVM version if `src/version` is modified
When bumping the bootstrap version, the name of the generated LLVM
shared object file is changed, even though it's the same contents as
before. If bootstrap tries to use an older version, it will get linking
errors:
```
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Compiling rustdoc-tool v0.0.0 (/home/joshua/rustc/src/tools/rustdoc)
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" ... lots of args ...
= note: /usr/bin/ld: cannot find -lLLVM-12-rust-1.53.0-nightly
clang: error: linker command failed with exit code 1 (use -v to see invocation)
bors [Sun, 21 Mar 2021 13:00:22 +0000 (13:00 +0000)]
Auto merge of #83339 - Aaron1011:deep-recollect, r=petrochenkov
Perform 'deep recollection' in test helper macros
Currently, the print helper macro performs 'recollection' by doing
`token_stream.into_iter().collect()`. However, this will not affect
nonterminals that occur nested inside delimited groups, since the
wrapping delimited group will be left untouched.
This commit adds 'deep recollection', which recursively recollects every
delimited group in the token stream. As with normal recollection, we
only print out something if deep recollection results in a different
stringified token stream.
This is useful for catching bugs where we update the AST of a
nonterminal (which affects pretty-printing), but do not update the
attatched `TokenStream`
Aaron Hill [Sun, 21 Mar 2021 04:17:19 +0000 (00:17 -0400)]
Perform 'deep recollection' in test helper macros
Currently, the print helper macro performs 'recollection' by doing
`token_stream.into_iter().collect()`. However, this will not affect
nonterminals that occur nested inside delimited groups, since the
wrapping delimited group will be left untouched.
This commit adds 'deep recollection', which recursively recollects every
delimited group in the token stream. As with normal recollection, we
only print out something if deep recollection results in a different
stringified token stream.
This is useful for catching bugs where we update the AST of a
nonterminal (which affects pretty-printing), but do not update the
attatched `TokenStream`
Dylan DPC [Sun, 21 Mar 2021 01:01:39 +0000 (02:01 +0100)]
Rollup merge of #83306 - Aaron1011:js-sys-lint, r=petrochenkov
Extend `proc_macro_back_compat` lint to `js-sys`
With this PR, we now lint for all cases where we perform some kind of
proc-macro back-compat hack.
The `js-sys` had an internal fix made to properly handle
`None`-delimited groups, so we need to manually check the version in the
filename. As a result, we no longer apply the back-compat hack to cases
where the version number is missing file the file path. This should not
affect any users of the `crates.io` crate.
Dylan DPC [Sun, 21 Mar 2021 01:01:34 +0000 (02:01 +0100)]
Rollup merge of #82707 - BoxyUwU:errooaaar, r=oli-obk
const_evaluatable_checked: Stop eagerly erroring in `is_const_evaluatable`
Fixes #82279
We don't want to be emitting errors inside of is_const_evaluatable because we may call this during selection where it should be able to fail silently
There were two errors being emitted in `is_const_evaluatable`. The one causing the compile error in #82279 was inside the match arm for `FailureKind::MentionsParam` but I moved the other error being emitted too since it made things cleaner imo
The `NotConstEvaluatable` enum \*should\* have a fourth variant for when we fail to evaluate a concrete const, e.g. `0 - 1` but that cant happen until #81339
Camelid [Sat, 20 Mar 2021 21:21:02 +0000 (14:21 -0700)]
Cleanup LLVM debuginfo module docs
* Use Markdown list syntax and unindent a bit to prevent Markdown
interpreting the nested lists as code blocks
* A few more small typographical cleanups
bors [Sat, 20 Mar 2021 16:20:21 +0000 (16:20 +0000)]
Auto merge of #83314 - Aaron1011:print-unstable-value, r=lcnr
Debug-print result when an unstable fingerprint is detected
Helps with issues like #83311
I had previously tried to do this in https://github.com/rust-lang/rust/pull/80692, but it had a significant performance impact (even though the code was never actually run). Hopefully, this will be better now that https://github.com/rust-lang/rust/pull/79100 has been merged.
bors [Sat, 20 Mar 2021 03:49:10 +0000 (03:49 +0000)]
Auto merge of #83293 - osa1:82436_perf, r=varkor
Revert performance-sensitive change in #82436
This change was done in #82436, as an "optimization". Unfortunately I
missed that this code is not always executed, because of the "continue"
in the conditional above it.
This commit should solve the perf regressions introduced by #82436 as I
think there isn't anything else that could affect runtime performance in
that PR. The `Pick` type grows only one word, which I doubt can cause up
to 8.8% increase in RSS in some of the benchmarks.
---
Could someone with the rights start a perf job please?
bors [Fri, 19 Mar 2021 23:53:02 +0000 (23:53 +0000)]
Auto merge of #83308 - Dylan-DPC:rollup-p2j6sy8, r=Dylan-DPC
Rollup of 8 pull requests
Successful merges:
- #79986 (Only build help popup when it's really needed)
- #82570 (Add `as_str` method for split whitespace str iterators)
- #83244 (Fix overflowing length in Vec<ZST> to VecDeque)
- #83254 (Include output stream in `panic!()` documentation)
- #83269 (Revert the second deprecation of collections::Bound)
- #83277 (Mark early otherwise optimization unsound)
- #83285 (Update LLVM to bring in SIMD updates for WebAssembly)
- #83297 (Do not ICE on ty::Error as an error must already have been reported)
Dylan DPC [Fri, 19 Mar 2021 22:01:41 +0000 (23:01 +0100)]
Rollup merge of #83285 - alexcrichton:wasm-simd-update, r=cuviper
Update LLVM to bring in SIMD updates for WebAssembly
This is a continuation of https://github.com/rust-lang/llvm-project/pull/96
to continue to make progress on updating Rust's support for SIMD
intrinsics on WebAssembly to the latest version of the specification.
Dylan DPC [Fri, 19 Mar 2021 22:01:39 +0000 (23:01 +0100)]
Rollup merge of #83269 - bstrie:revertdep, r=m-ou-se
Revert the second deprecation of collections::Bound
Per the review at https://github.com/rust-lang/rust/pull/82122#discussion_r596448078 and the decision at https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/unavoidable.20breakage.20when.20deprecating.20an.20enum.3F , revert this small portion of #82122 for the time being. This doesn't affect the other components of that patch, i.e. `intrinsics::drop_in_place` is still deprecated-for-real, and uses of `collections::Bound` remain removed from the repo.
Dylan DPC [Fri, 19 Mar 2021 22:01:37 +0000 (23:01 +0100)]
Rollup merge of #83244 - cuviper:vec_deque-zst, r=m-ou-se
Fix overflowing length in Vec<ZST> to VecDeque
`Vec` can hold up to `usize::MAX` ZST items, but `VecDeque` has a lower
limit to keep its raw capacity as a power of two, so we should check
that in `From<Vec<T>> for VecDeque<T>`. We can also simplify the
capacity check for the remaining non-ZST case.
Before this fix, the new test would fail on the length:
That was a result of `len()` using a mask `& (size - 1)` with the
improper length. Now we do get a "capacity overflow" panic as soon as
that `VecDeque::from(vec)` is attempted.
Dylan DPC [Fri, 19 Mar 2021 22:01:35 +0000 (23:01 +0100)]
Rollup merge of #82570 - WaffleLapkin:split_whitespace_as_str, r=m-ou-se
Add `as_str` method for split whitespace str iterators
This PR adds `as_str` methods to `SplitWhitespace` and `SplitAsciiWhitespace`
str iterators. The methods return the remainder, similar to `as_str` methods on
`Chars` and other split iterators. This PR is a continuation of https://github.com/rust-lang/rust/pull/75265, which added `as_str` for all other str split iterators.
The feature gate for new methods is `#![feature(str_split_whitespace_as_str)]`.
`SplitWhitespace` and `SplitAsciiWhitespace` use iterators under the hood, so to implement `as_str` it's required to either
1. Make fields of some iterators `pub(crate)`
2. Add getter methods (like `into_inner`, `inner`, `inner_mut`...) to some (all) iterators
3. Completely rewrite `SplitWhitespace` and `SplitAsciiWhitespace`
This PR uses the 1. approach since it's easier to implement and requires fewer changes (and no changes to the public API). If you think that's not the right way, please, tell me.
Dylan DPC [Fri, 19 Mar 2021 22:01:29 +0000 (23:01 +0100)]
Rollup merge of #79986 - GuillaumeGomez:build-help-when-needed, r=Nemo157
Only build help popup when it's really needed
When working on https://github.com/rust-lang/rust/pull/79985, I realized that the help popup was built even when it wasn't needed. This PR only makes the help popup to be built when required.
Aaron Hill [Fri, 19 Mar 2021 15:10:01 +0000 (11:10 -0400)]
Extend `proc_macro_back_compat` lint to `js-sys`
With this PR, we now lint for all cases where we perform some kind of
proc-macro back-compat hack.
The `js-sys` had an internal fix made to properly handle
`None`-delimited groups, so we need to manually check the version in the
filename. As a result, we no longer apply the back-compat hack to cases
where the version number is missing file the file path. This should not
affect any users of the `crates.io` crate.
bors [Fri, 19 Mar 2021 18:23:44 +0000 (18:23 +0000)]
Auto merge of #82951 - sexxi-goose:wr-mir-replace-methods2, r=nikomatsakis
Replace closures_captures and upvar_capture with closure_min_captures
Removed all uses of closures_captures and upvar_capture and refactored code to work with closure_min_captures. This also involved removing functions that were no longer needed like the bridge.
Dylan DPC [Fri, 19 Mar 2021 14:03:29 +0000 (15:03 +0100)]
Rollup merge of #83270 - steffahn:missing_word_in_skip_while_doc, r=joshtriplett
Fix typo/inaccuracy in the documentation of Iterator::skip_while
One of the examples used to say “this leads to a possibly confusing situation, where the type of the closure is a double reference” while _actually_ referring to the type of the closure _argument_.
This PR just changes a single word in documentation.
Dylan DPC [Fri, 19 Mar 2021 14:03:26 +0000 (15:03 +0100)]
Rollup merge of #83215 - bstrie:dephaikuraw, r=joshtriplett
Deprecate std::os::haiku::raw, which accidentally wasn't deprecated
In early 2016, all `std::os::*::raw` modules [were deprecated](https://github.com/rust-lang/rust/commit/aa23c98450063992473d40d707273903f8a3937d) in accordance with [RFC 1415](https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md). However, at this same time support for Haiku was being added to libstd, landing shortly after the aforementioned commit, and due to some crossed wires a `std::os::haiku::raw` module was added and was not marked as deprecated.
I have been in correspondence with the author of the Haiku patch, ````@nielx,```` who has confirmed that this was simply an oversight and that the definitions from the libc crate should be preferred instead.
Dylan DPC [Fri, 19 Mar 2021 14:03:23 +0000 (15:03 +0100)]
Rollup merge of #83179 - Aaron1011:actix-web-lint, r=petrochenkov
Extend `proc_macro_back_compat` lint to `actix-web`
Unlike the other cases of this lint, there's no simple way to detect if
an old version of the relevant crate (`syn`) is in use. The `actix-web`
crate only depends on `pin-project` v1.0.0, so checking the version of
`actix-web` does not guarantee that a new enough version of
`pin-project` (and therefore `syn`) is in use.
Instead, we rely on the fact that virtually all of the regressed crates
are pinned to a pre-1.0 version of `pin-project`. When this is the case,
bumping the `actix-web` dependency will pull in the *latest* version of
`pin-project`, which has an explicit dependency on a newer v dependency
on a newer version of `syn`.
The lint message tells users to update `actix-web`, since that's what
they're most likely to have control over. We could potentially tell them
to run `cargo update -p syn`, but I think it's more straightforward to
suggest an explicit change to the `Cargo.toml`
The `actori-web` fork had its last commit over a year ago, and appears
to just be a renamed fork of `actix-web`. Therefore, I've removed the
`actori-web` check entirely - any crates that actually get broken can
simply update `syn` themselves.
Dylan DPC [Fri, 19 Mar 2021 14:03:22 +0000 (15:03 +0100)]
Rollup merge of #82892 - jix:clarify-read-read, r=joshtriplett
Clarify docs for Read::read's return value
Right now the docs for `Read::read`'s return value are phrased in a way that makes it easy for the reader to assume that the return value is never larger than the passed buffer. This PR clarifies that this is a requirement for implementations of the trait, but that callers have to expect a buggy yet safe implementation failing to do so, especially if unchecked accesses to the buffer are done afterwards.
I fell into this trap recently, and when I noticed, I looked at the docs again and had the feeling that I might not have been the first one to miss this.
The same issue of trusting the return value of `read` was also present in std itself for about 2.5 years and only fixed recently, see #80895.
I hope that clarifying the docs might help others to avoid this issue.
Dylan DPC [Fri, 19 Mar 2021 14:03:20 +0000 (15:03 +0100)]
Rollup merge of #82759 - m-ou-se:remove-unwrap-none, r=petrochenkov
Remove unwrap_none/expect_none from compiler/.
We're not going to stabilize `Option::{unwrap_none, expect_none}`. (See https://github.com/rust-lang/rust/issues/62633.) This removes the usage of those unstable methods from `compiler/`.
Dylan DPC [Fri, 19 Mar 2021 14:03:14 +0000 (15:03 +0100)]
Rollup merge of #82500 - CDirkx:hermit-pipe, r=joshtriplett
Reuse `std::sys::unsupported::pipe` on `hermit`
Pipes are not supported on `hermit` and `hermit/pipe.rs` is identical to `unsupported/pipe.rs`. This PR reduces duplication between the two by doing the following on `hermit`:
```rust
#[path = "../unsupported/pipe.rs"]
pub mod pipe;
```
bors [Fri, 19 Mar 2021 12:44:33 +0000 (12:44 +0000)]
Auto merge of #82754 - rylev:rusage-windows, r=pnkfelix
Attempt to gather similar stats as rusage on Windows
A follow up to #82532. This is a bit hacked in because I think we need to discuss this before merging, but this is an attempt to gather similar metrics as `libc::rusage` on Windows.
Some comments on differences:
* Currently, we're passing `RUSAGE_CHILDREN` to `rusage` which collects statistics on all children that have been waited on and terminated. I believe this is currently just the invocation of the real `rustc` that the shim is wrapping. Does `rustc` itself spawn children processes? The windows version gets the child processes handle when spawning it, and uses that to collect the statistics. For maxrss, `rusage` will return "the resident set size of the largest child, not the maximum resident set size of the process tree.", the Windows version will only collect statistics on the wrapped `rustc` child process directly even if some theoretical sub process has a larger memory footprint.
* There might be subtle differences between `rusage`'s "resident set" and Window's "working set". The "working set" and "resident set" should both be the number of pages that are in memory and which would not cause a page fault when accessed.
* I'm not yet sure how best to get the same information that `ru_minflt`, `ru_inblock`, `ru_oublock`, `ru_nivcsw ` and `ru_nvcsw` provide.
This change was done in #82436, as an "optimization". Unfortunately I
missed that this code is not always executed, because of the "continue"
in the conditional above it.
This commit should solve the perf regressions introduced by #82436 as I
think there isn't anything else that could affect runtime performance in
that PR. The `Pick` type grows only one word, which I doubt can cause up
to 8.8% increase in RSS in some of the benchmarks.