bors [Wed, 4 Mar 2020 07:29:32 +0000 (07:29 +0000)]
Auto merge of #68952 - faern:stabilize-assoc-int-consts, r=dtolnay
Stabilize assoc_int_consts associated int/float constants
The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325.
* Stabilize all constants under the `assoc_int_consts` feature flag.
* Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred.
* Update documentation examples to use new constants.
* Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway.
bors [Tue, 3 Mar 2020 23:26:38 +0000 (23:26 +0000)]
Auto merge of #69678 - Dylan-DPC:rollup-yoaueud, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #69565 (miri engine: turn some debug_assert into assert)
- #69621 (use question mark operator in a few places.)
- #69650 (cleanup more iterator usages (and other things))
- #69653 (use conditions directly)
- #69665 (Invoke OptimizerLastEPCallbacks in PreLinkThinLTO)
- #69670 (Add explanation for E0379)
Dylan DPC [Tue, 3 Mar 2020 20:26:16 +0000 (21:26 +0100)]
Rollup merge of #69665 - tmiasko:new-pass-manager-thin-lto-opt, r=nikic
Invoke OptimizerLastEPCallbacks in PreLinkThinLTO
The default ThinLTO pre-link pipeline does not include optimizer last
extension points. Thus, when using the new LLVM pass manager & ThinLTO
& sanitizers on any opt-level different from zero, the sanitizer
function passes would be omitted from the pipeline.
Add optimizer last extensions points manually to the pipeline, but guard
registration with stage check in the case this behaviour changes in the
future.
Dylan DPC [Tue, 3 Mar 2020 20:26:13 +0000 (21:26 +0100)]
Rollup merge of #69650 - matthiaskrgr:clnp, r=varkor
cleanup more iterator usages (and other things)
* Improve weird formatting by moving comment inside else-code block.
* Use .any(x) instead of .find(x).is_some() on iterators.
* Use .nth(x) instead of .skip(x).next() on iterators.
* Simplify conditions like x + 1 <= y to x < y
* Use let instead of match to get value of enum with single variant.
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
Tomasz Miąsko [Tue, 3 Mar 2020 00:00:00 +0000 (00:00 +0000)]
Add test for -Znew-llvm-pass-manager -Clto=thin -Zsanitizer=...
Additionally verify that the current implementation of LLVM version
check (which uses lexicographic ordering) is good enough to exclude
versions before LLVM 9, where the new LLVM pass manager is unsupported.
Tomasz Miąsko [Tue, 3 Mar 2020 00:00:00 +0000 (00:00 +0000)]
Invoke OptimizerLastEPCallbacks in PreLinkThinLTO
The default ThinLTO pre-link pipeline does not include optimizer last
extension points. Thus, when using the new LLVM pass manager & ThinLTO
& sanitizers on any opt-level different from zero, the sanitizer
function passes would be omitted from the pipeline.
Add optimizer last extensions points manually to the pipeline, but guard
registration with stage check in the case this behaviour changes in the
future.
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.
projects / rust.git / log