Update CONTRIBUTING.md
Fixes#77215
As mentioned in #77215, the current CONTRIBUTING.md links to the rustc-dev-guide.
Even though the rustc-dev-guide has lots of useful information for contributors,
one is already confused by reading the first line of the current CONTRIBUTING.md.
> To get started, read the [Getting Started] guide in the [rustc-dev-guide].
This line tells the contributor to go and read the rustc-dev-guide. What is
the rustc-dev-guide? What does rustc even mean? These are some of the
questions that went into my head when reading this line as a first-time
contributor. By explaining what the rustc-dev-guide is and some platforms
to get help, a new contributor understands what the first step is and the process
is much clearer. The `About the [rustc-dev-guide]` section explains what
the rustc-dev-guide is, what rustc is, and the purpose out of reading the
guide. The `Getting help` section points the user to some places where
they can get help, find a mentor, and introduce themselves.
Update Cargo
Output of `git log --oneline c68432f1e..970bc67c3`:
970bc67c3 (HEAD, origin/master, origin/auto-cargo, origin/HEAD) Auto merge of #9243 - wickerwaka:configurable-env-doc, r=ehuss
4d7a29b75 Document the configurable-env usntable option
f7a7a3f91 Auto merge of #9229 - alexcrichton:fix-borrow-mut, r=ehuss
3f2ece7a9 Fix a `BorrowMut` error when stdout is closed
7441e8c23 Auto merge of #8825 - Aaron1011:feature/report-future-incompat, r=ehuss
139ed73f5 Add future-incompat tracking issue number.
9ea350368 Fix some minor formatting issues.
f03d47ce4 Address review comments
6177c6584 Implement future incompatibility report support
c69409658 Auto merge of #9022 - nagisa:nagisa/manifest_path, r=alexcrichton
548300b20 Add the path to the manifest in json output
99e714c05 Auto merge of #9230 - kornelski:nobinaries, r=alexcrichton
61a31bc5f Auto merge of #9236 - kornelski:track-assert, r=Eh2406
3f7f0942c track_caller on custom assert functions
6977dee10 Explain `cargo install` is not for libraries
e4aebf0a0 Auto merge of #9231 - joshtriplett:clear-to-eol-if-color, r=alexcrichton
b219f0eb7 Auto merge of #9181 - jyn514:computer-says-no, r=ehuss
0b1816578 Remove unhelpful link to Cargo book
ea46f5ce3 Use ANSI clear-to-EOL if color is force-enabled
a6394bcc1 Remove unnecessary `config` argument to `Features::add`
3a86ecf2d Fix TODO about nightly features
09677c83c Be less unix-centric in error messages
ecfdced0d Fix test that assumed tests always were run on the stable channel
eba541994 Update comment in build_script_env
a5720117f Make `nightly_features_allowed` a field instead of a function
169b09ce7 Compute `enable_nightly_features` once instead of on each call
8fc86e155 Remove unused thread_locals
4b096beae Fix `masquerade_as_nightly_cargo` in work threads
e56417c8c Suggest RUSTC_BOOTSTRAP=crate instead of RUSTC_BOOTSTRAP=1
418129dae Downgrade error to a warning when `RUSTC_BOOTSTRAP` is set or this is the nightly channel
6c422a2c0 Restrict RUSTC_BOOTSTRAP in build.rs
Change x64 size checks to not apply to x32.
Rust contains various size checks conditional on target_arch = "x86_64", but these checks were never intended to apply to x86_64-unknown-linux-gnux32. Add target_pointer_width = "64" to the conditions.
Bump libc dependency of std to 0.2.88.
This PR bumps the `libc` dependency of `std` to 0.2.88. This will fix `TcpListener::accept` for Android on x86 platforms (31a2777d8f).
This will really finally fix https://github.com/rust-lang/rust/issues/82400 for the main branch :)
r? ``@JohnTitor``
or-patterns: disallow in `let` bindings
~~Blocked on https://github.com/rust-lang/rust/pull/81869~~
Disallows top-level or-patterns before type ascription. We want to reserve this syntactic space for possible future generalized type ascription.
r? ``@petrochenkov``
Added #[repr(transparent)] to core::cmp::Reverse
I found casting from an `&T` to an `&Reverse<T>` potentially useful, but found that `Reverse` was not `#[repr(transparent)]`, so after asking about it [on Reddit](https://www.reddit.com/r/rust/comments/le60uv/make_stdcmpreverse_reprtransparent_and_add_a/), I decided to go ahead and make a pull request which simply adds the attribute to the struct.
Improve sift_down performance in BinaryHeap
Replacing `child < end - 1` with `child <= end.saturating_sub(2)` in `BinaryHeap::sift_down_range` (surprisingly) results in a significant speedup of `BinaryHeap::into_sorted_vec`. The same substitution can be done for `BinaryHeap::sift_down_to_bottom`, which causes a slight but probably statistically insignificant speedup for `BinaryHeap::pop`. It's interesting that benchmarks aside from `bench_into_sorted_vec` are barely affected, even those that do use `sift_down_*` methods internally.
| Benchmark | Before (ns/iter) | After (ns/iter) | Speedup |
|--------------------------|------------------|-----------------|---------|
| bench_find_smallest_1000<sup>1</sup> | 392,617 | 385,200 | 1.02 |
| bench_from_vec<sup>1</sup> | 506,016 | 504,444 | 1.00 |
| bench_into_sorted_vec<sup>1</sup> | 476,869 | 384,458 | 1.24 |
| bench_peek_mut_deref_mut<sup>3</sup> | 518,753 | 519,792 | 1.00 |
| bench_pop<sup>2</sup> | 446,718 | 444,409 | 1.01 |
| bench_push<sup>3</sup> | 772,481 | 770,208 | 1.00 |
<sup>1</sup>: internally calls `sift_down_range`
<sup>2</sup>: internally calls `sift_down_to_bottom`
<sup>3</sup>: should not be affected
rustdoc: Cleanup `html::render::Context`
- Move most shared fields to `SharedContext` (except for `cache`, which
isn't mutated anyway)
- Replace a use of `Arc` with `Rc`
- Make a bunch of fields private
- Add static size assertion for `Context`
- Don't share `id_map` and `deref_id_map`
Fixes#77215
As mentioned in #77215, the current CONTRIBUTING.md links to the rustc-dev-guide.
Even though the rustc-dev-guide has lots of useful information for contributors,
one is already confused by reading the first line of the current CONTRIBUTING.md.
> To get started, read the [Getting Started] guide in the [rustc-dev-guide].
This line tells the contributor to go and read the rustc-dev-guide. What is
the rustc-dev-guide? What does rustc even mean? These are some of the
questions that went into my head when reading this line as a first time
contributor. By explaining what the rustc-dev-guide is and some platforms
to get help, a new contributor understands what the first step is and the process
is much clearer. The `About the [rustc-dev-guide]` section explains what
the rustc-dev-guide is, what rustc is, and the purpose out of reading the
guide. The `Getting help` section points the user to some places where
they can get help, find a mentor, and introduce themsevles.
Revert switch of env locking to rwlock, to fix deadlock in process spawning
This reverts commit 354f19cf24, reversing changes made to 0cfba2fd09.
PR https://github.com/rust-lang/rust/pull/81850 switched the environment lock from a mutex to an rwlock. However, process spawning (when not able to use `posix_spawn`) locks the environment before forking, and unlocks it after forking (in both the parent and the child). With a mutex, this works (although probably not correct even with a mutex). With an rwlock, on at least some targets, unlocking in the child does not work correctly, resulting in a deadlock.
This has manifested as CI hangs on i686 Linux; that target doesn't use `posix_spawn` in the CI environment due to the age of the installed C library (currently glibc 2.23). (Switching to `posix_spawn` would just mask this issue, though, which would still arise in any case that can't use `posix_spawn`.)
Some additional cleanup of environment handling around process spawning may help, but for now, revert the PR and go back to a standard mutex.
Fixes#82221
