bors [Tue, 13 Oct 2020 12:11:47 +0000 (12:11 +0000)]
Auto merge of #77762 - pietroalbini:dist-build-manifest, r=Mark-Simulacrum
Dist build manifest
This PR makes two changes that should remove a significant chunk of the time spent in our release process: cloning the `rust-lang/rust` monorepo, all its submodules, and building `bootstrap` to then invoke `build-manifest`:
* `build-manifest` doesn't rely on a clone of the monorepo being present anymore. The only remaining bit of information it fetched from it (the Rust version) is instead bundled in the binary.
* A new "component" is added, `build-manifest`. That component includes a prebuilt version of the tool, and it's *not* included in the Rustup manifest. This will allow `promote-release` to directly invoke the tool without interacting with our build system.
* The Linux x86_64 CI is changed to also build the component mentioned above. It's the only CI builder tasked to do so, and to cleanly support this a new `--include-default-paths` flag was added to `./x.py`.
* The `BUILD_MANIFEST_NUM_THREADS` environment variable is added to configure the number of threads at runtime.
This PR is best reviewed commit-by-commit.
r? `@Mark-Simulacrum`
bors [Tue, 13 Oct 2020 08:27:01 +0000 (08:27 +0000)]
Auto merge of #77759 - tblah:fix_riscv_qemu, r=pietroalbini
ci: Fix riscv64gc linux test QEMU fault, plus doc link fix
Newer versions of the `qemu` package (used for riscv64gc-unknown-linux-gnu testing) don't work with the version of the RISC-V bootloader we were using. https://github.com/rust-lang/rust/commit/a4a0342cf59a1bff43ed79586065eb97dba0cddb bumps to a revision which should fix the problem.
bors [Tue, 13 Oct 2020 04:41:08 +0000 (04:41 +0000)]
Auto merge of #76196 - r-52:r-coverage-allow-missing-docs, r=jyn514
rustdoc: skip #[allow(missing docs)] for docs in coverage report
During the document coverage reporting with:
```bash
rustdoc something.rs -Z unstable-options --show-coverage
```
the coverage report counts code that is marked with `#[allow(missing_docs)]` for the calculation, which outputs lower numbers in the coverage report even though these parts should be ignored for the calculation.
Right now I'm not sure how this can be tested (CI)? (I verified it by hand and ran the unit tests)
bors [Mon, 12 Oct 2020 19:09:08 +0000 (19:09 +0000)]
Auto merge of #77867 - JohnTitor:rollup-0odg1n4, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #77550 (add shims for WithOptConstParam query calls)
- #77699 (Add word wrap for short descriptions)
- #77724 (Implement `AsRawFd` for `StdinLock` etc. on WASI.)
- #77746 (Fix `x.py setup` sets `changelog-seen`)
- #77784 (Fix intra-docs link in core::ffi::VaList)
- #77811 (rustdoc: Make some functions private that don't need to be public)
- #77818 (Mono collector: replace pair of ints with Range)
- #77831 (Use std methods on char instead of open coding them)
- #77852 (update url in bootstrap README (gcc-rs -> cc-rs))
- #77863 (Remove `mark-i-m` from rustc-dev-guide maintainers)
Yuki Okushi [Mon, 12 Oct 2020 19:08:02 +0000 (04:08 +0900)]
Rollup merge of #77818 - bugadani:range, r=oli-obk
Mono collector: replace pair of ints with Range
I found the initial PR (#33171) that introduced this piece of code but I didn't find any information about why a tuple was preferred over a `Range<usize>`.
I'm hoping there are no technical reasons to not do this.
Yuki Okushi [Mon, 12 Oct 2020 19:07:58 +0000 (04:07 +0900)]
Rollup merge of #77784 - aDotInTheVoid:ffi-sealed_trait-intra-docs, r=jyn514
Fix intra-docs link in core::ffi::VaList
At some point, `VaList` was changes to be a [wrapper](https://github.com/rust-lang/rust/blob/1661f77/library/core/src/ffi.rs#L177-L201) over `VaListImpl`, and now the `Arg` method exists on [`VaListImpl`](https://github.com/rust-lang/rust/blob/1661f77/library/core/src/ffi.rs#L333-L336). This PR fixes the intradoc links so that when `--document-private-items` is ran on std (via [patch](https://gist.github.com/aDotInTheVoid/42c82306210203f9c9093c952b765ab4)), it works
Pietro Albini [Fri, 9 Oct 2020 13:34:57 +0000 (15:34 +0200)]
build-manifest: accept the Rust version instead of the monorepo path
This commit changes the way build-manifest is invoked, to let it accept
the Rust version directly instead of requiring the path of the Rust
monorepo and letting build-manifest figure out the path on its own.
This allows to run build-manifest without a clone of the monorepo.
bors [Mon, 12 Oct 2020 12:12:54 +0000 (12:12 +0000)]
Auto merge of #77821 - tmiasko:discriminant-value-is-safe, r=jonas-schievink
Remove unnecessary unsafe block around calls to discriminant_value
Since 63793 the discriminant_value intrinsic is safe to call. Remove
unnecessary unsafe block around calls to this intrinsic in built-in
derive macros.
Roman [Tue, 1 Sep 2020 12:19:24 +0000 (14:19 +0200)]
rustdoc: skip allow missing doc in cover. report
During the document coverage reporting with
```bash
rustdoc something.rs -Z unstable-options --show-coverage
```
the coverage report also includes parts of the code that are marked
with `#[allow(missing_docs)]`, which outputs lower numbers in the
coverage report even though these parts should be ignored for the
calculation.
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
James Gill [Wed, 7 Oct 2020 01:54:05 +0000 (21:54 -0400)]
Stabilize slice_select_nth_unstable
This stabilizes the functionality in slice_partition_at_index,
but under the names `select_nth_unstable*`. The functions
`partition_at_index*` are left as deprecated, to be removed in
a later release.
bors [Sun, 11 Oct 2020 20:50:02 +0000 (20:50 +0000)]
Auto merge of #76859 - Aaron1011:fix/llvm-cgu-reuse, r=davidtwco,nikic
Use llvm::computeLTOCacheKey to determine post-ThinLTO CGU reuse
During incremental ThinLTO compilation, we attempt to re-use the
optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do
so.
Up until now, 'safe' has meant that the set of modules that our current
modules imports from/exports to is unchanged from the previous
compilation session. See PR #67020 and PR #71131 for more details.
However, this turns out be insufficient to guarantee that it's safe
to reuse the post-LTO module (i.e. that optimizing the pre-LTO module
would produce the same result). When LLVM optimizes a module during
ThinLTO, it may look at other information from the 'module index', such
as whether a (non-imported!) global variable is used. If this
information changes between compilation runs, we may end up re-using an
optimized module that (for example) had dead-code elimination run on a
function that is now used by another module.
Fortunately, LLVM implements its own ThinLTO module cache, which is used
when ThinLTO is performed by a linker plugin (e.g. when clang is used to
compile a C proect). Using this cache directly would require extensive
refactoring of our code - but fortunately for us, LLVM provides a
function that does exactly what we need.
The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash
from all data that might influence the result of ThinLTO on a module.
In addition to the module imports/exports that we manually track, it
also hashes information about global variables (e.g. their liveness)
which might be used during optimization. By using this function, we
shouldn't have to worry about new LLVM passes breaking our module re-use
behavior.
In LLVM, the output of this function forms part of the filename used to
store the post-ThinLTO module. To keep our current filename structure
intact, this PR just writes out the mapping 'CGU name -> Hash' to a
file. To determine if a post-LTO module should be reused, we compare
hashes from the previous session.
This should unblock PR #75199 - by sheer chance, it seems to have hit
this issue due to the particular CGU partitioning and optimization
decisions that end up getting made.
bors [Sun, 11 Oct 2020 16:33:47 +0000 (16:33 +0000)]
Auto merge of #77793 - tmiasko:no-op-discriminant, r=ecstatic-morse
Recognize discriminant reads as no-ops in RemoveNoopLandingPads
The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.
Aaron Hill [Sat, 26 Sep 2020 16:51:00 +0000 (12:51 -0400)]
Allow skipping extra paren insertion during AST pretty-printing
Fixes #74616
Makes progress towards #43081
Unblocks PR #76130
When pretty-printing an AST node, we may insert additional parenthesis
to ensure that precedence is properly preserved in code we output.
However, the proc macro implementation relies on comparing a
pretty-printed AST node to the captured `TokenStream`. Inserting extra
parenthesis changes the structure of the reparsed `TokenStream`, making
the comparison fail.
This PR refactors the AST pretty-printing code to allow skipping the
insertion of additional parenthesis. Several freestanding methods are
moved to trait methods on `PrintState`, which keep track of an internal
`insert_extra_parens` flag. This flag is normally `true`, but we expose
a public method which allows pretty-printing a nonterminal with
`insert_extra_parens = false`.
To avoid changing the public interface of `rustc_ast_pretty`, the
freestanding `_to_string` methods are changed to delegate to a
newly-crated `State`. The main pretty-printing code is moved to a new
`state` module to ensure that it does not accidentally call any of these
public helper functions (instead, the internal functions with the same
name should be used).
bors [Sun, 11 Oct 2020 14:06:04 +0000 (14:06 +0000)]
Auto merge of #77727 - thomcc:mach-info-order, r=Amanieu
Avoid SeqCst or static mut in mach_timebase_info and QueryPerformanceFrequency caches
This patch went through a couple iterations but the end result is replacing a pattern where an `AtomicUsize` (updated with many SeqCst ops) guards a `static mut` with a single `AtomicU64` that is known to use 0 as a value indicating that it is not initialized.
The code in both places exists to cache values used in the conversion of Instants to Durations on macOS, iOS, and Windows.
I have no numbers to prove that this improves performance (It seems a little futile to benchmark something like this), but it's much simpler, safer, and in practice we'd expect it to be faster everywhere where Relaxed operations on AtomicU64 are cheaper than SeqCst operations on AtomicUsize, which is a lot of places.
Anyway, it also removes a bunch of unsafe code and greatly simplifies the logic, so IMO that alone would be worth it unless it was a regression.
If you want to take a look at the assembly output though, see https://godbolt.org/z/rbr6vn for x86_64, https://godbolt.org/z/cqcbqv for aarch64 (Note that this just the output of the mac side, but i'd expect the windows part to be the same and don't feel like doing another godbolt for it). There are several versions of this function in the godbolt:
- `info_new`: version in the current patch
- `info_less_new`: version in initial PR
- `info_original`: version currently in the tree
- `info_orig_but_better_orderings`: a version that just tries to change the original code's orderings from SeqCst to the (probably) minimal orderings required for soundness/correctness.
The biggest concern I have here is if we can use AtomicU64, or if there are targets that dont have it that this code supports. AFAICT: no. (If that changes in the future, it's easy enough to do something different for them)
r? `@Amanieu` because he caught a couple issues last time I tried to do a patch reducing orderings 😅
---
<details>
<summary>I rewrote this whole message so the original is inside here</summary>
I happened to notice the code we use for caching the result of mach_timebase_info uses SeqCst exclusively.
However, thinking a little more, it's actually pretty easy to avoid the static mut by packing the timebase info into an AtomicU64.
This entirely avoids needing to do the compare_exchange. The AtomicU64 can be read/written using Relaxed ops, which on current macos/ios platforms (x86_64/aarch64) have no overhead compared to direct loads/stores. This simplifies the code and makes it a lot safer too.
I have no numbers to prove that this improves performance (It seems a little futile to benchmark something like this), although it should do that on both targets it applies to.
That said, it also removes a bunch of unsafe code and simplifies the logic (arguably at least — there are only two states now, initialized or not), so I think it's a net win even without concrete numbers.
If you want to take a look at the assembly output though, see below. It has the new version, the original, and a version of the original with lower Orderings (which is still worse than the version in this PR)
- godbolt.org/z/obfqf9 x86_64-apple-darwin
- godbolt.org/z/Wz5cWc aarch64-unknown-linux-gnu (godbolt can't do aarch64-apple-ios but that doesn't matter here)
A different (and more efficient) option than this would be to just use the AtomicU64 and use the knowledge that after initialization the denominator should be nonzero... That felt like it's relying on too many things I'm not confident in, so I didn't want to do that.
</details>
bors [Sun, 11 Oct 2020 09:50:19 +0000 (09:50 +0000)]
Auto merge of #77743 - bugadani:idl-cleanup, r=bugadani
Clean up in intra-doc link collector
This PR makes the following changes in intra-doc links:
- clean up hard to follow closure-based logic in `check_full_res`
- fix a FIXME comment by figuring out that `true` and `false` need to be resolved separately
- refactor path resolution by extracting common code to a helper method and trying to reduce the number of unnecessary early returns
- primitive types are now defined by their symbols, not their name strings
- re-enables a commented-out test case
bors [Sun, 11 Oct 2020 07:55:20 +0000 (07:55 +0000)]
Auto merge of #77769 - camelid:regression-untriaged, r=jyn514
Auto-prioritize issues with `regression-untriaged`
This auto-prioritizes issues with the `regression-untriaged` label. (I just added it per <https://github.com/rust-lang/rust/pull/77725#discussion_r502135703>.)
Aman Arora [Fri, 2 Oct 2020 01:06:16 +0000 (21:06 -0400)]
Always return tupled_upvar_tys for Closure/Generator consituent tys
Depending on if upvar_tys inferred or not, we were returning either an
inference variable which later resolves to a tuple or else the upvar tys
themselves