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).
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.
![screenshot of command line output of the new formatting](https://user-images.githubusercontent.com/332036/89291343-aa40de00-d65a-11ea-9f6c-ea06c1806327.png)
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™
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!
Mark Rousskov [Fri, 2 Oct 2020 23:51:36 +0000 (19:51 -0400)]
Place all-targets checking behind a flag
This matches Cargo behavior and avoids the (somewhat expensive) double checking,
as well as the unfortunate duplicate error messages (#76822,
rust-lang/cargo#5128).
bors [Sat, 3 Oct 2020 07:23:02 +0000 (07:23 +0000)]
Auto merge of #77347 - jyn514:dox, r=Amanieu
Remove --cfg dox from rustdoc.rs
This was added in https://github.com/rust-lang/rust/pull/53076 because
several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`).
I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think
this is now safe to remove.
bors [Fri, 2 Oct 2020 22:47:35 +0000 (22:47 +0000)]
Auto merge of #77470 - jonas-schievink:rollup-9a2hulp, r=jonas-schievink
Rollup of 8 pull requests
Successful merges:
- #75377 (Fix Debug implementations of some of the HashMap and BTreeMap iterator types)
- #76107 (Write manifest for MAJOR.MINOR channel to enable rustup convenience)
- #76745 (Move Wrapping<T> ui tests into library)
- #77182 (Add missing examples for Fd traits)
- #77251 (Bypass const_item_mutation if const's type has Drop impl)
- #77264 (Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used. )
- #77421 (Revert "resolve: Avoid "self-confirming" import resolutions in one more case")
- #77452 (Permit ty::Bool in const generics for v0 mangling)
Jonas Schievink [Fri, 2 Oct 2020 22:31:14 +0000 (00:31 +0200)]
Rollup merge of #77264 - fusion-engineering-forks:skip-local-stdio, r=dtolnay
Only use LOCAL_{STDOUT,STDERR} when set_{print/panic} is used.
The thread local `LOCAL_STDOUT` and `LOCAL_STDERR` are only used by the `test` crate to capture output from tests when running them in the same process in differen threads. However, every program will check these variables on every print, even outside of testing.
This involves allocating a thread local key, and registering a thread local destructor. This can be somewhat expensive.
This change keeps a global flag (`LOCAL_STREAMS`) which will be set to `true` when either of these local streams is used. (So, effectively only in test and benchmark runs.) When this flag is off, these thread locals are not even looked at and therefore will not be initialized on the first output on every thread, which also means no thread local destructors will be registered.
---
Together with https://github.com/rust-lang/rust/pull/77154, this should make output a little bit more efficient.
Jonas Schievink [Fri, 2 Oct 2020 22:31:06 +0000 (00:31 +0200)]
Rollup merge of #76107 - integer32llc:manifest-alias, r=pietroalbini
Write manifest for MAJOR.MINOR channel to enable rustup convenience
This connects to https://github.com/rust-lang/rustup/issues/794.
It's hard to remember if there have been patch releases for old versions
when you'd like to install the latest in a MAJOR.MINOR series.
When we're doing a stable release, we write duplicate manifests to
`stable`. With this change, only when we're doing a stable release, also
write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup
(and any other tooling that builds Rust release URLs) to request, say,
`1.45` and get `1.45.2` (assuming `1.45.2` is the latest available
`1.45` and assuming that we never publish patch releases out of order).
I tested the best I could; it's a bit hard to get everything set up right
to be able to run the build-manifest tool. But I was able to run it with
a release of "1.45.2" and in addition to the files like `channel-rust-1.45.2.toml`
and `channel-rust-stable.toml` (and other manifests) that I got before this
change, I now get `channel-rust-1.45.toml`.
I believe this change to be safe to deploy as it does not change or remove
anything about manifests, just adds more. The actions in rust-central-station
that interact with manifests appear to use wildcards in such a way that it will
pick up these files without any problems.
There will need to be changes to `rustup` before `rustup install 1.45` will work,
but we can wait for a stable release and stable patch releases to happen with this
change before making the `rustup` changes, so that we're not committing to anything
before we know it works.
Jonas Schievink [Fri, 2 Oct 2020 22:31:04 +0000 (00:31 +0200)]
Rollup merge of #75377 - canova:map_debug_impl, r=dtolnay
Fix Debug implementations of some of the HashMap and BTreeMap iterator types
HashMap's `ValuesMut`, BTreeMaps `ValuesMut`, IntoValues and `IntoKeys` structs were printing both keys and values on their Debug implementations. But they are iterators over either keys or values. Irrelevant values should not be visible. With this PR, they only show relevant fields.
This fixes #75297.
[Here's an example code.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0c79356ed860e347a0c1a205616f93b7) This prints this on nightly:
```
ValuesMut { inner: IterMut { range: [(1, "hello"), (2, "goodbye")], length: 2 } }
IntoKeys { inner: [(1, "hello"), (2, "goodbye")] }
IntoValues { inner: [(1, "hello"), (2, "goodbye")] }
[(2, "goodbye"), (1, "hello")]
```
After the patch this example prints these instead:
```
["hello", "goodbye"]
["hello", "goodbye"]
[1, 2]
["hello", "goodbye"]
```
I didn't add test cases for them, since I couldn't see any tests for Debug implementations anywhere. But please let me know if I should add it to a specific place.
bors [Fri, 2 Oct 2020 19:42:07 +0000 (19:42 +0000)]
Auto merge of #77462 - jonas-schievink:rollup-m0rqdh5, r=jonas-schievink
Rollup of 12 pull requests
Successful merges:
- #76101 (Update RELEASES.md for 1.47.0)
- #76739 (resolve: prohibit anon const non-static lifetimes)
- #76811 (Doc alias name restriction)
- #77405 (Add tracking issue of iter_advance_by feature)
- #77409 (Add example for iter chain struct)
- #77415 (Better error message for `async` blocks in a const-context)
- #77423 (Add `-Zprecise-enum-drop-elaboration`)
- #77432 (Use posix_spawn on musl targets)
- #77441 (Fix AVR stack corruption bug)
- #77442 (Clean up on example doc fixes for ptr::copy)
- #77444 (Fix span for incorrect pattern field and add label)
- #77453 (Stop running macOS builds on Azure Pipelines)
Jonas Schievink [Fri, 2 Oct 2020 18:27:18 +0000 (20:27 +0200)]
Rollup merge of #77453 - pietroalbini:ci-no-more-azure, r=Mark-Simulacrum
Stop running macOS builds on Azure Pipelines
The Infrastructure Team agreed to migrate macOS builds to GitHub Actions, so this commit stops running those builders on Azure Pipelines. The GitHub Actions runners are already configured to upload to the production bucket.
We can't still fully remove the Azure Pipelines configuration, as we still need to have that available until no stable releases run any of their builds on Azure Pipelines anymore. I'll open an issue to track fully removing our Azure Pipelines setup once the PR is merged.
Jonas Schievink [Fri, 2 Oct 2020 18:27:11 +0000 (20:27 +0200)]
Rollup merge of #77432 - tmiasko:posix-spawn-musl, r=cuviper
Use posix_spawn on musl targets
The posix_spawn had been available in a form suitable for use in a
Command implementation since musl 0.9.12. Use it in a preference to a
fork when possible, to benefit from CLONE_VM|CLONE_VFORK used there.
Jonas Schievink [Fri, 2 Oct 2020 18:27:09 +0000 (20:27 +0200)]
Rollup merge of #77423 - ecstatic-morse:discriminant-switch-effect-config, r=pnkfelix
Add `-Zprecise-enum-drop-elaboration`
Its purpose is to assist in debugging #77382 and #74551. Passing `-Zprecise-enum-drop-elaboration=no` will turn off the added precision that seems to be causing issues on some platforms. This assumes that we can reproduce #77382 on the latest master. I should have done this earlier. Oh well.
Jonas Schievink [Fri, 2 Oct 2020 18:26:55 +0000 (20:26 +0200)]
Rollup merge of #76739 - davidtwco:issue-75323-non-static-lifetime-in-anonconst, r=varkor
resolve: prohibit anon const non-static lifetimes
Fixes #75323, fixes #74447 and fixes #73375.
This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so, `to_region_vid`'s `bug!` had to be changed into a delayed bug, which unfortunately required providing it a `TyCtxt`.~~
---
~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const`, emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked, but it didn't silence the ICE either. To silence the ICE, I changed it to a delayed bug which worked but was more invasive that I would have liked, and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary, but I wasn't sure where that would be and wanted to get some feedback first.~~
The approach taken by this PR has been changed to implement the error in name resolution, which ended up being much simpler.
bors [Fri, 2 Oct 2020 13:22:26 +0000 (13:22 +0000)]
Auto merge of #77418 - pietroalbini:ci-environment-files, r=Mark-Simulacrum
Switch to environment files to change the environment on GHA
This PR switches our CI to use GitHub's new [environment files](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#environment-files) to set environment variables and add items to `$PATH`, as GitHub [plans to disable the old `::set-env` and `::add-path` log commands](https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/) due to a [security issue](https://github.com/actions/toolkit/security/advisories/GHSA-mfwh-5m23-j46w).
Our self-hosted runners are on version 2.273.4, so they already have support for this.
David Wood [Tue, 15 Sep 2020 13:38:41 +0000 (14:38 +0100)]
resolve: prohibit anon const non-static lifetimes
This commit modifies name resolution to emit an error when non-static
lifetimes are used in anonymous constants when the `min_const_generics`
feature is enabled.