Rollup of 8 pull requests
Successful merges:
- #67585 (Improve `char::is_ascii_*` codegen)
- #68914 (Speed up `SipHasher128`.)
- #68994 (rustbuild: include channel in sanitizers installed name)
- #69032 (ICE in nightly-2020-02-08: handle TerminatorKind::Yield in librustc_mir::transform::promote_consts::Validator method)
- #69034 (parser: Remove `Parser::prev_token_kind`)
- #69042 (Remove backtrace header text)
- #69059 (Remove a few unused objects)
- #69089 (Properly use the darwin archive format on Apple targets)
Failed merges:
r? @ghost
ICE in nightly-2020-02-08: handle TerminatorKind::Yield in librustc_mir::transform::promote_consts::Validator method
IR: https://github.com/rust-lang/rust/issues/69017
regressed commit: f8fd462447
Source: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=55e65a869e1f5fef64cc4462b1a5a087
Addresses ICE reported in #69017 by handling `TerminatorKind::Yield` in 4d1241f515/src/librustc_mir/transform/promote_consts.rs (L465-L468).
<details><summary>Nightly build</summary>
<p>
```
$ cargo +nightly build
Compiling yielder v0.1.0 (/Users/chris/Desktop/tests/rustlang-tests/yielder)
error: internal compiler error: src/librustc_mir/transform/promote_consts.rs:467: _1 = suspend(move _21) -> [resume: bb2, drop: bb3] not promotable
--> src/main.rs:8:27
|
8 | println!("-> {}", yield);
| ^^^^^
thread 'rustc' panicked at 'Box<Any>', <::std::macros::panic macros>:2:4
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.43.0-nightly (71c7e149e 2020-02-09) running on x86_64-apple-darwin
note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin
note: some of the compiler flags provided by cargo are hidden
error: aborting due to previous error
error: could not compile `yielder`.
To learn more, run the command again with --verbose.
```
</p>
</details>
<details><summary>Stage 1 dev build</summary>
<p>
```
$ cargo +stage1 build
Compiling yielder v0.1.0 (/Users/chris/Desktop/tests/rustlang-tests/yielder)
warning: function is never used: `gen`
--> src/main.rs:6:4
|
6 | fn gen() -> impl Generator<usize> {
| ^^^
|
= note: `#[warn(dead_code)]` on by default
Finished dev [unoptimized + debuginfo] target(s) in 0.53s
```
</p>
</details>
@jonas-schievink @oli-obk
Migrate borrowck dataflow impls to new framework
This uses #65672 to implement the dataflow analyses needed by borrowck. These include all the `InitializedPlaces` analyses as well as `Borrows`. Additionally, this PR contains several independent changes around the dataflow API which improve performance and make it more ergonomic.
* An optimization that inhibits the caching of block transfer functions for acyclic MIR (~0.3% I-CNT savings).
* A `ResultsVisitor` for dataflow results that is more efficient than `ResultsCursor` when we have to visit every statement unconditionally (~0.3% I-CNT savings).
* An `into_engine` method on `Analysis` that selects the appropriate `Engine` constructor.
* A `contains` method for `ResultsCursor` as a shorthand for `.get().contains()`.
* A `find_descendants` helper on `MovePath` that replaces `has_any_child_of` on the old `FlowsAtLocation`
These changes made porting the dataflow analyses much easier. Finally, this PR removes some now-unused code in `dataflow/at_location.rs` and elsewhere.
You can view the perf results for the final version of this PR [here](https://perf.rust-lang.org/compare.html?start=29b854fb741809c29764e33fc17c32ba9c6523ba&end=6e516c1410c18cfe4eb6d030a39fdb73c8d8a4fe). Here's an example of the graphviz diagrams that are generated for the `MaybeInitializedPlaces` analysis.
Remove common usage pattern from `AllocRef`
This removes the common usage patterns from `AllocRef`:
- `alloc_one`
- `dealloc_one`
- `alloc_array`
- `realloc_array`
- `dealloc_array`
Actually, they add nothing to `AllocRef` except a [convenience wrapper around `Layout` and other methods in this trait](https://doc.rust-lang.org/1.41.0/src/core/alloc.rs.html#1076-1240) but have a major flaw: The documentation of `AllocRefs` notes, that
> some higher-level allocation methods (`alloc_one`, `alloc_array`) are well-defined on zero-sized types and can optionally support them: it is left up to the implementor whether to return `Err`, or to return `Ok` with some pointer.
With the current API, `GlobalAlloc` does not have those methods, so they cannot be overridden for `liballoc::Global`, which means that even if the global allocator would support zero-sized allocations, `alloc_one`, `alloc_array`, and `realloc_array` for `liballoc::Global` will error, while calling `alloc` with a zeroed-size `Layout` could succeed. Even worse: allocating with `alloc` and deallocating with `dealloc_{one,array}` could end up with not calling `dealloc` at all!
For the full discussion please see https://github.com/rust-lang/wg-allocators/issues/18
r? @Amanieu
Test failure of unchecked arithmetic intrinsics in const eval
Test that the unchecked arithmetic intrinsics that were made unstably const in #68809 emit an error during const-eval if given invalid input.
Addresses [this comment](https://github.com/rust-lang/rust/pull/68809#discussion_r375753066).
r? @RalfJung
Use `dyn Trait` more in tests
Here are some tests using the old trait object type syntax which are not testing the syntax itself.
This has been extracted from https://github.com/rust-lang/rust/pull/66364.
Remove unused feature gates
I think many of the remaining unstable things can be easily be replaced with stable things. I have kept the `#![feature(nll)]` even though it is only necessary in `libstd`, to make regressions of it harder.
Invert control in struct_lint_level.
Closes#67927
Changes the `struct_lint*` methods to take a `decorate` function instead of a message string. This decorate function is also responsible for eventually stashing, emitting or cancelling the diagnostic. If the lint was allowed after all, the decorate function is not run at all, saving us from spending time formatting messages (and potentially other expensive work) for lints that don't end up being emitted.
r? @Centril
rustc_codegen_ssa: only "spill" SSA-like values to the stack for debuginfo.
This is an implementation of the idea described in https://github.com/rust-lang/rust/issues/68817#issuecomment-583719182.
In short, instead of debuginfo forcing otherwise-SSA-like MIR locals into `alloca`s, and requiring a `load` for each use (or two, for scalar pairs), the `alloca` is now *only* used for attaching debuginfo with `llvm.dbg.declare`: the `OperandRef` is stored to the `alloca`, but *never loaded* from it.
Outside of `debug_introduce_local`, nothing cares about the debuginfo-only `alloca`, and instead works with `OperandRef` the same as MIR locals without debuginfo before this PR.
This should have some of the benefits of `llvm.dbg.value`, while working today.
cc @nagisa @nikomatsakis
change an instance of span_bug() to struct_span_err() to avoid ICE
After #67148, the `span_bug()` in `parse_ty_tuple_or_parens()` is reachable because `parse_paren_comma_seq()` can return an `Ok()` even in cases where it encounters an error.
This pull request prevents an ICE in such cases by replacing the `span_bug()` with `struct_span_error()`.
Fixes#68890.
Add long error code explanation message for E0637
Reference issue [#61137](https://github.com/rust-lang/rust/issues/61137)
To incorporate a long error description for E0637, I have made the necessary modification to error_codes.rs and added error_codes/E0637.md, and blessed the relevant .stderror files. ~~, however when I build rustc stage 1, I am unable to make `$ rustc --explain E0637` work even though rustc appears to be able to call up the long error explanations for other errors. I wanted to guarantee this would work before moving on the blessing the various ui tests that have been affected. @GuillaumeGomez Do you know the most likely reason(s) why this would be the case?~~
Update: `$ rustc --explain E0637` works now.
Remove problematic specialization from RangeInclusive
Fixes#67194 using the approach [outlined by Mark-Simulacrum](https://github.com/rust-lang/rust/issues/67194#issuecomment-581669549).
> I believe the property we want is that if `PartialEq(&self, &other) == true`, then `self.next() == other.next()`. It is true that this is satisfied by removing the specialization and always doing `is_empty.unwrap_or_default()`; the "wrong" behavior there arises from calling `next()` having an effect on initially empty ranges, as we should be in `is_empty = true` but are not (yet) there. It might be possible to detect that the current state is always empty (i.e., `start > end`) and then not fill in the empty slot. I think this might solve the problem without regressing tests; however, this could have performance implications.
> That approach essentially states that we only use the `is_empty` slot for cases where `start <= end`. That means that `Idx: !Step` and `start > end` would both behave the same, and correctly -- we do not need the boolean if we're not ever going to emit any values from the iterator.
This is implemented here by replacing the `is_empty: Option<bool>` slot with an `exhausted: bool` slot. This flag is
- `false` upon construction,
- `false` when iteration has not yielded an element -- importantly, this means it is always `false` for an iterator empty by construction,
- `false` when iteration has yielded an element and the iterator is not exhausted, and
- only `true` when iteration has been used to exhaust the iterator.
For completeness, this also adds a note to the `Debug` representation to note when the range is exhausted.
Rollup of 6 pull requests
Successful merges:
- #68694 (Reduce the number of `RefCell`s in `InferCtxt`.)
- #68966 (Improve performance of coherence checks)
- #68976 (Make `num::NonZeroX::new` an unstable `const fn`)
- #68992 (Correctly parse `mut a @ b`)
- #69005 (Small graphviz improvements for the new dataflow framework)
- #69006 (parser: Keep current and previous tokens precisely)
Failed merges:
r? @ghost
parser: Keep current and previous tokens precisely
...including their unnormalized forms.
Add more documentation for them.
Hopefully, this will help to eliminate footguns like https://github.com/rust-lang/rust/pull/68728#discussion_r373787486.
I'll try to address the FIXMEs in separate PRs during the next week.
r? @Centril
Make `num::NonZeroX::new` an unstable `const fn`
cc #53718
These require `#[feature(const_if_match)]`, meaning they must remain unstable for the time being.
This has negligible perf impact, but it does improve the code a bit.
* Only query the specialization graph of any trait once instead of once per
impl
* Loop over impls only once, precomputing impl DefId and TraitRef
Improve reporting errors and suggestions for trait bounds
Fix#66802
- When printing errors for unsized function parameter, properly point at the parameter instead of function's body.
- Improve `consider further restricting this bound` (and related) messages by separating human-oriented hints from the machine-oriented ones.
When suggesting associated fn with type parameters, include in the structured suggestion
Address #50734.
```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
--> file.rs:14:1
|
14 | impl TraitA<()> for S {
| ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
|
= help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
= help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
= help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```
It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.
