bors [Sun, 25 Oct 2020 09:23:45 +0000 (09:23 +0000)]
Auto merge of #77476 - tgnottingham:buffered_siphasher128, r=nnethercote
perf: buffer SipHasher128
This is an attempt to improve Siphasher128 performance by buffering input. Although it reduces instruction count, I'm not confident the effect on wall times, or lack-thereof, is worth the change.
---
Additional notes not reflected in source comments:
* Implementation choices were guided by a combination of results from rustc-perf and micro-benchmarks, mostly the former.
* ~~I tried a couple of different struct layouts that might be more cache friendly with no obvious effect.~~ Update: a particular struct layout was chosen, but it's not critical to performance. See comments in source and discussion below.
* I suspect that buffering would be important to a SIMD-accelerated algorithm, but from what I've read and my own tests, SipHash does not seem very amenable to SIMD acceleration, at least by SSE.
bors [Sun, 25 Oct 2020 04:48:37 +0000 (04:48 +0000)]
Auto merge of #77398 - wesleywiser:measureme_0_8, r=Mark-Simulacrum
Upgrade to measureme 9.0.0
I believe I did this correctly but there's still a reference to `measureme@0.7.1` coming from `rustc-ap-rustc_data_structures` and I'm not sure how to resolve that.
r? `@Mark-Simulacrum`
We'll also need to deploy the new version of the tools on perf.rlo.
bors [Sun, 25 Oct 2020 02:27:09 +0000 (02:27 +0000)]
Auto merge of #77526 - RalfJung:dont-promote-unions, r=lcnr
stop promoting union field accesses in 'const'
Turns out that promotion of union field accesses is the only difference between "promotion in `const`/`static` bodies" and "explicit promotion". So if we can remove this, we have finally achieved what I thought to already be the case -- that the bodies of `const`/`static` initializers behave the same as explicit promotion contexts.
The reason we do not want to promote union field accesses is that they can introduce UB, i.e., they can go wrong. We want to [minimize the ways promoteds can fail to evaluate](https://github.com/rust-lang/const-eval/issues/53). Also this change makes things more consistent overall, removing a special case that was added without much consideration (as far as I can tell).
bors [Sat, 24 Oct 2020 21:42:39 +0000 (21:42 +0000)]
Auto merge of #78334 - jonas-schievink:rollup-z0gzbmm, r=jonas-schievink
Rollup of 12 pull requests
Successful merges:
- #75115 (`#[deny(unsafe_op_in_unsafe_fn)]` in sys/cloudabi)
- #76614 (change the order of type arguments on ControlFlow)
- #77610 (revise Hermit's mutex interface to support the behaviour of StaticMutex)
- #77830 (Simplify query proc-macros)
- #77930 (Do not ICE with TraitPredicates containing [type error])
- #78069 (Fix const core::panic!(non_literal_str).)
- #78072 (Cleanup constant matching in exhaustiveness checking)
- #78119 (Throw core::panic!("message") as &str instead of String.)
- #78191 (Introduce a temporary for discriminant value in MatchBranchSimplification)
- #78272 (const_evaluatable_checked: deal with unused nodes + div)
- #78318 (TyCtxt: generate single impl block with `slice_interners` macro)
- #78327 (resolve: Relax macro resolution consistency check to account for any errors)
Jonas Schievink [Sat, 24 Oct 2020 20:40:00 +0000 (22:40 +0200)]
Rollup merge of #78327 - petrochenkov:inconsist, r=Aaron1011
resolve: Relax macro resolution consistency check to account for any errors
The check was previously omitted only when ambiguity errors or `Res::Err` were encountered, but the "macro-expanded `extern crate` items cannot shadow..." error (at least) can cause same inconsistencies as well.
Jonas Schievink [Sat, 24 Oct 2020 20:39:55 +0000 (22:39 +0200)]
Rollup merge of #78191 - tmiasko:temp-match-branch-simplification, r=oli-obk
Introduce a temporary for discriminant value in MatchBranchSimplification
The optimization introduces additional uses of the discriminant operand, but
does not ensure that it is still valid to evaluate it or that it still
evaluates to the same value.
Evaluate it once at original position, and store the result in a new temporary.
Follow up on #78151. The optimization remains disabled by default.
Jonas Schievink [Sat, 24 Oct 2020 20:39:53 +0000 (22:39 +0200)]
Rollup merge of #78119 - fusion-engineering-forks:panic-use-as-str, r=Amanieu
Throw core::panic!("message") as &str instead of String.
This makes `core::panic!("message")` consistent with `std::panic!("message")`, which throws a `&str` and not a `String`.
This also makes any other panics from `core::panicking::panic` result in a `&str` rather than a `String`, which includes compiler-generated panics such as the panics generated for `mem::zeroed()`.
fn check(msg: &(dyn Any + Send)) {
if let Some(s) = msg.downcast_ref::<String>() {
println!("Got a String: {:?}", s);
} else if let Some(s) = msg.downcast_ref::<&str>() {
println!("Got a &str: {:?}", s);
}
}
```
Before:
```
Got a String: "core"
Got a String: "core"
Got a &str: "std"
Got a &str: "std"
```
After:
```
Got a &str: "core"
Got a &str: "core"
Got a &str: "std"
Got a &str: "std"
```
Jonas Schievink [Sat, 24 Oct 2020 20:39:51 +0000 (22:39 +0200)]
Rollup merge of #78072 - Nadrieril:cleanup-constant-matching, r=varkor
Cleanup constant matching in exhaustiveness checking
This supercedes https://github.com/rust-lang/rust/pull/77390. I made the `Opaque` constructor work.
I have opened two issues https://github.com/rust-lang/rust/issues/78071 and https://github.com/rust-lang/rust/issues/78057 from the discussion we had on the previous PR. They are not regressions nor directly related to the current PR so I thought we'd deal with them separately.
I left a FIXME somewhere because I didn't know how to compare string constants for equality. There might even be some unicode things that need to happen there. In the meantime I preserved previous behavior.
Jonas Schievink [Sat, 24 Oct 2020 20:39:49 +0000 (22:39 +0200)]
Rollup merge of #78069 - fusion-engineering-forks:core-const-panic-str, r=RalfJung
Fix const core::panic!(non_literal_str).
Invocations of `core::panic!(x)` where `x` is not a string literal expand to `panic!("{}", x)`, which is not understood by the const panic logic right now. This adds `panic_str` as a lang item, and modifies the const eval implementation to hook into this item as well.
This fixes the issue mentioned here: https://github.com/rust-lang/rust/issues/51999#issuecomment-687604248
Jonas Schievink [Sat, 24 Oct 2020 20:39:44 +0000 (22:39 +0200)]
Rollup merge of #77610 - hermitcore:dtors, r=m-ou-se
revise Hermit's mutex interface to support the behaviour of StaticMutex
rust-lang/rust#77147 simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. To support the new behavior of StaticMutex, we move part of the mutex implementation into libstd.
The interface to the OS changed. Consequently, I removed a few functions, which aren't longer needed.
bors [Sat, 24 Oct 2020 19:23:32 +0000 (19:23 +0000)]
Auto merge of #77255 - Aaron1011:feature/collect-attr-tokens, r=petrochenkov
Unconditionally capture tokens for attributes.
This allows us to avoid synthesizing tokens in `prepend_attr`, since we
have the original tokens available.
We still need to synthesize tokens when expanding `cfg_attr`,
but this is an unavoidable consequence of the syntax of `cfg_attr` -
the user does not supply the `#` and `[]` tokens that a `cfg_attr`
expands to.
This is based on PR https://github.com/rust-lang/rust/pull/77250 - this PR exposes a bug in the current `collect_tokens` implementation, which is fixed by the rewrite.
bors [Sat, 24 Oct 2020 16:12:01 +0000 (16:12 +0000)]
Auto merge of #78319 - jonas-schievink:rollup-vzj8a6l, r=jonas-schievink
Rollup of 15 pull requests
Successful merges:
- #76649 (Add a spin loop hint for Arc::downgrade)
- #77392 (add `insert` to `Option`)
- #77716 (Revert "Allow dynamic linking for iOS/tvOS targets.")
- #78109 (Check for exhaustion in RangeInclusive::contains and slicing)
- #78198 (Simplify assert terminator only if condition evaluates to expected value)
- #78243 (--test-args flag description)
- #78249 (improve const infer error)
- #78250 (Document inline-const)
- #78264 (Add regression test for issue-77475)
- #78274 (Update description of Empty Enum for accuracy)
- #78278 (move `visit_predicate` into `TypeVisitor`)
- #78292 (Loop instead of recursion)
- #78293 (Always store Rustdoc theme when it's changed)
- #78300 (Make codegen coverage_context optional, and check)
- #78307 (Revert "Set .llvmbc and .llvmcmd sections as allocatable")
Jonas Schievink [Sat, 24 Oct 2020 12:12:18 +0000 (14:12 +0200)]
Rollup merge of #78300 - richkadel:coverage-cx, r=wesleywiser
Make codegen coverage_context optional, and check
Addresses Issue #78286
Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).
Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.
Jonas Schievink [Sat, 24 Oct 2020 12:12:16 +0000 (14:12 +0200)]
Rollup merge of #78293 - nasso:master, r=GuillaumeGomez
Always store Rustdoc theme when it's changed
`switchTheme` (too) lazily updated the value of `rustdoc-theme` in `localStorage`, leading to an incorrect stored value when the system theme is the same as the default (`light`) theme.
Jonas Schievink [Sat, 24 Oct 2020 12:12:13 +0000 (14:12 +0200)]
Rollup merge of #78278 - lcnr:predicate-visit, r=matthewjasper
move `visit_predicate` into `TypeVisitor`
Seems easier than dealing with `PredicateVisitor` for me which I needed for object safety checks for `PredicateAtom::ConstEvaluatable`. Is there a reason I am missing for this split?
Jonas Schievink [Sat, 24 Oct 2020 12:12:06 +0000 (14:12 +0200)]
Rollup merge of #78249 - lcnr:ct-infer-origin, r=varkor
improve const infer error
For type inference we probably have to be careful about subtyping and stuff but considering that subtyping shouldn't be relevant for constants I don't really see a reason why we may not want to reuse the const origin here.
Jonas Schievink [Sat, 24 Oct 2020 12:11:59 +0000 (14:11 +0200)]
Rollup merge of #77716 - francesca64:revert-ios-dynamic-linking, r=jonas-schievink
Revert "Allow dynamic linking for iOS/tvOS targets."
This reverts PR #73516.
On macOS I compile static libs for iOS, automated using [cargo-mobile](https://github.com/BrainiumLLC/cargo-mobile), which has worked smoothly for the past 2 years. However, upon updating to Rust 1.46.0, I was no longer able to use Rust on iOS. I've bisected this to the PR referenced above.
For most projects tested, apps now immediately crash with a message like this:
```
dyld: Library not loaded: /Users/francesca/Projects/example/target/aarch64-apple-ios/debug/deps/libexample.dylib
Referenced from: /private/var/containers/Bundle/Application/745912AF-A928-465C-B340-872BD1C9F368/example.app/example
Reason: image not found
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib:/Developer/Library/PrivateFrameworks/GPUTools.framework/libglInterpose.dylib:/usr/lib/libMTLCapture.dylib
```
This can be reproduced by using cargo-mobile to generate a winit example project, and then attempting to run it on an iOS device (`cargo mobile init && cargo apple open`).
In our projects that depend on DisplayLink, the build instead fails with a linker error:
```
= note: Undefined symbols for architecture arm64:
"_CACurrentMediaTime", referenced from:
display_link::ios::run_callback_ios10::hda81197ff46aedbd in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
display_link::ios::run_callback_pre_ios10::h91f085da19374320 in libapp-4f0abc1d7684103f.rlib(app-4f0abc1d7684103f.40d4iro0yz1iy487.rcgu.o)
ld: symbol(s) not found for architecture arm64
```
After reverting the change to enable dynamic linking on iOS, everything works the same as it did on Rust 1.45.2 for me.
In the future, would it be possible for me to be pinged when iOS-related PRs are made? I work for a company that intends on using Rust on iOS in production, so I'd gladly provide testing.
It's also useful in contexts not requiring the mutability of the reference.
Here's a typical cache example:
```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => {
cache = Some(compute_cache_entry());
// unwrap is OK because we just filled the option
&cache.as_ref().unwrap().content
}
};
```
It can be changed into
```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => &cache.insert(compute_cache_entry()).content,
};
```
Rich Kadel [Fri, 23 Oct 2020 18:41:56 +0000 (11:41 -0700)]
Make codegen coverage_context optional, and check
Addresses Issue #78286
Libraries compiled with coverage and linked with out enabling coverage
would fail when attempting to add the library's coverage statements to
the codegen coverage context (None).
Now, if coverage statements are encountered while compiling / linking
with `-Z instrument-coverage` disabled, codegen will *not* attempt to
add code regions to a coverage map, and it will not inject the LLVM
instrprof_increment intrinsic calls.
bors [Fri, 23 Oct 2020 17:32:04 +0000 (17:32 +0000)]
Auto merge of #77015 - davidtwco:check-attr-variant-closure-expr, r=lcnr
passes: `check_attr` on more targets
This PR modifies `check_attr` so that:
- Enum variants are now checked (some attributes would not have been prohibited on variants previously).
- `check_expr_attributes` and `check_stmt_attributes` are removed as `check_attributes` can perform the same checks. This means that codegen attribute errors aren't shown if there are other errors first (e.g. from other attributes, as shown in `src/test/ui/macros/issue-68060.rs` changes below).
It's also useful in contexts not requiring the mutability of the reference.
Here's a typical cache example:
```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => {
cache = Some(compute_cache_entry());
// unwrap is OK because we just filled the option
&cache.as_ref().unwrap().content
}
};
```
It can be changed into
```
let checked_cache = cache.as_ref().filter(|e| e.is_valid());
let content = match checked_cache {
Some(e) => &e.content,
None => &cache.insert_with(compute_cache_entry).content,
};
```
bors [Fri, 23 Oct 2020 09:31:44 +0000 (09:31 +0000)]
Auto merge of #78270 - JohnTitor:rollup-bldrjh5, r=JohnTitor
Rollup of 17 pull requests
Successful merges:
- #77268 (Link to "Contributing to Rust" rather than "Getting Started".)
- #77339 (Implement TryFrom between NonZero types.)
- #77488 (Mark `repr128` as `incomplete_features`)
- #77890 (Fixing escaping to ensure generation of welformed json.)
- #77918 (Cleanup network tests)
- #77920 (Avoid extraneous space between visibility kw and ident for statics)
- #77969 (Doc formating consistency between slice sort and sort_unstable, and big O notation consistency)
- #78098 (Clean up and improve some docs)
- #78116 (Make inline const work in range patterns)
- #78153 (Sync LLVM submodule if it has been initialized)
- #78163 (Clean up lib docs)
- #78169 (Update cargo)
- #78231 (Make closures inherit the parent function's target features)
- #78235 (Explain where the closure return type was inferred)
- #78255 (Reduce diagram mess in 'match arms have incompatible types' error)
- #78263 (Add regression test of issue-77668)
- #78265 (Add some inference-related regression tests about incorrect diagnostics)
Yuki Okushi [Fri, 23 Oct 2020 09:26:40 +0000 (18:26 +0900)]
Rollup merge of #78255 - dtolnay:match, r=lcnr
Reduce diagram mess in 'match arms have incompatible types' error
I noticed this wild diagram in https://twitter.com/a_hoverbear/status/1318960787105353728 which I think does not benefit from the big outer vertical span.
This PR shrinks the outer span to cover just the `match` keyword and scrutinee expression *if* at least one of the highlighted match arms involved in the error is multiline.
**Before:**
<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
<b>--></b> src/topology/builder.rs:141:35
<b>|</b>
<b>120 |</b> let transform = match transform {
<b>| _________________________-</b>
<b>121 | |</b> Transform::Function(t) => {
<b>| _|_______________________________________-</b>
<b>122 | | |</b> filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | | |</b> futures::stream::iter(match v {
<b>124 | | |</b> Err(e) => {
<b>... | |</b>
<b>139 | | |</b> .compat();
<b>140 | | |</b> }
<b>| |_|_____________- this is found to be of type `()`</b>
<b>141 | |</b> Transform::Task(t) => t
<b>| _|___________________________________^</b>
<b>142 | | |</b> .transform(filter_event_type(input_rx, input_type))
<b>143 | | |</b> .forward(output)
<b>144 | | |</b> .map(|_| debug!("Finished"))
<b>145 | | |</b> .compat(),
<b>| |_|_________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>146 | |</b> };
<b>| |_________- `match` arms have incompatible types</b>
<b>|</b>
<b>= note:</b> expected type `<b>()</b>`
found struct `<b>futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = (), Item = event::Event> + std::marker::Send>, topology::fanout::Fanout>, [closure@src/topology/builder.rs:144:22: 144:44]>></b>`
</pre>
**After:**
<pre>
<b>error[E0308]: `match` arms have incompatible types</b>
<b>--></b> src/topology/builder.rs:141:35
<b>|</b>
<b>120 |</b> let transform = match transform {
<b>| --------------- `match` arms have incompatible types</b>
<b>121 |</b> Transform::Function(t) => {
<b>| _________________________________________-</b>
<b>122 | |</b> filter_event_type(input_rx, input_type).compat().flat_map(|v| {
<b>123 | |</b> futures::stream::iter(match v {
<b>124 | |</b> Err(e) => {
<b>... |</b>
<b>139 | |</b> .compat();
<b>140 | |</b> }
<b>| |_______________- this is found to be of type `()`</b>
<b>141 |</b> Transform::Task(t) => t
<b>| _____________________________________^</b>
<b>142 | |</b> .transform(filter_event_type(input_rx, input_type))
<b>143 | |</b> .forward(output)
<b>144 | |</b> .map(|_| debug!("Finished"))
<b>145 | |</b> .compat(),
<b>| |___________________________^ expected `()`, found struct `futures::compat::Compat01As03`</b>
<b>|</b>
<b>= note:</b> expected type `<b>()</b>`
found struct `<b>futures::compat::Compat01As03<futures::Map<futures::stream::Forward<std::boxed::Box<dyn futures::Stream<Error = (), Item = event::Event> + std::marker::Send>, topology::fanout::Fanout>, [closure@src/topology/builder.rs:144:22: 144:44]>></b>`
</pre>
Yuki Okushi [Fri, 23 Oct 2020 09:26:32 +0000 (18:26 +0900)]
Rollup merge of #78153 - est31:downloaded_llvm_maybe_sync, r=Mark-Simulacrum
Sync LLVM submodule if it has been initialized
Since having enabled the download-ci-llvm option,
and having rebased on top of #76864,
I've noticed that I had to update the llvm-project
submodule manually if it was checked out.
Orignally, the submodule update logic was
introduced to reduce the friction for contributors
to manage the submodules, or in other words, to prevent
getting PRs that have unwanted submodule rollbacks
because the contributors didn't run git submodule update.
This commit adds logic to ensure there is no inadvertent
LLVM submodule rollback in a PR if download-ci-llvm
(or llvm-config) is enabled. It will detect whether the
llvm-project submodule is initialized, and if so, update
it in any case. If it is not initialized, behaviour is
kept to not do any update/initialization.
An alternative to the chosen implementation would
be to not pass the --init command line arg to
`git submodule update` for the src/llvm-project
submodule. This would show a confusing error message
however on all builds with an uninitialized repo.
We could pass the --silent param, but we still want
it to print something if it is initialized and has
to update something.
So we just do a manual check for whether the
submodule is initialized.
Yuki Okushi [Fri, 23 Oct 2020 09:26:28 +0000 (18:26 +0900)]
Rollup merge of #78098 - camelid:fixup-docs, r=steveklabnik
Clean up and improve some docs
* compiler docs
* Don't format list as part of a code block
* Clean up some other formatting
* rustdoc book
* Update CommonMark spec version to latest (0.28 -> 0.29)
* Clean up some various wording and formatting
Yuki Okushi [Fri, 23 Oct 2020 09:26:26 +0000 (18:26 +0900)]
Rollup merge of #77969 - ryan-scott-dev:bigo-notation-consistency, r=m-ou-se
Doc formating consistency between slice sort and sort_unstable, and big O notation consistency
Updated documentation for slice sorting methods to be consistent between stable and unstable versions, which just ended up being minor formatting differences.
I also went through and updated any doc comments with big O notation to be consistent with #74010 by italicizing them rather than having them in a code block.
Yuki Okushi [Fri, 23 Oct 2020 09:26:24 +0000 (18:26 +0900)]
Rollup merge of #77920 - ayazhafiz:i/mut-ident-spacing, r=jyn514
Avoid extraneous space between visibility kw and ident for statics
Today, given a static like `static mut FOO: usize = 1`, rustdoc would
emit `static mut FOO: usize = 1`, as it emits both the mutability kw
with a space and reserves a space after the mutability kw. This patch
fixes that misformatting.
This patch also adds some tests for emit of other statics, as I could
not find an existing test devoted to statics.
Yuki Okushi [Fri, 23 Oct 2020 09:26:20 +0000 (18:26 +0900)]
Rollup merge of #77890 - gilescope:welformed-json-output-from-libtest, r=KodrAus
Fixing escaping to ensure generation of welformed json.
doc tests' json name have a filename in them. When json test output is asked for on windows currently produces invalid json.
Tracking issue for json test output: #49359
Yuki Okushi [Fri, 23 Oct 2020 09:26:18 +0000 (18:26 +0900)]
Rollup merge of #77488 - varkor:repr128-incomplete_features, r=jonas-schievink
Mark `repr128` as `incomplete_features`
As mentioned in https://github.com/rust-lang/rust/issues/56071 and noticed in https://github.com/rust-lang/rust/issues/77457, `repr(u128)` and `repr(i128)` do not work properly due to lack of LLVM support. We should thus warn users trying to use the feature that they may encounter ICEs when using it.
Yuki Okushi [Fri, 23 Oct 2020 09:26:14 +0000 (18:26 +0900)]
Rollup merge of #77268 - follower:patch-3, r=jyn514
Link to "Contributing to Rust" rather than "Getting Started".
Change to link to "Contributing to Rust" chapter of `rustc` Dev Guide, primarily on the basis that:
* The GitHub "first contribution" Issue "pop-up" says "Be sure to review the [contributing guidelines] and [code of conduct]" and links to this file.
* The "Bug Report" section _seems_ to restrict itself to if "a compiler error message [told] you to come here".
* The previous content of `CONTRIBUTING.md` now lives in the "Contributing to Rust" chapter.
When/if the guide/"Getting Started" section gets revised to not be `rustc`-specific, the choice of linked chapter could be updated.
In the meantime this prevents leading first time contributors into a confusing cul de sac.
_[I wasn't planning to make a PR for this until discussion in #77215 concluded but the discovery that the "first issue" pop-up also links to this document IMO makes it a higher priority to make the link useful sooner rather than later.]_
projects / rust.git / log