Dylan DPC [Mon, 2 Mar 2020 12:42:43 +0000 (13:42 +0100)]
Rollup merge of #69624 - ehuss:toolstate-beta-regress, r=Mark-Simulacrum
Toolstate: Don't block beta week on already broken tools.
This changes it so that tools are allowed to be broken entering the beta week if they are already broken. This restores the original behavior before the changes in #69332.
Dylan DPC [Mon, 2 Mar 2020 12:42:41 +0000 (13:42 +0100)]
Rollup merge of #69623 - Centril:fix-69396-tmp, r=petrochenkov
stash API: remove panic to fix ICE.
Implements the temporary solution suggested in https://github.com/rust-lang/rust/pull/69537#issuecomment-593143975.
Fixes https://github.com/rust-lang/rust/issues/69396.
Dylan DPC [Mon, 2 Mar 2020 12:42:37 +0000 (13:42 +0100)]
Rollup merge of #69544 - lqd:unrevert-67174, r=Mark-Simulacrum
Unrevert "Remove `checked_add` in `Layout::repeat`"
This reapplies @kraai's original `libcore::alloc::Layout::repeat` change from #67174 which was temporarily reverted in #69241. Now that the proper LLVM fix has been cherry-picked, we can unrevert the revert.
This change was originally reviewed by @hanna-kruppe on the initial PR.
bors [Mon, 2 Mar 2020 09:37:35 +0000 (09:37 +0000)]
Auto merge of #69257 - RalfJung:layout-visitor, r=eddyb
Adjust Miri value visitor, and doc-comment layout components
I realized that I still didn't have quite the right intuition for how our `LayoutDetails` work, so I had to adjust the Miri value visitor to the things I understood better now. I also added some doc-comments to `LayoutDetails` as a hopefully canonical place to note such things.
The main visitor change is that we *first* look at all the fields (according to `FieldPlacement`), and *then* check the variants and handle `Multiple` appropriately. I did not quite realize how orthogonal "fields" and "variants" are.
I also moved the check for the scalar ABI to *after* checking all the fields; this leads to better (more type-driven) error messages.
And it looks like we can finally remove that magic hack for `ty::Generator`. :D
r? @oli-obk for the Miri/visitor changes and @eddyb for the layout docs
The Miri PR is at: https://github.com/rust-lang/miri/pull/1178
bors [Mon, 2 Mar 2020 06:30:52 +0000 (06:30 +0000)]
Auto merge of #69469 - matthewjasper:type-flags, r=cramertj
Clean up TypeFlags
* Add a new method `has_infer_types_or_consts` that's used instead of `has_infer_types` most of the time, since there's generally no reason to only consider types.
* Remove `has_closure_types`/`HAS_TY_CLOSURE`, because closures are no longer implicitly linked to the `InferCtxt`.
* Reorder flags to group similar ones together
* Make some flags more granular
* Compute `HAS_FREE_LOCAL_NAMES` from the other flags
* Add some more doc comments
bors [Mon, 2 Mar 2020 00:07:06 +0000 (00:07 +0000)]
Auto merge of #69432 - petrochenkov:alldeps, r=eddyb
rustc_metadata: Load metadata for indirect macro-only dependencies
Imagine this dependency chain between crates
```
Executable crate -> Library crate -> Macro crate
```
where "Library crate" uses the macros from "Macro crate" for some code generation, but doesn't reexport them any further.
Currently, when compiling "Executable crate" we don't even load metadata for it, because why would we want to load any metadata from "Macro crate" if it already did all its code generation job when compiling "Library crate".
Right?
Wrong!
Hygiene data and spans (https://github.com/rust-lang/rust/issues/68686, https://github.com/rust-lang/rust/pull/68941) from "Macro crate" still may need to be decoded from "Executable crate".
So we'll have to load them properly.
Questions:
- How this will affect compile times for larger crate trees in practice? How to measure it?
Hygiene/span encoding/decoding will necessarily slow down compilation because right now we just don't do some work that we should do, but this introduces a whole new way to slow down things. E.g. loading metadata for `syn` (and its dependencies) when compiling your executable if one of its library dependencies uses it.
- We are currently detecting whether a crate reexports macros from "Macro crate" or not, could we similarly detect whether a crate "reexports spans" and keep it unloaded if it doesn't?
Or at least "reexports important spans" affecting hygiene, we can probably lose spans that only affect diagnostics.
Matthew Jasper [Sat, 22 Feb 2020 15:09:17 +0000 (15:09 +0000)]
Clean up TypeFlags
* Reorder flags to group similar ones together
* Make some flags more granular
* Compute `HAS_FREE_LOCAL_NAMES` from the other flags
* Remove `HAS_TY_CLOSURE`
* Add some more doc comments
Matthew Jasper [Sat, 22 Feb 2020 14:10:17 +0000 (14:10 +0000)]
Fix use of `has_infer_types`
* Add a new method `has_infer_types_or_consts` that's used instead most
of the time, since there's generally no reason to only consider types.
* Remove use of `has_closure_types`, because closures are no longer
implicitly linked to the `InferCtxt`.
Dylan DPC [Sun, 1 Mar 2020 16:23:26 +0000 (17:23 +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.
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
projects / rust.git / log