This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
Don't hardcode the `v1` prelude in diagnostics, to allow for new preludes.
Instead of looking for `std::prelude::v1`, this changes the two places where that was hardcoded to look for `std::prelude::<anything>` instead.
This is needed for https://github.com/rust-lang/rust/pull/82217.
r? `@estebank`
Bump tracing-tree dependency
This bump fixes two small rendering things that were annoying me:
* The first level didn't have an opening line
* When wraparound happens, there was no warning, the levels just disappeared. Now there is a line that shows that wraparound is happening
See https://github.com/davidbarsky/tracing-tree/pull/31/files for how the look changes
Update README.md to use the correct cmake version number
LLVM requires at least cmake 3.13.4 and cmake is only required to build
LLVM.
https://www.llvm.org/docs/CMake.html
Also closes#42555
Add Option::get_or_default
Tracking issue: #82901
The original issue is #55042, which was closed, but for an invalid reason (see discussion there). Opening this to reconsider (I hope that's okay). It seems like the only gap for `Option` being "entry-like".
I ran into a need for this method where I had a `Vec<Option<MyData>>` and wanted to do `vec[n].get_or_default().my_data_method()`. Using an `Option` as an inner component of a data structure is probably where the need for this will normally arise.
Build rustdoc for run-make tests, not just run-make-fulldeps
Rustdoc almost never needs a full stage 2 compiler, and requiring
rustdoc tests to be in run-make-fulldeps adds a lot of compile time for
no reason.
This is the same change from https://github.com/rust-lang/rust/pull/81197, but separated into its own PR. I ran into this again today while working on https://github.com/rust-lang/docs.rs/issues/1302.
r? ```@Mark-Simulacrum```
Fixes to ExitStatus and its docs
* On Unix, properly display every possible wait status (and don't panic on weird values)
* In the documentation, be clear and consistent about "exit status" vs "wait status".
Stabilize `unsafe_op_in_unsafe_fn` lint
This makes it possible to override the level of the `unsafe_op_in_unsafe_fn`, as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896.
Tracking issue: #71668
r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung```
# Stabilization report
This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`.
## Summary
Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside.
The `unsafe_op_in_unsafe_fn` lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block.
For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level.
For more information, see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md)
### Example
```rust
// An `unsafe fn` for demonstration purposes.
// Calling this is an unsafe operation.
unsafe fn unsf() {}
// #[allow(unsafe_op_in_unsafe_fn)] by default,
// the behavior of `unsafe fn` is unchanged
unsafe fn allowed() {
// Here, no `unsafe` block is needed to
// perform unsafe operations...
unsf();
// ...and any `unsafe` block is considered
// unused and is warned on by the compiler.
unsafe {
unsf();
}
}
#[warn(unsafe_op_in_unsafe_fn)]
unsafe fn warned() {
// Removing this `unsafe` block will
// cause the compiler to emit a warning.
// (Also, no "unused unsafe" warning will be emitted here.)
unsafe {
unsf();
}
}
#[deny(unsafe_op_in_unsafe_fn)]
unsafe fn denied() {
// Removing this `unsafe` block will
// cause a compilation error.
// (Also, no "unused unsafe" warning will be emitted here.)
unsafe {
unsf();
}
}
```
This updates all places where match branches check on StatementKind or UseContext.
This doesn't properly implement them, but adds TODOs where they are, and also adds some best
guesses to what they should be in some cases.
I'm still not totally sure if this is the right way to implement the memcpy, but that portion
compiles correctly now. Now to fix the compile errors everywhere else :).
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
diagnostics: Be clear about "crate root" and `::foo` paths in resolve diagnostics
Various changes to make sure the diagnostics are clear about the differences in `::foo` paths across editions:
- `::foo` will say "crate root" in 2015 and "list of imported crates" in 2018
- `crate::` will never reference imported crates in 2018
Fixes https://github.com/rust-lang/rust/issues/82876
Add note about the `#[doc(no-inline)]` usage
This is required to correctly build the documentation (including all submodules, that are only available in certain targets).
See the linked issue and #82861 for reference.
