kadmin [Mon, 5 Oct 2020 22:53:00 +0000 (22:53 +0000)]
Update match branches
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.
kadmin [Mon, 5 Oct 2020 20:13:36 +0000 (20:13 +0000)]
Update fmt and use of memcpy
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 :).
Mara Bos [Tue, 9 Mar 2021 09:05:27 +0000 (09:05 +0000)]
Rollup merge of #82887 - henryboisdequin:improve-contributing-md, r=joshtriplett
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.
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
Mara Bos [Tue, 9 Mar 2021 09:05:24 +0000 (09:05 +0000)]
Rollup merge of #82841 - hvdijk:x32, r=joshtriplett
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.
Mara Bos [Tue, 9 Mar 2021 09:05:22 +0000 (09:05 +0000)]
Rollup merge of #82731 - de-vri-es:bump-libc-for-std, r=Mark-Simulacrum
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 (https://github.com/rust-lang/libc/commit/31a2777d8f72db9eb3c3105f13afa94a47ca90d5).
This will really finally fix https://github.com/rust-lang/rust/issues/82400 for the main branch :)
Mara Bos [Tue, 9 Mar 2021 09:05:19 +0000 (09:05 +0000)]
Rollup merge of #81879 - imbrem:make-reverse-repr-transparent, r=m-ou-se
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.
Mara Bos [Tue, 9 Mar 2021 09:05:18 +0000 (09:05 +0000)]
Rollup merge of #81127 - hanmertens:binary_heap_sift_down_perf, r=dtolnay
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.
bors [Tue, 9 Mar 2021 04:33:43 +0000 (04:33 +0000)]
Auto merge of #82356 - camelid:render-cleanup, r=GuillaumeGomez
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`
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.
Dan Gohman [Tue, 9 Mar 2021 01:46:03 +0000 (17:46 -0800)]
WASI: Switch to crt1-command.o to enable support for new-style commands
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
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.
Dylan DPC [Mon, 8 Mar 2021 12:13:27 +0000 (13:13 +0100)]
Rollup merge of #82862 - athre0z:generalize-vec-write-impl, r=TimDiekmann
Generalize Write impl for Vec<u8> to Vec<u8, A>
As discussed in the [issue tracker for the wg-allocators working group][1], updating this impl for allocator support was most likely just forgotten previously. This PR fixes this.
Dylan DPC [Mon, 8 Mar 2021 12:13:25 +0000 (13:13 +0100)]
Rollup merge of #82755 - osa1:confirm_builtin_call_refactor, r=petrochenkov
Refactor confirm_builtin_call, remove partial if
Pass callee expr to `confirm_builtin_call`. This removes a partial
pattern match in `confirm_builtin_call` and the `panic` in the `else`
branch. The diff is large because of indentation changes caused by
removing the if-let.
Dylan DPC [Mon, 8 Mar 2021 12:13:23 +0000 (13:13 +0100)]
Rollup merge of #82682 - petrochenkov:cfgeval, r=Aaron1011
Implement built-in attribute macro `#[cfg_eval]` + some refactoring
This PR implements a built-in attribute macro `#[cfg_eval]` as it was suggested in https://github.com/rust-lang/rust/pull/79078 to avoid `#[derive()]` without arguments being abused as a way to configure input for other attributes.
The macro is used for eagerly expanding all `#[cfg]` and `#[cfg_attr]` attributes in its input ("fully configuring" the input).
The effect is identical to effect of `#[derive(Foo, Bar)]` which also fully configures its input before passing it to macros `Foo` and `Bar`, but unlike `#[derive]` `#[cfg_eval]` can be applied to any syntax nodes supporting macro attributes, not only certain items.
`cfg_eval` was the first name suggested in https://github.com/rust-lang/rust/pull/79078, but other alternatives are also possible, e.g. `cfg_expand`.
```rust
#[cfg_eval]
#[my_attr] // Receives `struct S {}` as input, the field is configured away by `#[cfg_eval]`
struct S {
#[cfg(FALSE)]
field: u8,
}
```
Dylan DPC [Mon, 8 Mar 2021 12:13:19 +0000 (13:13 +0100)]
Rollup merge of #82415 - petrochenkov:modin3, r=davidtwco
expand: Refactor module loading
This is an accompanying PR to https://github.com/rust-lang/rust/pull/82399, but they can be landed independently.
See individual commits for more details.
Anyone should be able to review this equally well because all people actually familiar with this code left the project.
Dylan DPC [Mon, 8 Mar 2021 12:13:18 +0000 (13:13 +0100)]
Rollup merge of #82047 - the8472:fast-rename, r=davidtwco
bypass auto_da_alloc for metadata files
This saves about 0.7% when rerunning the UI test suite. I.e. when the metadata files exist and will be overwritten. No improvements expected for a clean build. So it might show up in incr-patched perf results.
```
regular rename:
Benchmark #1: touch src/tools/compiletest/src/main.rs ; RUSTC_WRAPPER="" schedtool -B -e ./x.py test src/test/ui
Time (mean ± σ): 47.305 s ± 0.170 s [User: 1631.540 s, System: 412.648 s]
Range (min … max): 47.125 s … 47.856 s 20 runs
non-durable rename:
Benchmark #1: touch src/tools/compiletest/src/main.rs ; RUSTC_WRAPPER="" schedtool -B -e ./x.py test src/test/ui
Time (mean ± σ): 46.930 s ± 0.064 s [User: 1634.344 s, System: 396.038 s]
Range (min … max): 46.759 s … 47.043 s 20 runs
```
There are more places that trigger auto_da_alloc behavior by overwriting existing files with O_TRUNC, but those are much harder to locate because `O_TRUNC` is set on `open()` but the writeback is triggered on `close()`. The latter is the part which shows up in profiles.
bors [Sun, 7 Mar 2021 23:45:57 +0000 (23:45 +0000)]
Auto merge of #81635 - michaelwoerister:structured_def_path_hash, r=pnkfelix
Let a portion of DefPathHash uniquely identify the DefPath's crate.
This allows to directly map from a `DefPathHash` to the crate it originates from, without constructing side tables to do that mapping -- something that is useful for incremental compilation where we deal with `DefPathHash` instead of `DefId` a lot.
It also allows to reliably and cheaply check for `DefPathHash` collisions which allows the compiler to gracefully abort compilation instead of running into a subsequent ICE at some random place in the code.
The following new piece of documentation describes the most interesting aspects of the changes:
```rust
/// A `DefPathHash` is a fixed-size representation of a `DefPath` that is
/// stable across crate and compilation session boundaries. It consists of two
/// separate 64-bit hashes. The first uniquely identifies the crate this
/// `DefPathHash` originates from (see [StableCrateId]), and the second
/// uniquely identifies the corresponding `DefPath` within that crate. Together
/// they form a unique identifier within an entire crate graph.
///
/// There is a very small chance of hash collisions, which would mean that two
/// different `DefPath`s map to the same `DefPathHash`. Proceeding compilation
/// with such a hash collision would very probably lead to an ICE and, in the
/// worst case, to a silent mis-compilation. The compiler therefore actively
/// and exhaustively checks for such hash collisions and aborts compilation if
/// it finds one.
///
/// `DefPathHash` uses 64-bit hashes for both the crate-id part and the
/// crate-internal part, even though it is likely that there are many more
/// `LocalDefId`s in a single crate than there are individual crates in a crate
/// graph. Since we use the same number of bits in both cases, the collision
/// probability for the crate-local part will be quite a bit higher (though
/// still very small).
///
/// This imbalance is not by accident: A hash collision in the
/// crate-local part of a `DefPathHash` will be detected and reported while
/// compiling the crate in question. Such a collision does not depend on
/// outside factors and can be easily fixed by the crate maintainer (e.g. by
/// renaming the item in question or by bumping the crate version in a harmless
/// way).
///
/// A collision between crate-id hashes on the other hand is harder to fix
/// because it depends on the set of crates in the entire crate graph of a
/// compilation session. Again, using the same crate with a different version
/// number would fix the issue with a high probability -- but that might be
/// easier said then done if the crates in questions are dependencies of
/// third-party crates.
///
/// That being said, given a high quality hash function, the collision
/// probabilities in question are very small. For example, for a big crate like
/// `rustc_middle` (with ~50000 `LocalDefId`s as of the time of writing) there
/// is a probability of roughly 1 in 14,750,000,000 of a crate-internal
/// collision occurring. For a big crate graph with 1000 crates in it, there is
/// a probability of 1 in 36,890,000,000,000 of a `StableCrateId` collision.
```
Given the probabilities involved I hope that no one will ever actually see the error messages. Nonetheless, I'd be glad about some feedback on how to improve them. Should we create a GH issue describing the problem and possible solutions to point to? Or a page in the rustc book?
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
bors [Sun, 7 Mar 2021 20:23:23 +0000 (20:23 +0000)]
Auto merge of #82285 - nhwn:nonzero-debug, r=nagisa
Use u32 over Option<u32> in DebugLoc
~~Changes `Option<u32>` fields in `DebugLoc` to `Option<NonZeroU32>`. Since the respective fields (`line` and `col`) are guaranteed to be 1-based, this layout optimization is a freebie.~~
EDIT: Changes `Option<u32>` fields in `DebugLoc` to `u32`. As `@bugadani` pointed out, an `Option<NonZeroU32>` is probably an unnecessary layer of abstraction since the `None` variant is always used as `UNKNOWN_LINE_NUMBER` (which is just `0`). Also, `SourceInfo` in `metadata.rs` already uses a `u32` instead of an `Option<u32>` to encode the same information, so I think this change is warranted.
Since `@jyn514` raised some concerns over measuring performance in a similar PR (#82255), does this need a perf run?