Suggestion when encountering assoc types from hrtb
When encountering E0212, detect whether this is a representable case or
not, i.e. if it's happening on an `fn` or on an ADT. If the former,
provide a structured suggestion, otherwise note that this can't be
represented in Rust.
Fix#69000.
Properly use parent generics for opaque types
Fixes#67844
Previously, opaque types would only get parent generics if they
a return-position-impl-trait (e.g. `fn foo<A>() -> impl MyTrait<A>`).
However, it's possible for opaque types to be nested inside one another:
```rust
trait WithAssoc { type AssocType; }
trait WithParam<A> {}
type Return<A> = impl WithAssoc<AssocType = impl WithParam<A>>;
```
When this occurs, we need to ensure that the nested opaque types
properly inherit generic parameters from their parent opaque type.
This commit fixes the `generics_of` query to take the parent item
into account when determining the generics for an opaque type.
miri: improve and simplify overflow detection
This simplifies the overflow detection for signed binary operators, and adds overflow detection to unary operators so that const-prop doesn't have to crudely hand-roll that.
It also fixes some bugs in the operator implementation that however, I think, were not observable.
r? @oli-obk @wesleywiser
Account for type params on method without parentheses
Account for those type parameters in the structured suggestion when forgetting to call method:
```
error[E0615]: attempted to take value of method `collect` on type `std::vec::IntoIter<_>`
--> $DIR/method-missing-parentheses.rs:2:32
|
LL | let _ = vec![].into_iter().collect::<usize>;
| ^^^^^^^---------
| |
| help: use parentheses to call the method: `collect::<usize>()`
```
Support new LLVM pass manager
Add support for the new LLVM pass manager behind a `-Z new-llvm-pass-manager=on` option. Both the pre-link optimization and LTO pipelines use the new pass manager. There's some bits that are not supported yet:
* `-C passes`. NewPM requires an entirely different way of specifying custom pass pipelines. We should probably expose that functionality, but it doesn't directly map to what `-C passes` does.
* NewPM has no support for custom inline parameters right now. We'd have to add upstream support for that first.
* NewPM does not support PGO at O0 in LLVM 9 (which is why those tests fail with NewPM enabled). This is supported in LLVM 10.
* NewPM does not support MergeFunctions in LLVM 9. I've landed this upstream just before the cut, so we'll be able to re-enable that with LLVM 10.
Closes#64289.
r? @ghost
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
When encountering E0212, detect whether this is a representable case or
not, i.e. if it's happening on an `fn` or on an ADT. If the former,
provide a structured suggestion, otherwise note that this can't be
represented in Rust.
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.
