Currently, we emit a "try adding a comma" suggestion if a comma is
missing in a struct definition. However, we emit no such suggestion if a
comma is missing in a struct initializer.
This commit adds a "try adding a comma" suggestion when we don't find a
comma during the parsing of a struct initializer field.
The change to `src/test/ui/parser/removed-syntax-with-1.stderr` isn't
great, but I don't see a good way of avoiding it.
Fix extra subslice lowering
We are currently ICEing on e.g.
```rust
fn main() {
let [.., b @ ..] = [1, 2];
b;
}
```
This happens because `b @ ..` registers a binding such that `b;` is OK, but then we forget to lower that binding in `rustc_ast_lowering`.
Fixes#69103.
r? @davidtwco
typeck: clarify def_bm adjustments & add tests for or-patterns
Clarify the adjustment algorithm for the expected type / default binding-modes when type checking patterns with more documentation and tweaks that make the algorithm more independent of the pattern forms.
Also resolve the FIXME noted for or-patterns by deciding that the current implementation is correct, noting the rationale and adding tests for the current implementation.
cc https://github.com/rust-lang/rust/issues/54883
r? @oli-obk @varkor
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
