Auto merge of #64766 - Centril:rollup-gdy5jr6, r=Centril
Rollup of 6 pull requests
Successful merges:
- #62975 (Almost fully deprecate hir::map::Map.hir_to_node_id)
- #64386 (use `sign` variable in abs and wrapping_abs methods)
- #64508 (or-patterns: Push `PatKind/PatternKind::Or` at top level to HIR & HAIR)
- #64738 (Add const-eval support for SIMD types, insert, and extract)
- #64759 (Refactor mbe a tiny bit)
- #64764 (Master is now 1.40 )
Rollup merge of #64508 - Centril:or-pat-hir, r=matthewjasper
or-patterns: Push `PatKind/PatternKind::Or` at top level to HIR & HAIR
Following up on work in https://github.com/rust-lang/rust/pull/64111, https://github.com/rust-lang/rust/pull/63693, and https://github.com/rust-lang/rust/pull/61708, in this PR:
- We change `hair::Arm.patterns: Vec<Pattern<'_>>` into `hir::Arm.pattern: Pattern<'_>`.
- `fn hair::Arm::top_pats_hack` is introduced as a temporary crutch in MIR building to avoid more changes.
- We change `hir::Arm.pats: HirVec<P<Pat>>` into `hir::Arm.pat: P<Pat>`.
- The hacks in `rustc::hir::lowering` are removed since the representation hack is no longer necessary.
- In some places, `fn hir::Arm::top_pats_hack` is introduced to leave some things as future work.
- Misc changes: HIR pretty printing is adjusted to behave uniformly wrt. top/inner levels, rvalue promotion is adjusted, regionck, and dead_code is also.
- Type checking is adjusted to uniformly handle or-patterns at top/inner levels.
To make things compile, `p_0 | ... | p_n` is redefined as a "reference pattern" in [`fn is_non_ref_pat`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.is_non_ref_pat) for now. This is done so that reference types are not eagerly stripped from the `expected: Ty<'tcx>`.
- Liveness is adjusted wrt. the `unused_variables` and `unused_assignments` lints to handle top/inner levels uniformly and the handling of `fn` parameters, `let` locals, and `match` arms are unified in this respect. This is not tested for now as exhaustiveness checks are reachable and will ICE.
- In `check_match`, checking `@` and by-move bindings is adjusted. However, exhaustiveness checking is not adjusted the moment and is handled by @dlrobertson in https://github.com/rust-lang/rust/pull/63688.
- AST borrowck (`construct.rs`) is not adjusted as AST borrowck will be removed soon.
r? @matthewjasper
cc @dlrobertson @varkor @oli-obk
Rollup merge of #62975 - ljedrz:kill_off_hir_to_node_id, r=Zoxc
Almost fully deprecate hir::map::Map.hir_to_node_id
- HirIdify `doctree::Module.id`
- HirIdify `hir::Crate.modules`
- introduce a `HirId` to `DefIndex` map in `map::Definitions`
The only last uses of `hir::map::Map.hir_to_node_id` in the compiler are:
- for the purposes of `driver::pretty` (in `map::nodes_matching_suffix`), but I don't know if we can remove `NodeId`s in there (I think when I attempted it previously there was some issue due to `HirId` not being representable with an integer)
- in `ty::query::on_disk_cache` (not sure about the purpose of this one)
- in `mir::transform::check_unsafety` (only important for error message order)
Auto merge of #64663 - jakoschiko:report-time, r=alexcrichton
libtest: Add --report-time flag to print test execution time
Implements the flag `--report-time` to print the execution time of each executed (successful or failed) test.
Closes #46610
# Example
`cargo test -- --report-time` produces the following output to stdout:
```
running 6 tests
test tests::ignore ... ignored
test tests::noop ... ok 0.000s
test tests::should_panic ... ok 0.000s
test tests::panic_after_10millis ... FAILED 0.010s
test tests::sleep_100millis ... ok 0.100s
test tests::sleep_10secs ... ok 10.001s
failures:
---- tests::panic_after_10millis stdout ----
thread 'tests::panic_after_10millis' panicked at 'foo', src\lib.rs:31:9
Rollup merge of #64753 - ehuss:json-short-explain, r=Mark-Simulacrum
Don't emit explain with json short messages.
This fixes an issue where `--error-format=json --json=diagnostic-short` would emit the "For more information about this error" message, which doesn't match the behavior of `--error-format=short` which explicitly excludes it.
Rollup merge of #64746 - estebank:elide-impl-trait-obligations-on-err, r=cramertj
Remove blanket silencing of "type annotation needed" errors
Remove blanket check for existence of other errors before emitting "type annotation needed" errors, and add some eager checks to avoid adding obligations when they refer to types that reference `[type error]` in order to reduce unneeded errors.
Rollup merge of #64743 - alexcrichton:update-cargo, r=nikomatsakis
Update cargo
11 commits in b6c6f685b38d523580813b0031677c2298f458ea..aa6b7e01abce30091cc594cb23a15c46cead6e24
2019-09-19 21:10:09 +0000 to 2019-09-24 17:19:12 +0000
- Fix interpretation of `--features a b` on the CLI (rust-lang/cargo#7419)
- Update env_logger requirement from 0.6.0 to 0.7.0 (rust-lang/cargo#7422)
- Update some unstable docs (rust-lang/cargo#7407)
- Fix xcompile tests. (rust-lang/cargo#7408)
- -Ztimings: Fix more scale problems. (rust-lang/cargo#7403)
- Fix some rendering issues with -Ztimings. (rust-lang/cargo#7397)
- -Ztimings: show max jobs/cpus (rust-lang/cargo#7398)
- Fix -Ztimings with doc tests. (rust-lang/cargo#7395)
- Add documentation for the -Zdoctest-xcompile feature (rust-lang/cargo#7391)
- Fix integration tests waiting for binaries to finish. (rust-lang/cargo#7394)
- Extract Platform to a separate crate. (rust-lang/cargo#7375)
Rollup merge of #64481 - tomtau:fix/tls-error-message, r=KodrAus
A more explanatory thread local storage panic message
Outside rust-std internals, TLS is usually understood as Transport Layer Security, so the existing message could be a bit puzzling when one has TLS sessions in `thread_local!`.
Rollup merge of #64324 - alexcrichton:share-generics-again, r=michaelwoerister
rustc: Fix mixing crates with different `share_generics`
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...
Auto merge of #64751 - Centril:rollup-hpbmcfj, r=Centril
Rollup of 16 pull requests
Successful merges:
- #63356 (Issue#63183: Add fs::read_dir() and ReadDir warning about iterator order + example)
- #63934 (Fix coherence checking for impl trait in type aliases)
- #64016 (Streamline `Compiler`)
- #64296 (Document the unstable iter_order_by library feature)
- #64443 (rustdoc: general cleanup)
- #64622 (Add a cycle detector for generic `Graph`s and `mir::Body`s)
- #64689 (Refactor macro by example)
- #64698 (Recover on `const X = 42;` and infer type + Error Stash API)
- #64702 (Remove unused dependencies)
- #64717 (update mem::discriminant test to use assert_eq and assert_ne over comparison operators)
- #64720 ( remove rtp.rs, and move rtpSpawn and RTP_ID_ERROR to libc)
- #64721 (Fixed issue from #64447)
- #64725 (fix one typo)
- #64737 (fix several issues in String docs)
- #64742 (relnotes: make compatibility section more sterile and fix rustc version)
- #64748 (Fix #64744. Account for the Zero sub-pattern case.)
Rollup merge of #64737 - jordins:master, r=steveklabnik
fix several issues in String docs
- In some places &str was shown instead of String.
- into_bytes is the reverse of from_utf8
Fixes #63797
I've retaken the work done in this PR: https://github.com/rust-lang/rust/pull/63865 which for some reason was closed.
and just done a minor change (I hope you don't mind @sam09 ).
Rollup merge of #64721 - hman523:issue64447, r=estebank
Fixed issue from #64447
Did two tiny fixes. One is a micro optimization since we know that max is going to be assigned a `usize`, we do not have to worry about a possible negative number.
The other issue that was fixed is that the max from the children isn't updated correctly. Now it will use `sub_result` instead of `primary` and will properly get the needed value.
Rollup merge of #64698 - Centril:infer-const-with-stash, r=estebank
Recover on `const X = 42;` and infer type + Error Stash API
Here we:
1. Introduce a notion of the "error stash".
This is a map in the `Handler` to which you can `err.stash(...)` away your diagnostics and then steal them in a later "phase" of the compiler (e.g. stash in parser, steal in typeck) to enrich them with more information that isn't available in the previous "phase".
I believe I've covered all the bases to make sure these diagnostics are actually emitted eventually even under `#[cfg(FALSE)]` but please check my logic.
2. Recover when parsing `[const | static mut?] $ident = $expr;` which has a missing type.
Use the "error stash" to stash away the error and later steal the error in typeck where we emit the error as `MachineApplicable` with the actual inferred type. This builds on https://github.com/rust-lang/rust/pull/62804.
Rollup merge of #64622 - ecstatic-morse:cycle-detector, r=oli-obk
Add a cycle detector for generic `Graph`s and `mir::Body`s
Cycle detection is one way to differentiate the upcoming `const_loop` feature flag (#52000) from the `const_if_match` one (#49146). It would be possible to use the existing implementation of strongly-connected components for this but less efficient.
The ["tri-color" terminology](http://www.cs.cornell.edu/courses/cs2112/2012sp/lectures/lec24/lec24-12sp.html) is common in introductory data structures and algorithms courses: black nodes are settled, grey nodes are visited, and white nodes have no state. This particular implementation is iterative and uses a well-known technique where "node settled" events are kept on the stack alongside nodes to visit. When a settled event is popped, we know that all successors of that node have been visited and themselves settled. If we encounter a successor node that has been visited (is on the stack) but not yet settled, we have found a cycle.
Rollup merge of #63934 - Aaron1011:fix/impl-trait-coherence, r=nikomatsakis
Fix coherence checking for impl trait in type aliases
**UPDATE**: This PR now treats all opaque types as remote. The original description appears below, but is no longer accurate.
Fixes #63677
[RFC 2071](https://github.com/rust-lang/rfcs/pull/2071) (impl-trait-existential-types) does not explicitly state how `type_alias_impl_trait` should interact with coherence. However, there's only one choice which makes sense - coherence should look at the underlying type (i.e. the *"defining"* type of the `impl Trait`) of the type alias, just like we do for non-`impl Trait` type aliases.
Specifically, `impl Trait` type aliases that resolve to a local type should be treated like a local type with respect to coherence (e.g. `impl Trait` type aliases which resolve to a foreign type should be treated as a foreign type, and those that resolve to a local type should be treated as a local type).
Since neither inherent impls nor direct trait impl (i.e. `impl MyType` or `impl MyTrait for MyType`) are allowed for type aliases, this usually does not come up. Before we ever attempt to do coherence checking, we will have errored out if an `impl Trait` type alias was used directly in an `impl` clause.
However, during trait selection, we sometimes need to prove bounds like `T: Sized` for some type `T`. If `T` is an impl trait type alias, this requires to know the coherence behavior for `impl Trait` type aliases when we perform coherence checking.
Note: Since determining the underlying type of an `impl Trait` type alias requires us to perform body type checking, this commit causes us to type check some bodies easier than we otherwise would have. However, since this is done through a query, this shouldn't cause any problems
For completeness, I've added an additional test of the coherence-related behavior of `impl Trait` type aliases.
Remove blanket silencing of "type annotation needed" errors
Remove blanket check for existence of other errors before emitting
"type annotation needed" errors, and add some eager checks to avoid
adding obligations when they refer to types that reference
`[type error]` in order to reduce unneded errors.
Alex Crichton [Tue, 24 Sep 2019 18:06:56 +0000 (11:06 -0700)]
Update cargo
11 commits in b6c6f685b38d523580813b0031677c2298f458ea..aa6b7e01abce30091cc594cb23a15c46cead6e24
2019-09-19 21:10:09 +0000 to 2019-09-24 17:19:12 +0000
- Fix interpretation of `--features a b` on the CLI (rust-lang/cargo#7419)
- Update env_logger requirement from 0.6.0 to 0.7.0 (rust-lang/cargo#7422)
- Update some unstable docs (rust-lang/cargo#7407)
- Fix xcompile tests. (rust-lang/cargo#7408)
- -Ztimings: Fix more scale problems. (rust-lang/cargo#7403)
- Fix some rendering issues with -Ztimings. (rust-lang/cargo#7397)
- -Ztimings: show max jobs/cpus (rust-lang/cargo#7398)
- Fix -Ztimings with doc tests. (rust-lang/cargo#7395)
- Add documentation for the -Zdoctest-xcompile feature (rust-lang/cargo#7391)
- Fix integration tests waiting for binaries to finish. (rust-lang/cargo#7394)
- Extract Platform to a separate crate. (rust-lang/cargo#7375)
Aaron Hill [Tue, 27 Aug 2019 01:32:14 +0000 (21:32 -0400)]
Fix coherence checking for impl trait in type aliases
Fixes #63677
RFC #2071 (impl-trait-existential-types) does not explicitly state how
impl trait type alises should interact with coherence. However, there's
only one choice which makes sense - coherence should look at the
underlying type (i.e. the 'defining' type of the impl trait) of the type
alias, just like we do for non-impl-trait type aliases.
Specifically, impl trait type alises which resolve to a local type
should be treated like a local type with respect to coherence (e.g.
impl trait type aliases which resolve to a forieign type should be
treated as a foreign type, and those that resolve to a local type should
be treated as a local type).
Since neither inherent impls nor direct trait impl (i.e. `impl MyType`
or `impl MyTrait for MyType`) are allowd for type aliases, this
usually does not come up. Before we ever attempt to do coherence
checking, we will have errored out if an impl trait type alias was used
directly in an 'impl' clause.
However, during trait selection, we sometimes need to prove bounds like
'T: Sized' for some type 'T'. If 'T' is an impl trait type alias, this
requires to know the coherence behavior for impl trait type aliases when
we perform coherence checking.
Note: Since determining the underlying type of an impl trait type alias
requires us to perform body type checking, this commit causes us to type
check some bodies easlier than we otherwise would have. However, since
this is done through a query, this shouldn't cause any problems
For completeness, I've added an additional test of the coherence-related
behavior of impl trait type aliases.
Auto merge of #64316 - alexcrichton:cleanup-shim, r=Mark-Simulacrum
Delete most of `src/bootstrap/bin/rustc.rs`
This commit is an attempt at deleting as much of the `rustc.rs` shim that we have in rustbuild as possible. This shim predates `RUSTFLAGS` and is as old as rustbuild itself. While useful for quick hacks, it subverts Cargo's knowledge of `rustc`, makes it more difficult to build crates out of rustbuild, and is generally a hazard/code smell due to its architecture.
Additionally since the inception of this script we've added a number of features to Cargo such as profile overrides and `RUSTFLAGS`. This commit attempts to use these features of Cargo as much as possible to delete almost all of `src/bootstrap/bin/rustc.rs`. It's hoped that all new configuration for the Rust compiler can be codified in rustbuild rather than in this shim, allowing Cargo to have more knowledge about what's going on and making it a bit easier to reproduce builds outside of Cargo itself.
This was primarily motivated by some recent work on std-aware Cargo, and is also generally a cleanup of the script itself. This internally resulted in a number of refactorings of rustbuild itself, and the commits should be readable one-at-a-time instead of having to digest them all at once.
Alex Crichton [Wed, 11 Sep 2019 15:08:04 +0000 (08:08 -0700)]
rustc: Fix mixing crates with different `share_generics`
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...