Revert part of #94372 to improve performance
#94732 was supposed to give small but widespread performance improvements, as judged from three per-merge performance runs. But the performance run that occurred after merging included a roughly equal number of improvements and regressions, for unclear reasons.
This PR is for a test run reverting those changes, to see what happens.
r? `@ghost`
cleanup bound variable handling
each commit should be pretty self-contained and hopefully straightforward to review.
I've added 677ec23a8dbf8ff5f1c03ccebd46f8b85e5ec1fc so that we can stop returning the region map from `replace_bound_vars_with_fresh_vars` in the following commit.
r? `@nikomatsakis` or `@jackh726`
Rollup of 6 pull requests
Successful merges:
- #93331 (refactor write_output_file to merge two invocation paths into one.)
- #97928 (Removes debug settings from wasm32_unknown_emscripten default link args)
- #97940 (Use relative links instead of linking to doc.rust-lang.org when possible)
- #97941 (nit: Fixed several error_codes/Exxxx.md messages which used UpperCamelCase…)
- #97953 (Add regression test for #54378)
- #97957 (Make `std::` prefix suggestion test `run-rustfix`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Removes debug settings from wasm32_unknown_emscripten default link args
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
``@sbc100``
Use `fcntl(fd, F_GETFD)` to detect if standard streams are open
In the previous implementation, if the standard streams were open,
but the RLIMIT_NOFILE value was below three, the poll would fail
with EINVAL:
> ERRORS: EINVAL The nfds value exceeds the RLIMIT_NOFILE value.
Switch to the existing fcntl based implementation to avoid the issue.
Fixes#96621.
Rollup of 6 pull requests
Successful merges:
- #97718 (Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383))
- #97876 (update docs for `std::future::IntoFuture`)
- #97888 (Don't use __gxx_personality_v0 in panic_unwind on emscripten target)
- #97922 (Remove redundant calls to reserve in impl Write for VecDeque)
- #97927 (Do not introduce bindings for types and consts in HRTB.)
- #97937 (Fix a typo in `test/ui/hrtb/hrtb-just-for-static.rs`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Don't use __gxx_personality_v0 in panic_unwind on emscripten target
This resolves#85821. See also the discussion here:
https://github.com/emscripten-core/emscripten/issues/17128
The consensus seems to be that rust_eh_personality is never invoked.
I patched __gxx_personality_v0 to log invocations and then ran
various panic tests and it was never called, so this analysis matches
what seems to happen in practice. This replaces the definition with
an abort, modeled on the structured exception handling implementation.
update docs for `std::future::IntoFuture`
Ref https://github.com/rust-lang/rust/issues/67644.
This updates the docs for `IntoFuture` providing a bit more guidance on how to use it. Thanks!
Fix `delayed_good_path_bug` ice for expected diagnostics (RFC 2383)
Fixes a small ICE with the `delayed_good_path_bug` check.
---
r? ``@wesleywiser``
cc: ``@eddyb`` this might be interesting, since you've added a `FIXME` comment above the modified check which kind of discusses a case like this
closes: https://github.com/rust-lang/rust/issues/95540
cc: https://github.com/rust-lang/rust/issues/85549
std::io: Modify some ReadBuf method signatures to return `&mut Self`
This allows using `ReadBuf` in a builder-like style and to setup a `ReadBuf` and
pass it to `read_buf` in a single expression, e.g.,
```
// With this PR:
reader.read_buf(ReadBuf::uninit(buf).assume_init(init_len))?;
// Previously:
let mut buf = ReadBuf::uninit(buf);
buf.assume_init(init_len);
reader.read_buf(&mut buf)?;
```
r? `@sfackler`
cc https://github.com/rust-lang/rust/issues/78485, https://github.com/rust-lang/rust/issues/94741
Add the Provider api to core::any
This is an implementation of [RFC 3192](https://github.com/rust-lang/rfcs/pull/3192) ~~(which is yet to be merged, thus why this is a draft PR)~~. It adds an API for type-driven requests and provision of data from trait objects. A primary use case is for the `Error` trait, though that is not implemented in this PR. The only major difference to the RFC is that the functionality is added to the `any` module, rather than being in a sibling `provide_any` module (as discussed in the RFC thread).
~~Still todo: improve documentation on items, including adding examples.~~
cc `@yaahc`
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
Revert "remove num_cpus dependency" in rustc and update cargo
Fixes#97549. This PR reverts #94524 and does a Cargo update to pull in rust-lang/cargo#10737.
Rust 1.61.0 has a regression in which it misidentifies the number of available CPUs in some environments, leading to enormously increased memory usage and failing builds. In between Rust 1.60 and 1.61 both rustc and cargo replaced some uses of `num_cpus` with `available_parallelism`, which eliminated support for cgroupv1, still apparently in common use. This PR switches both rustc and cargo back to using `num_cpus` in order to support environments where the available parallelism is controlled by cgroupv1. Both can use `available_parallism` again once it handles cgroupv1 (if ever).
I have confirmed that the rustc part of this PR fixes the memory usage regression in my non-Cargo environment, and others have confirmed in #97549 that the Cargo regression was at fault for the memory usage regression in their environments.
