Fixes#68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
Suggest a comma if a struct initializer field fails to parse
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.
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.
Infer regions for opaque types in borrowck
This is a step towards the goal of typeck not doing region inference.
The commits up to `Arena allocate the result of mir_borrowck` are various bug fixes and prerequisites.
The remaining commits move opaque type inference to borrow checking.
r? @nikomatsakis
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>()`
```
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
