bors [Mon, 5 Oct 2020 09:26:32 +0000 (09:26 +0000)]
Auto merge of #77552 - ecstatic-morse:body-def-id, r=lcnr
Replace `(Body, DefId)` with `Body` where possible
Follow-up to #77430.
I `grep`-ed for parameter lists in which a `Body` appeared within a few lines of a `DefId`, so it's possible that I missed some cases, but this should be pretty complete. Most of these changes were mechanical, but there's a few places where I started calling things "caller" and "callee" when multiple `DefId`s were in-scope at once. Also, we should probably have a helper function on `Body` that returns a `LocalDefId`. I can do that in this PR or in a follow-up.
bors [Mon, 5 Oct 2020 02:49:51 +0000 (02:49 +0000)]
Auto merge of #77557 - Dylan-DPC:rollup-aib9ptp, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #75853 (Use more intra-doc-links in `core::fmt`)
- #75928 (Remove trait_selection error message in specific case)
- #76329 (Add check for doc alias attribute at crate level)
- #77219 (core::global_allocator docs link to std::alloc::GlobalAlloc)
- #77395 (BTreeMap: admit the existence of leaf edges in comments)
- #77407 (Improve build-manifest to work with the improved promote-release)
- #77426 (Include scope id in SocketAddrV6::Display)
- #77439 (Fix missing diagnostic span for `impl Trait` with const generics, and add various tests for `min_const_generics` and `const_generics`)
- #77471 (BTreeMap: refactoring around edges, missed spots)
- #77512 (Allow `Abort` terminators in all const-contexts)
- #77514 (Replace some once(x).chain(once(y)) with [x, y] IntoIter)
bors [Mon, 5 Oct 2020 00:35:58 +0000 (00:35 +0000)]
Auto merge of #77466 - Aaron1011:reland-drop-tree, r=matthewjasper
Re-land PR #71840 (Rework MIR drop tree lowering)
PR https://github.com/rust-lang/rust/pull/71840 was reverted in https://github.com/rust-lang/rust/pull/72989 to fix an LLVM error (https://github.com/rust-lang/rust/issues/72470). That LLVM error no longer occurs with the recent upgrade to LLVM 11 (https://github.com/rust-lang/rust/pull/73526), so let's try re-landing this PR.
I've cherry-picked the commits from the original PR (with the exception of the commit blessing test output), making as few modifications as possible. I addressed the rebase fallout in separate commits on top of those.
Dylan DPC [Mon, 5 Oct 2020 00:29:42 +0000 (02:29 +0200)]
Rollup merge of #77514 - scottmcm:less-once-chain-once, r=estebank
Replace some once(x).chain(once(y)) with [x, y] IntoIter
Now that we have by-value array iterators that are [already used](https://github.com/rust-lang/rust/blob/25c8c53dd994acb3f4f7c02fe6bb46076393f8b0/compiler/rustc_hir/src/def.rs#L305-L307)...
For example,
```diff
- once(self.type_ns).chain(once(self.value_ns)).chain(once(self.macro_ns)).filter_map(|it| it)
+ IntoIter::new([self.type_ns, self.value_ns, self.macro_ns]).filter_map(|it| it)
```
Dylan DPC [Mon, 5 Oct 2020 00:29:40 +0000 (02:29 +0200)]
Rollup merge of #77512 - ecstatic-morse:const-checking-allow-abort, r=RalfJung
Allow `Abort` terminators in all const-contexts
We never unwind during const-eval, so we basically have these semantics already. Also I just figured out that these only appear along the cleanup path, which doesn't get const-checked. In other words, this doesn't actually change behavior: the `check-pass` test I added compiles just fine on nightly.
(I only added separate `min_const_generics` and `const_generics` tests if they were handled differently by the two features.)
We need to figure out how to deduplicate when `const_generics` is stabilised, but we can discuss that later. For now, we should be checking neither feature breaks, so require regression tests for both. I've given them identical names when I've added both, which should make it easier to spot them later.
Dylan DPC [Mon, 5 Oct 2020 00:29:33 +0000 (02:29 +0200)]
Rollup merge of #77407 - pietroalbini:less-build-manifest, r=Mark-Simulacrum
Improve build-manifest to work with the improved promote-release
This PR makes some changes to build-manifest to have it work better with the other improvements I'm making to [promote-release](https://github.com/rust-lang/promote-release).
A new way to invoke the tool was added: `./x.py run src/tools/build-manifest`. The new invocation disables the generation of `.sha256` files and the generation of GPG signatures, as those steps are not tied to the Rust version we're building the manifest of: handling them in `promote-release` will improve the maintenability of our release process. Invocations through the old command (`./x.py dist hash-and-sign`) are referred inside the source code as "legacy". The new invocation also enables internal parallelism, disabled on legacy to avoid overloading our old server.
Improvements were also made on how the checksums included in the manifest are generated:
* The manifest is first generated with placeholder checksums, and then a function walks through the manifes and calculates only the needed hashes. Before this PR, all the hashes were calculated beforehand, including the hashes of unused files.
* Calculating the hashes is now done in parallel with rayon, to better utilize all the available disk bandwidth.
* The `sha2` crate is now used instead of the `sha256sum` CLI tool: this avoids the overhead of calling another process, but more importantly enables hardware acceleration whenever available (the `sha256sum` CLI tool doesn't support it at all).
r? @Mark-Simulacrum
This PR is best reviewed commit-by-commit.
Dylan DPC [Mon, 5 Oct 2020 00:29:31 +0000 (02:29 +0200)]
Rollup merge of #77395 - ssomers:btree_love_the_leaf_edge_comments, r=Mark-Simulacrum
BTreeMap: admit the existence of leaf edges in comments
The btree code is ambiguous about leaf edges (i.e., edges within leaf nodes). Iteration relies on them heavily, but some of the comments suggest there are no leaf edges (extracted from #77025)
bors [Sun, 4 Oct 2020 21:08:06 +0000 (21:08 +0000)]
Auto merge of #77023 - HeroicKatora:len-missed-optimization, r=Mark-Simulacrum
Hint the maximum length permitted by invariant of slices
One of the safety invariants of references, and in particular of references to slices, is that they may not cover more than `isize::MAX` bytes. The unsafe `from_raw_parts` constructors of slices explicitly requires the caller to guarantee this fact. Violating it would also be UB with regards to the semantics of generated llvm code.
This effectively bounds the length of a (non-ZST) slice from above by a compile time constant. But when the length is loaded from a function argument it appears llvm is not aware of this requirement. The additional value range assertions allow some further elision of code branches, including overflow checks, especially in the presence of artithmetic on the indices.
This may have a performance impact, adding more code to a common method but allowing more optimization. I'm not quite sure, is the Rust side of const-prop strong enough to elide the irrelevant match branches?
Andreas Molzer [Sun, 20 Sep 2020 15:22:17 +0000 (17:22 +0200)]
Assume slice len is bounded by allocation size
Uses assume to check the length against a constant upper bound. The
inlined result then informs the optimizer of the sound value range.
This was tried with unreachable_unchecked before which introduces a
branch. This has the advantage of not being executed in sound code but
complicates basic blocks. It resulted in ~2% increased compile time in
some worst cases.
Add a codegen test for the assumption, testing the issue from #67186
Dylan MacKenzie [Fri, 2 Oct 2020 01:47:36 +0000 (18:47 -0700)]
HACK: Overwrite the MIR's source with the correct const param
There's a cleaner way of doing this, but it involves passing
`WithOptConstParam` around in more places. We're going to try to explore
different approaches before committing to that.
bors [Sun, 4 Oct 2020 13:49:36 +0000 (13:49 +0000)]
Auto merge of #77527 - jonas-schievink:rollup-szgq5he, r=jonas-schievink
Rollup of 8 pull requests
Successful merges:
- #77072 (Minor `hash_map` doc adjustments + item attribute orderings)
- #77368 (Backport LLVM apfloat commit to rustc_apfloat)
- #77445 (BTreeMap: complete the compile-time test_variance test case)
- #77504 (Support vectors with fewer than 8 elements for simd_select_bitmask)
- #77513 (Change DocFragments from enum variant fields to structs with a nested enum)
- #77518 (Only use Fira Sans for the first `td` in item lists)
- #77521 (Move target feature whitelist from cg_llvm to cg_ssa)
- #77525 (Enable RenameReturnPlace MIR optimization on mir-opt-level >= 2)
Jonas Schievink [Sun, 4 Oct 2020 13:45:50 +0000 (15:45 +0200)]
Rollup merge of #77525 - tmiasko:nrvo-2, r=jonas-schievink
Enable RenameReturnPlace MIR optimization on mir-opt-level >= 2
The destination propagation as currently implemented does not supersede the NRVO, e.g., the destination propagation never applies if either local has an address taken, while NRVO might.
Additionally, the issue with failing assertions had been already resolved.
Continue running both optimizations at mir-opt-level >= 2.
Jonas Schievink [Sun, 4 Oct 2020 13:45:48 +0000 (15:45 +0200)]
Rollup merge of #77521 - bjorn3:target_feature_whitelist, r=lcnr
Move target feature whitelist from cg_llvm to cg_ssa
These target features have to be supported or at least emulated by alternative codegen backends anyway as they are used by common crates. By moving this list to cg_ssa, other codegen backends don't have to copy
this code.
Jonas Schievink [Sun, 4 Oct 2020 13:45:41 +0000 (15:45 +0200)]
Rollup merge of #77445 - ssomers:btree_cleanup_7, r=Mark-Simulacrum
BTreeMap: complete the compile-time test_variance test case
Some of the items added to the new `test_sync` belonged in the old `test_variance` as well. And fixed inconsistent paths to nearby modules.
r? @Mark-Simulacrum
Jonas Schievink [Sun, 4 Oct 2020 13:45:33 +0000 (15:45 +0200)]
Rollup merge of #77072 - sharnoff:hash-docs, r=LukasKalbertodt
Minor `hash_map` doc adjustments + item attribute orderings
This PR is really a couple visual changes glued together:
1. Some of the doc comments for items in `std::collections::hash_map` referenced the names of types without escaping their formatting (e.g. using "VacantEntry" instead of "`VacantEntry`") - the ones I could find were changed to the latter
2. The vast majority of pre-item attributes seem to place doc comments as the first attribute (instead of things like `#[feature(...)]`), so the few that had the other order were changed.
3. Also ordering related: the general trend seems to be that `#[feature]` attributes follow `#[inline]`, so I swapped the two lines in places where that ordering was reversed. This is primarily a change based on stylistic continuity and aesthetics - I'm not sure how important that actually is / should be.
I figured this would be pretty uncontroversial, but some of these might have been intentional for reasons I don't know about - if so, I'd be happy to remove the relevant changes. Of these, the final set of changes is probably the most unnecessary, so it also might be better to leave those out (in favor of reducing code churn).
Aaron Hill [Fri, 2 Oct 2020 20:30:36 +0000 (16:30 -0400)]
Add regression test for issue #72470
This was fixed with the upgrade to LLVM 11 in #73526.
It seems extremely unlikey that this exact issue will ever reoccur,
since slight modifications to the code caused the crash to stop
happening. However, it can't hurt to have a test for it.
bors [Sun, 4 Oct 2020 11:48:50 +0000 (11:48 +0000)]
Auto merge of #76610 - hch12907:master, r=LukasKalbertodt
Implement as_ne_bytes() for integers and floats
This is related to issue #64464.
I am pretty sure that these functions are actually const-ify-able, and technically as_bits() can also be implemented for floats, but I might need some comments on both.
bjorn3 [Sun, 4 Oct 2020 09:12:56 +0000 (11:12 +0200)]
Move target feature whitelist from cg_llvm to cg_ssa
These target features have to be supported or at least emulated by
alternative codegen backends anyway as they are used by common crates.
By moving this list to cg_ssa, other codegen backends don't have to copy
this code.
Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.
bors [Sun, 4 Oct 2020 06:48:17 +0000 (06:48 +0000)]
Auto merge of #77380 - fusion-engineering-forks:unbox-the-mutex, r=dtolnay
Unbox mutexes and condvars on some platforms
Both mutexes and condition variables contained a Box containing the actual os-specific object. This was done because moving these objects may cause undefined behaviour on some platforms.
However, this is not needed on Windows[1], Wasm[2], cloudabi[2], and 'unsupported'[3], were the box was only needlessly making them less efficient.
This change gets rid of the box on those platforms.
On those platforms, `Condvar` can no longer verify it is only used with one `Mutex`, as mutexes no longer have a stable address. This was addressed and considered acceptable in #76932.
[1]\: https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializesrwlock
[2]\: These are just a single atomic integer together with futex wait/wake calls/instructions.
[3]\: The `unsupported` platform doesn't support multiple threads at all.
Yuki Okushi [Sun, 4 Oct 2020 02:44:49 +0000 (11:44 +0900)]
Rollup merge of #75143 - oli-obk:tracing, r=RalfJung
Use `tracing` spans to trace the entire MIR interp stack
r? @RalfJung
While being very verbose, this allows really good tracking of what's going on. While I considered schemes like the previous indenter that we had (which we could get by using the `tracing-tree` crate), this will break down horribly with things like multithreaded rustc. Instead, we can now use `RUSTC_LOG` to restrict the things being traced. You could specify a filter in a way that only shows the logging of a specific frame.
If we lower the span's level to `debug`, then in `info` level logging we'd not see the frames, but in `debug` level we would see them. The filtering rules in `tracing` are super powerful, but I'm not sure if we can specify a filter so we do see `debug` level events, but *not* the `frame` spans. The documentation at https://docs.rs/tracing-subscriber/0.2.10/tracing_subscriber/struct.EnvFilter.html makes me think that we can only turn on things, not turn off things at a more precise level.
bors [Sun, 4 Oct 2020 02:24:20 +0000 (02:24 +0000)]
Auto merge of #76017 - JulianKnodt:fmt_fast, r=nagisa
Use less divisions in display u128/i128
This PR is an absolute mess, and I need to test if it improves the speed of fmt::Display for u128/i128, but I think it's correct.
It hopefully is more efficient by cutting u128 into at most 2 u64s, and also chunks by 1e16 instead of just 1e4.
Also I specialized the implementations for uints to always be non-false because it bothered me that it was checked at all
Do not merge until I benchmark it and also clean up the god awful mess of spaghetti.
Based on prior work in #44583
cc: `@Dylan-DPC`
Due to work on `itoa` and suggestion in original issue:
r? `@dtolnay`
Tomasz Miąsko [Sun, 4 Oct 2020 00:00:00 +0000 (00:00 +0000)]
Enable RenameReturnPlace MIR optimization on mir-opt-level >= 2
The destination propagation as currently implemented does not supersede
the NRVO, e.g., the destination propagation never applies if either
local has an address taken, while NRVO might.
Additionally, the issue with failing assertions had been already
resolved.
Continue running both optimizations at mir-opt-level >= 2.
bors [Sat, 3 Oct 2020 22:13:01 +0000 (22:13 +0000)]
Auto merge of #77434 - jonas-schievink:ret-in-reg-2-electric-boogalo, r=nagisa
Returns values up to 2*usize by value
Addresses https://github.com/rust-lang/rust/pull/76986#discussion_r498306837 and https://github.com/rust-lang/rust/pull/76986#issuecomment-696415287 by doing the optimization on all targets.
This matches what we do for functions returning `&[T]` and other fat pointers, so it should be Harmless™
Dylan MacKenzie [Sat, 3 Oct 2020 21:38:01 +0000 (14:38 -0700)]
Allow `Abort` terminators in a const-context
These appear along the cleanup path inside functions with
`#[unwind(aborts)]`. We don't const-check the cleanup path anyways,
since const-eval already has "abort-on-panic" semantics and there's
often drops that would otherwise be forbidden, so the check wasn't
really preventing anything anyways.
bors [Sat, 3 Oct 2020 14:18:26 +0000 (14:18 +0000)]
Auto merge of #74160 - CAD97:weak-as-unsized-ptr, r=RalfJung
Allow Weak::as_ptr and friends for unsized T
Relaxes `impl<T> Weak<T>` to `impl<T: ?Sized> Weak<T>` for the methods `rc::Weak::as_ptr`, `into_raw`, and `from_raw`.
Follow-up to #73845, which did most of the impl work to make these functions work for `T: ?Sized`.
We still have to adjust the implementation of `Weak::from_raw` here, however, because I missed a use of `ptr.is_null()` previously. This check was necessary when `into`/`from_raw` were first implemented, as `into_raw` returned `ptr::null()` for dangling weak. However, we now just (wrapping) offset dangling weaks' pointers the same as nondangling weak, so the null check is no longer necessary (or even hit). (I can submit just 17a928f as a separate PR if desired.)
As a nice side effect, moves the `fn is_dangling` definition closer to `Weak::new`, which creates the dangling weak.
This technically stabilizes that "something like `align_of_val_raw`" is possible to do. However, I believe the part of the functionality required by these methods here -- specifically, getting the alignment of a pointee from a pointer where it may be dangling iff the pointee is `Sized` -- is uncontroversial enough to stabilize these methods without a way to implement them on stable Rust.
r? `@RalfJung,` who reviewed #73845.
ATTN: This changes (relaxes) the (input) generic bounds on stable fn!
projects / rust.git / log