Amanieu d'Antras [Thu, 26 Dec 2019 15:37:48 +0000 (10:37 -0500)]
Test catch_unwind vanishing
We execpt the try intrinsic to be a direct call if in -Cpanic=abort mode, and
that catch_unwind optimizes out if calling a function that does not unwind.
Mark Rousskov [Thu, 26 Dec 2019 15:02:21 +0000 (10:02 -0500)]
Inline catching panics into std::catch_unwind
This allows LLVM to inline the happy path, such that catching unwinding is
zero-cost when no panic occurs. This also allows us to match the code generated
by C++ try/catch.
bors [Sun, 1 Mar 2020 11:03:16 +0000 (11:03 +0000)]
Auto merge of #69606 - JohnTitor:rollup-i3nrrcf, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #69397 (bootstrap: Remove commit hash from LLVM version suffix to avoid rebuilds)
- #69549 (Improve MinGW detection when cross compiling )
- #69562 (Don't `bug` when taking discriminant of generator during dataflow)
- #69579 (parser: Remove `Parser::prev_span`)
- #69580 (use .copied() instead of .map(|x| *x) on iterators)
- #69583 (Do not ICE on invalid type node after parse recovery)
- #69605 (Use `opt_def_id()` over `def_id()`)
Yuki Okushi [Sun, 1 Mar 2020 10:28:09 +0000 (19:28 +0900)]
Rollup merge of #69562 - ecstatic-morse:dataflow-generator-discriminant, r=oli-obk
Don't `bug` when taking discriminant of generator during dataflow
The proper fix for rust-lang/rust-clippy#5239. `Rvalue::Discriminant` is used on generators as well as `enum`s. This didn't cause a test failure in `rustc` since we don't need to do any dataflow passes until after the generator transform that adds the `Rvalue::Discriminant`.
This required a small refactoring. `diff -w` is beneficial.
Yuki Okushi [Sun, 1 Mar 2020 10:28:07 +0000 (19:28 +0900)]
Rollup merge of #69549 - mati865:mingw, r=kennytm
Improve MinGW detection when cross compiling
Official mingw-w64 builds, MSYS2 and LLVM MinGW provide both `gcc.exe` and `$ARCH-w64-mingw32-gcc.exe` so they should not regress but I included CI changes to verify it though `@bors try` (I don't have permission).
This change will come handy when cross compiling from Linux or Cygwin since they use `gcc` as native compiler and `$ARCH-w64-mingw32-gcc.exe` for MinGW. This means users will no longer have to override the linker.
Yuki Okushi [Sun, 1 Mar 2020 10:28:05 +0000 (19:28 +0900)]
Rollup merge of #69397 - tmiasko:llvm-version-suffix, r=nagisa
bootstrap: Remove commit hash from LLVM version suffix to avoid rebuilds
The custom LLVM version suffix was introduced to avoid unintentional
library names conflicts. By default it included the LLVM submodule
commit hash. Changing the version suffix requires the complete LLVM
rebuild, and since then every change to the submodules required it as
well.
Remove the commit hash from version suffix to avoid complete rebuilds,
while leaving the `rust` string, the release number and release channel
to disambiguate the library name.
Context: version suffix was introduced by #59173 as solution to #59034.
bors [Sun, 1 Mar 2020 07:53:13 +0000 (07:53 +0000)]
Auto merge of #69295 - ecstatic-morse:unified-dataflow-generators, r=tmandry
Use new dataflow framework for generators
#65672 introduced a new dataflow framework that can handle arbitrarily complex transfer functions as well as ones expressed as a series of gen/kill operations. This PR ports the analyses used to implement generators to the new framework so that we can remove the old one. See #68241 for a prior example of this. The new framework has some superficial API changes, but this shouldn't alter the generator passes in any way.
bors [Sun, 1 Mar 2020 04:42:21 +0000 (04:42 +0000)]
Auto merge of #68943 - ecstatic-morse:no-useless-drop-on-enum-variants, r=matthewjasper
Skip `Drop` terminators for enum variants without drop glue
Split out from #68528.
When doing drop elaboration for an `enum` that may or may not be moved out of (an open drop), we check the discriminant of the `enum` to see whether the live variant has any drop flags and then check the drop flags to see whether we need to drop each field. Sometimes, however, the live
variant has no move paths and thus no drop flags. In this case, we still emit a drop terminator
for the entire enum after checking the enum discriminant. This drop shim will check the discriminant of the enum *again* and then drop the fields of the active variant. If the active variant has no drop glue, nothing will be done.
This commit skips emitting the drop terminator during drop elaboration when the "otherwise" variants, those without move paths, have no drop glue. A common example of this scenario is when an `Option` is moved from, since `Option::None` never needs drop glue. Below is a fragment the pre-codegen CFG for `Option::unwrap_or` in which we check the drop flag (`_5`) for `self` (`_1`), before and after the change.
Dylan DPC [Sat, 29 Feb 2020 17:54:07 +0000 (18:54 +0100)]
Rollup merge of #69587 - petrochenkov:reqname, r=Centril
rustc_parse: Tweak the function parameter name check
The function doesn't need a full token, only its edition.
Noticed while implementing https://github.com/rust-lang/rust/pull/69384.
I'm still not sure whether normalized or unnormalized token is a better fit for the edition check here, so https://github.com/rust-lang/rust/pull/69384 and this PR just keep the status quo behavior.
r? @Centril
Dylan DPC [Sat, 29 Feb 2020 17:54:05 +0000 (18:54 +0100)]
Rollup merge of #69584 - zantysor:fix-saturating-duration-since-comment, r=varkor
Correct comment to match behavior
Corrects the header comment on `saturating_duration_since` to match the behavior of returning 0 if the other timestamp is _later_ than the invocant, not earlier,
This is purely a documentation change, so hopefully it doesn't require an issue; if it does, I'll open one and resubmit.
bors [Sat, 29 Feb 2020 10:43:32 +0000 (10:43 +0000)]
Auto merge of #69570 - Dylan-DPC:rollup-d6boczt, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #69477 (docs: add mention of async blocks in move keyword docs)
- #69504 (Use assert_ne in hash tests)
- #69546 (use to_vec() instead of .iter().cloned().collect() to convert slices to vecs.)
- #69551 (use is_empty() instead of len() == x to determine if structs are empty.)
- #69563 (Fix no_std detection for target triples)
- #69567 (use .to_string() instead of format!() macro to create strings)
bors [Sat, 29 Feb 2020 07:27:29 +0000 (07:27 +0000)]
Auto merge of #69227 - Marwes:buffer_stderr, r=varkor
perf: Buffer stderr when writing json errors/warnings
Since `stderr` is unbuffered, writing out json messages actually take up
about ~10%/0.1s of the runtime of the `inflate` benchmark as it generates a fair number of warnings.
Dylan DPC [Sat, 29 Feb 2020 01:16:23 +0000 (02:16 +0100)]
Rollup merge of #69563 - andre-richter:fix_no_std_match, r=Mark-Simulacrum
Fix no_std detection for target triples
The current check for wether a target is no_std or not is matching for the string `-none-` in a target triple. This doesn't work for triples that end in `-none`, like `aarch64-unknown-none`.
Fix this by matching for `-none` instead.
I checked for all the current target triples containing `none`, and this should not generate any false positives.
This fixes an issue encountered in https://github.com/rust-lang/rust/pull/68334
Dylan DPC [Sat, 29 Feb 2020 01:16:18 +0000 (02:16 +0100)]
Rollup merge of #69504 - MichaelMcDonnell:hash_assert_ne, r=LukasKalbertodt
Use assert_ne in hash tests
The hash tests were written before the assert_ne macro was added to the standard library. The assert_ne macro provides better output in case of a failure.
Andre Richter [Fri, 28 Feb 2020 20:51:16 +0000 (21:51 +0100)]
Fix no_std detection for target triples
The current check for wether a target is no_std or not is matching for the
string "-none-" in a target triple. This doesn't work for triples that end in
"-none", like "aarch64-unknown-none".
Fix this by matching for "-none" instead.
I checked for all the current target triples containing "none", and this should
not generate any false positives.
This fixes an issue encountered in https://github.com/rust-lang/rust/pull/68334
Esteban Küber [Wed, 19 Feb 2020 01:53:25 +0000 (17:53 -0800)]
Show information of chain of bound obligations
When the obligation that couldn't be fulfilled is specific to a nested
obligation, maintain both the nested and parent obligations around for
more accurate and detailed error reporting.
Esteban Küber [Wed, 19 Feb 2020 00:35:47 +0000 (16:35 -0800)]
Track all predicates in errors, not just trait obligations
Surface associated type projection bounds that could not be fulfilled in
E0599 errors. Always present the list of unfulfilled trait bounds,
regardless of whether we're pointing at the ADT or trait that didn't
satisfy it.
Rollup merge of #69539 - Centril:fix-69401, r=petrochenkov
late resolve, visit_fn: bail early if there's no body.
Fixes https://github.com/rust-lang/rust/issues/69401 which was injected by https://github.com/rust-lang/rust/commit/b2c6eeb713d4cf9b35b7dda6ff2b0274e7f24684 in https://github.com/rust-lang/rust/pull/68788.
So, after https://github.com/rust-lang/rust/pull/69006, its follow-ups and an attempt to remove `Parser::prev_span` I came to the conclusion that the unnormalized token and its span is what you want in most cases, so it should be default.
Normalization only makes difference in few cases where we are checking against `token::Ident` or `token::Lifetime` specifically.
This PR uses `normalized_token` for those cases.
Using normalization explicitly means that people writing code should remember about `NtIdent` and `NtLifetime` in general. (That is alleviated by the fact that `token.ident()` and `fn parse_ident_*` are already written.)
Remembering about `NtIdent`, was, however, already the case, kind of, because the implicit normalization was performed only for the current/previous token, but not for things like `look_ahead`.
As a result, most of token classification methods in `token.rs` already take `NtIdent` into account (this PR fixes a few pre-existing minor mistakes though).
The next step is removing `normalized(_prev)_token` entirely and replacing it with `token.ident()` (mostly) and `token.normalize()` (occasionally).
I want to make it a separate PR for that and run it though perf.
`normalized_token` filled on every bump has both a potential to avoid repeated normalization, and to do unnecessary work in advance (it probably doesn't matter anyway, the normalization is very cheap).
On `Self(...)` (that is, a `Res::SelfCtor`), do not use `self.impl_self_ty(...)`. The problem with that method is that it creates unconstrained inference variables for type parameters in the `impl` (e.g. `impl<T> S0<T>`). These variables then eventually get substituted for something else when they come in contact with the expected type (e.g. `S0<u8>`) or merely the arguments passed to the tuple constructor (e.g. the `0` in `Self(0)`).
Instead of using `self.impl_self_ty(...)`, we instead merely use `let ty = self.normalize_ty(span, tcx.at(span).type_of(impl_def_id));` to get the rewritten `res`.
bors [Fri, 28 Feb 2020 14:24:57 +0000 (14:24 +0000)]
Auto merge of #69148 - estebank:cold-as-ice, r=oli-obk
Account for bounds and asociated items when denying `_`
Fix #68801, #69204. Follow up to #67597 and #68071.
Output for the original ICE report:
```
Checking vinoteca v5.0.0 (/Users/ekuber/workspace/vinoteca)
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> src/producers.rs:43:70
|
43 | pub fn top<Table: diesel::Table + diesel::query_dsl::InternalJoinDsl<_, diesel::query_source::joins::Inner, _>>(table: Table, limit: usize, connection: DbConn) -> RestResult<Vec<TopWineType>> {
| ^ not allowed in type signatures ^ not allowed in type signatures