When the panic handler is run, the existing Handler may be in a weird
state if it was responsible for triggering the panic. By using a freshly
created Handler, we avoid trying to re-entrantly lock a HandlerInner,
which was causing a double panic on ICEs.
Rename `subst::Kind` to `subst::GenericArg`
And `subst::UnpackedKind` to `subst::GenericArgKind`. Individual variable names (e.g. `kind`) are not renamed, which would be an infeasible mission.
Fixes https://github.com/rust-lang/rust/issues/64352.
r? @eddyb
reserve `impl<T> From<!> for T`
this is necessary for never-type stabilization.
cc #57012#35121
I think we wanted a crater run for this @nikomatsakis?
r? @nikomatsakis
Update cargo
4 commits in aa6b7e01abce30091cc594cb23a15c46cead6e24..ab6fa8908c9b6c8f7e2249231c395eebfbc49891
2019-09-24 17:19:12 +0000 to 2019-09-25 17:00:56 +0000
- Fix macOS collection of CPU data (rust-lang/cargo#7429)
- Don't ever capture CPU state if timings are disabled (rust-lang/cargo#7428)
- Change build-std to use --sysroot (rust-lang/cargo#7421)
- set -Zmtime_on_use from config or ENV (rust-lang/cargo#7411)
4 commits in aa6b7e01abce30091cc594cb23a15c46cead6e24..ab6fa8908c9b6c8f7e2249231c395eebfbc49891
2019-09-24 17:19:12 +0000 to 2019-09-25 17:00:56 +0000
- Fix macOS collection of CPU data (rust-lang/cargo#7429)
- Don't ever capture CPU state if timings are disabled (rust-lang/cargo#7428)
- Change build-std to use --sysroot (rust-lang/cargo#7421)
- set -Zmtime_on_use from config or ENV (rust-lang/cargo#7411)
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 )
Failed merges:
r? @ghost
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
use `sign` variable in abs and wrapping_abs methods
This also makes the code easier to understand by hinting at the significance of `self >> ($BITS - 1)`.
Also, now `overflowing_abs` simply uses `wrapping_abs`, which is clearer and avoids a potential performance regression in the LLVM IR.
This PR follows from the discussion from #63786.
r? @eddyb
cc @nikic
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)
Any suggestions how to kill these off?
r? @Zoxc
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.
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.
Fix#64084.
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!`.
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...
Closes#64319
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.)
Failed merges:
r? @ghost
