bors [Tue, 3 Mar 2020 16:38:02 +0000 (16:38 +0000)]
Auto merge of #69371 - tmiasko:weak-lang-cycle, r=alexcrichton
Improve linking of crates with circular dependencies
Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:
* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.
This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.
The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.
bors [Tue, 3 Mar 2020 13:27:52 +0000 (13:27 +0000)]
Auto merge of #69482 - lqd:poloniusup, r=nikomatsakis
Polonius: update `polonius-engine` to 0.12.0
Since @albins won't have the time to finish up #68993 for a while, I'll take care of the trivial remaining tasks (rebasing, taking care of tidy/rustfmt).
I'll r? @nikomatsakis since they're assigned to #68993, but have actually [already reviewed it pre-rebase](https://github.com/rust-lang/rust/pull/68993#issuecomment-586413089).
When CI passes: I'll notify bors and close #68993, since this PR supersedes it.
Tomasz Miąsko [Sat, 22 Feb 2020 00:00:00 +0000 (00:00 +0000)]
Improve linking of crates with circular dependencies
Previously, the code responsible for handling the cycles between crates
introduces through weak lang items, would keep a set of missing language
items:
* extending it with items missing from the current crate,
* removing items provided by the current crate,
* grouping the crates when the set changed from non-empty back to empty.
This could produce incorrect results, if a lang item was missing from a
crate that comes after the crate that provides it (in the loop iteration
order). In that case the grouping would not take place.
The changes here address this specific failure scenario by keeping track
of two separate sets of crates. Those that are required to link successfully,
and those that are available for linking.
Yuki Okushi [Tue, 3 Mar 2020 08:50:08 +0000 (17:50 +0900)]
Rollup merge of #69619 - matthiaskrgr:misc, r=eddyb
more cleanups
* use starts_with() instead of chars().next() == Some(x)
* use subsec_micros() instead of subsec_nanos() / 1000
* use for (idx, item) in iter.enumerate() instead of manually counting loop iterations with variables
* use values() or keys() respectively when iterating only over keys or values of maps.
Yuki Okushi [Tue, 3 Mar 2020 08:50:06 +0000 (17:50 +0900)]
Rollup merge of #69609 - TimDiekmann:excess, r=Amanieu
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
bors [Tue, 3 Mar 2020 04:31:01 +0000 (04:31 +0000)]
Auto merge of #69247 - CAD97:remove-chalk, r=nikomatsakis
Remove experimental chalk option
As suggested by @nikomatsakis [here](https://github.com/rust-lang/rust/pull/68807#issuecomment-583339932).
The current version of chalk used by the experimental `-Zchalk` flag is [v0.9.0, which is over a year old](https://crates.io/crates/chalk-engine). Since v0.9.0, chalk has seen [a lot of further development](https://github.com/rust-lang/chalk/compare/41dfe13...master), and the intent is to eventually upgrade rustc to use a more recent chalk.
However, it will take a decent chunk of effort to upgrade the current experimental chalk support, and it is currently [blocking at least some PRs](https://github.com/rust-lang/rust/pull/68807) due to chalk:0.9.0's use of unstable features. So for the interim until the next chalk release and experimental rustc integration, we remove the chalk-specific code from rustc.
bors [Mon, 2 Mar 2020 22:58:48 +0000 (22:58 +0000)]
Auto merge of #69627 - ehuss:update-cargo-clippy, r=Dylan-DPC
Update cargo, clippy
Closes #69601
## cargo
16 commits in e57bd02999c9f40d52116e0beca7d1dccb0643de..bda50510d1daf6e9c53ad6ccf603da6e0fa8103f
2020-02-21 20:20:10 +0000 to 2020-03-02 18:05:34 +0000
- Fix rare failure in collision_export test. (rust-lang/cargo#7956)
- Ignore broken Cargo.toml in git sources (rust-lang/cargo#7947)
- Add more fingerprint mtime debug logging. (rust-lang/cargo#7952)
- Fix plugin tests for latest nightly. (rust-lang/cargo#7955)
- Simplified usage code of SipHasher (rust-lang/cargo#7945)
- Add a special case for git config discovery inside tests (rust-lang/cargo#7944)
- Fixes issue rust-lang/cargo#7543 (rust-lang/cargo#7946)
- Filter out cfgs which should not be used during build (rust-lang/cargo#7943)
- Provide extra context on a query failure. (rust-lang/cargo#7934)
- Try to clarify `cargo metadata`'s relationship with the workspace. (rust-lang/cargo#7927)
- Update libgit2 dependency (rust-lang/cargo#7939)
- Fix link in comment (rust-lang/cargo#7936)
- Enable `cargo doc --open` tests on macos. (rust-lang/cargo#7932)
- build-std: remove sysroot probe (rust-lang/cargo#7931)
- Try to clarify how feature flags work on the "current" package. (rust-lang/cargo#7928)
- Add extra details in the new feature resolver doc comment. (rust-lang/cargo#7918)
## clippy
6 commits in fc5d0cc583cb1cd35d58fdb7f3e0cfa12dccd6c0..8b7f7e667268921c278af94ae30a61e87a22b22b
2020-02-24 05:58:17 +0000 to 2020-03-02 20:00:31 +0000
- Rustup to rust-lang/rust#69469 (rust-lang-nursery/rust-clippy#5254)
- Some rustups (rust-lang-nursery/rust-clippy#5247)
- Update git2 to 0.12 (rust-lang-nursery/rust-clippy#5232)
- Rustup to rust-lang/rust#61812 (rust-lang-nursery/rust-clippy#5231)
- Add lint to improve floating-point expressions (rust-lang-nursery/rust-clippy#4897)
- Do not run deploy action on other repos (rust-lang-nursery/rust-clippy#5222)
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.