bors [Tue, 4 May 2021 10:42:13 +0000 (10:42 +0000)]
Auto merge of #84017 - Smittyvb:int-literal-underscores, r=jyn514
Valid underscores in hex/octal/binary literal docs
Currently hex/octal/binary literals with computed values are displayed like `0_xff_fff_fffu32`, which is invalid since underscores can't be in the middle of integer prefixes. This properly formats prefixed integers.
This causes [`std::u32::MAX`](https://doc.rust-lang.org/std/u32/constant.MAX.html) to be displayed as
```rust
pub const MAX: u32 = u32::MAX; // 0_xff_fff_fffu32
```
This PR changes it to be displayed as:
```rust
pub const MAX: u32 = u32::MAX; // 0xffff_ffffu32
```
bors [Tue, 4 May 2021 05:40:24 +0000 (05:40 +0000)]
Auto merge of #84874 - joshtriplett:ci-extract-llvm-win64-installer, r=Mark-Simulacrum
CI: Extract LLVM win64 installer directly, using 7z
Currently, we have LLVM tarballs for win64, generated by someone running
the installer via wine and tarring up the result.
7z knows how to extract NSIS installers directly, and the result is
identical to our tarball, except that it doesn't include `Uninstall.exe`
(which we don't care about) and it includes the NSIS plugin directory
(which we also don't care about).
This simplifies the process of upgrading CI, and allows us to just
mirror the upstream release .exe directly. This also improves our
supply chain.
Valid underscores in hex/octal/binary literal docs
Currently hex/octal/binary literals with computed values are displayed
like `0_xff_fff_fffu32`, which is invalid since underscores can't be in
the middle of integer prefixes. This properly formats prefixed integers.
Josh Triplett [Mon, 3 May 2021 18:23:00 +0000 (11:23 -0700)]
CI: Extract LLVM win64 installer directly, using 7z
Currently, we have LLVM tarballs for win64, generated by someone running
the installer via wine and tarring up the result.
7z knows how to extract NSIS installers directly, and the result is
identical to our tarball, except that it doesn't include `Uninstall.exe`
(which we don't care about) and it includes the NSIS plugin directory
(which we also don't care about).
This simplifies the process of upgrading CI, and allows us to just
mirror the upstream release .exe directly. This also improves our
supply chain.
bors [Mon, 3 May 2021 14:35:12 +0000 (14:35 +0000)]
Auto merge of #84862 - GuillaumeGomez:rollup-cbc93h4, r=GuillaumeGomez
Rollup of 6 pull requests
Successful merges:
- #84835 (Add link to Issue #34202 in udp docs)
- #84852 (Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar)
- #84854 (use double quotes and full path for E0761)
- #84856 (Correct stability of ErrorKind::OutOfMemory)
- #84858 (Fix stability attributes of byte-to-string specialization)
- #84860 (Link to MCP from target tier policy)
Guillaume Gomez [Mon, 3 May 2021 13:08:07 +0000 (15:08 +0200)]
Rollup merge of #84852 - mautamu:master, r=GuillaumeGomez
Change librustdoc write!(.. \n) to writeln!(..); fix comment grammar
Howdy,
This PR does the following:
1. Updates the grammar of a comment in librustdoc.
2. Replaces a few write!(..\n) macros with writeln!(..\n) for clarity. (Please let me know if there is a reason why this might be wrong!)
bors [Mon, 3 May 2021 05:41:23 +0000 (05:41 +0000)]
Auto merge of #84842 - blkerby:null_lowercase, r=joshtriplett
Replace 'NULL' with 'null'
This replaces occurrences of "NULL" with "null" in docs, comments, and compiler error/lint messages. This is for the sake of consistency, as the lowercase "null" is already the dominant form in Rust. The all-caps NULL looks like the C macro (or SQL keyword), which seems out of place in a Rust context, given that NULL does not exist in the Rust language or standard library (instead having [`ptr::null()`](https://doc.rust-lang.org/stable/std/ptr/fn.null.html)).
bors [Mon, 3 May 2021 00:17:16 +0000 (00:17 +0000)]
Auto merge of #84840 - Dylan-DPC:rollup-uzk7w0h, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #84072 (Allow setting `target_family` to multiple values, and implement `target_family="wasm"`)
- #84744 (Add ErrorKind::OutOfMemory)
- #84784 (Add help message to suggest const for unused type param)
- #84811 (RustDoc: Fix bounds linking trait.Foo instead of traitalias.Foo)
- #84818 (suggestion for unit enum variant when matched with a patern)
- #84832 (Do not print visibility in external traits)
Dylan DPC [Sun, 2 May 2021 22:32:40 +0000 (00:32 +0200)]
Rollup merge of #84072 - nagisa:target-family-two-the-movie, r=petrochenkov
Allow setting `target_family` to multiple values, and implement `target_family="wasm"`
As per the conclusion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Are.20we.20comfortable.20with.20adding.20an.20insta-stable.20cfg.28wasm.29.3F/near/233158441), this implements an ability to specify any number of `target_family` values, allowing for more flexible generic groups, or "families", to be created than just the OS-based unix/windows dichotomy.
cc https://github.com/rust-lang/reference/pull/1006
As you can see, I had to move the "undocumented" items below, they're not mixed with the others anymore. Unfortunately, I don't see a way to keep the current appearance without JS. As a a reminder, currently it looks like this:
Dylan DPC [Sun, 2 May 2021 15:00:23 +0000 (17:00 +0200)]
Rollup merge of #84752 - lrh2000:generator-debuginfo, r=tmandry
Fix debuginfo for generators
First, all fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part, which gives an equivalent layout but offers us much better integration with debuggers.
Second, artificial flags in generator variants should be removed.
- Literally, variants are not artificial. We have `yield` statements, upvars and inner variables in the source code.
- Functionally, we don't want debuggers to suppress the variants. It contains the state of the generator, which is useful when debugging. So they shouldn't be marked artificial.
- Debuggers may use artificial flags to find the active variant. In this case, marking variants artificial will make debuggers not work properly.
Fixes #62572.
Fixes #79009.
And refer https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Debuginfo.20for.20generators.
bors [Sun, 2 May 2021 11:43:39 +0000 (11:43 +0000)]
Auto merge of #84802 - jyn514:option-dead-code, r=Mark-Simulacrum
Remove dead code in `rustc_session::Options`
- Don't recompile the same functions for each debugging option
This reduces the amount of items in the crate by quite a lot.
- Remove unused `parse_opt_list` and `parse_pathbuf_push` functions
- Remove unused macro parameters
- Remove `allow(dead_code)`.
bors [Sun, 2 May 2021 07:09:38 +0000 (07:09 +0000)]
Auto merge of #84750 - jyn514:nix-cargo, r=Mark-Simulacrum
Don't download cargo twice when download-rustc is set
Previously, this caused a bug on NixOS:
1. bootstrap.py would download and patch stage0/cargo
2. bootstrap.py would download nightly cargo, but extract it to
stage0/cargo instead of ci-rustc/cargo. It would still try (and fail) to patch ci-rustc/cargo.
3. bootstrap.py would fail to build rustbuild because stage0/cargo
wasn't patched.
The "proper" fix is to extract nightly cargo to ci-rustc instead, but it
doesn't seem to be necessary at all, so this just skips downloading it
instead.
bors [Sun, 2 May 2021 04:54:31 +0000 (04:54 +0000)]
Auto merge of #84725 - sebpop:arm64-isb, r=joshtriplett
[Arm64] use isb instruction instead of yield in spin loops
On arm64 we have seen on several databases that ISB (instruction synchronization
barrier) is better to use than yield in a spin loop. The yield instruction is a
nop. The isb instruction puts the processor to sleep for some short time. isb
is a good equivalent to the pause instruction on x86.
Below is an experiment that shows the effects of yield and isb on Arm64 and the
time of a pause instruction on x86 Intel processors. The micro-benchmarks use
https://github.com/google/benchmark.git
```
$ cat a.cc
static void BM_scalar_increment(benchmark::State& state) {
int i = 0;
for (auto _ : state)
benchmark::DoNotOptimize(i++);
}
BENCHMARK(BM_scalar_increment);
static void BM_yield(benchmark::State& state) {
for (auto _ : state)
asm volatile("yield"::);
}
BENCHMARK(BM_yield);
static void BM_isb(benchmark::State& state) {
for (auto _ : state)
asm volatile("isb"::);
}
BENCHMARK(BM_isb);
BENCHMARK_MAIN();
$ g++ -o run a.cc -O2 -lbenchmark -lpthread
$ ./run
--------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------
bors [Sat, 1 May 2021 23:16:12 +0000 (23:16 +0000)]
Auto merge of #84471 - jyn514:linkcheck-llvm, r=Mark-Simulacrum
Allow running `x.py test --stage 2 src/tools/linkchecker` with `download-rustc = true`
Previously, the LD_LIBRARY_PATH for the linkchecker looked like
`build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib`, because the linkchecker depends on the master copy of the standard library. This is true, but doesn't include the library path for the compiler libraries:
```
/home/joshua/src/rust/rust/build/x86_64-unknown-linux-gnu/stage1-tools-bin/error_index_generator: error while loading shared libraries: libLLVM-12-rust-1.53.0-nightly.so: cannot open shared object file: No such file or directory
```
That file is in
`build/x86_64-unknown-linux-gnu/stage1/lib/libLLVM-12-rust-1.53.0-nightly.so`,
which wasn't included in the dynamic path. This adds `build/x86_64-unknown-linux-gnu/stage1/lib` to the dynamic path for the linkchecker.
Aaron Hill [Sat, 1 May 2021 20:52:54 +0000 (16:52 -0400)]
Make `TypeFoldable::is_global()` false when fresh tys/consts are present
This ensures that `ParamEnv::and` preserves the original `caller_bounds`
when we have a value containing fresh tys/consts. This ensures that when
we cache a `SelectionCandidate`, the cache key (a `ParamEnvAnd`)
contains all of the information that influenced the computation of our
result (e.g. we may end up choosing a `ParamCandidate`)
bors [Sat, 1 May 2021 18:03:25 +0000 (18:03 +0000)]
Auto merge of #83114 - cjgillot:hop, r=eddyb
Move HIR parenting information out of hir_owner
Split out of #82681.
The parent of a HIR node and its content are currently bundled together, but are rarely used together.
This PR separates both information in two distinct queries for HIR owners.
This reduces incremental invalidation for HIR items that appear within a function body when this body (and the local ids) changes.
bors [Sat, 1 May 2021 09:59:54 +0000 (09:59 +0000)]
Auto merge of #84786 - JohnTitor:rollup-j5omx6f, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #84601 (rustdoc: Only store locations in Cache::extern_locations and calculate the other info on-demand)
- #84704 (platform-support.md: Update for consistency with Target Tier Policy)
- #84724 (Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_None)
- #84740 (Reset the docs' copy path button after 1 second)
- #84749 (Sync `rustc_codegen_cranelift`)
- #84756 (Add a ToC to the Target Tier Policy documentation)
- #84765 (Update cargo)
- #84774 (Fix misspelling)
Yuki Okushi [Sat, 1 May 2021 09:32:35 +0000 (18:32 +0900)]
Rollup merge of #84749 - XAMPPRocky:cranelift-rebase, r=bjorn3
Sync `rustc_codegen_cranelift`
Retrying #84746
r? ``@bjorn3``
---
Edit(bjorn3): Since the last sync there have been some refactorings around the driver code in preparation for a planned new feature. In addition ``@mominul`` implemented `-Ctarget-cpu` support and ``@XAMPPRocky`` fixed compilation of cg_clif itself for Windows with the MSVC toolchain.
Yuki Okushi [Sat, 1 May 2021 09:32:35 +0000 (18:32 +0900)]
Rollup merge of #84740 - r00ster91:patch-6, r=GuillaumeGomez
Reset the docs' copy path button after 1 second
I like that this copy path button on the top next to the type/module's name changes to a check mark when you successfully clicked and copied the path but I find it really weird how the icon stays that check mark forever after the first time of clicking it. Imagine you leave that documentation tab open and come back after 2 hours and you still see that check mark in that box because you copied the path 2 hours ago. You will probably be confused and you might've forgotten what that button even does (even more so currently where this is a new feature, or when you simply don't use it often), so I really think at some point it should go back to the ⎘ icon which, at least to me, pretty clearly indicates copying, whereas the check mark (if it stays there for so long) could falsely look like a verification mark indicating "this module is verified" or something like that.
I believe after a longer period of time it's not logical to still tell the user "yes you've copied this successful".
In addition to this timeout, maybe it could be made so that you can't copy again until this cooldown of 1 second is over, but I'm not sure how useful or user-friendly that feature would be so maybe it's fine the way it is now.
Also the timeout is cleared every time you click again so if you constantly click it, it won't reset during that.
Yuki Okushi [Sat, 1 May 2021 09:32:34 +0000 (18:32 +0900)]
Rollup merge of #84724 - MaskRay:sys-fs, r=petrochenkov
Replace llvm::sys::fs::F_None with llvm::sys::fs::OF_None
The former is deprecated.
OF_None has been available in LLVM since 2018-06.
-----
OF_None (https://reviews.llvm.org/rG1f67a3cba9b09636c56e2109d8a35ae96dc15782) exists in LLVM 9.
https://reviews.llvm.org/D101506 may drop `F_None` support.
Yuki Okushi [Sat, 1 May 2021 09:32:33 +0000 (18:32 +0900)]
Rollup merge of #84704 - joshtriplett:platform-support-target-tier-policy, r=pietroalbini
platform-support.md: Update for consistency with Target Tier Policy
Split into five sections to match the tiers: "Tier 1 with Host Tools",
"Tier 1", "Tier 2 with Host Tools", "Tier 2", and "Tier 3". Explain each
tier briefly in prose, and link to the corresponding section of the
policy for full requirements.
Drop the `host` columns from the first four, since the different
sections distinguish that. (Keep the `host` column for "Tier 3", since
it's a single list and the `host` column just indicates if host tools
are expected to work.)
Targets with host tools always have full support for std, so drop the
`std` column from those.
Move the explanations of the `std` column next to the appropriate
tables, and drop the unknown/WIP case for tier 2 targets.
bors [Sat, 1 May 2021 07:48:24 +0000 (07:48 +0000)]
Auto merge of #84582 - richkadel:issue-84561, r=tmandry
Vastly improves coverage spans for macros
Fixes: #84561
This resolves problems where macros like `trace!(...)` would show zero coverage if tracing was disabled, and `assert_eq!(...)` would show zero coverage if the assertion did not fail, because only one coverage span was generated, for the branch.
This PR started with an idea that I could just drop branching blocks with same span as expanded macro. (See the fixed issue for more details.)
That did help, but it didn't resolve everything.
I also needed to add a span specifically for the macro name (plus `!`) to ensure the macro gets coverage even if it's internal expansion adds conditional branching blocks that are retained, and would otherwise drop the outer span. Now that outer span is _only_ the `(argument, list)`, which can safely be dropped now), because the macro name has its own span.
While testing, I also noticed the spanview debug output can cause an ICE on a function with no body. The
workaround for this is included in this PR (separate commit).