Rollup merge of #67026 - Nadrieril:improve-usefulness-empty, r=varkor,Centril,estebank
Improve diagnostics and code for exhaustiveness of empty matches
There was a completely separate check and diagnostics for the case of an empty match. This led to slightly different error messages and duplicated code.
This improves code reuse and generally clarifies what happens for empty matches. This also clarifies the action of the `exhaustive_patterns` feature, and ensures that this feature doesn't change diagnostics in places it doesn't need to.
Dylan MacKenzie [Wed, 11 Dec 2019 18:09:10 +0000 (10:09 -0800)]
Look for "unstable feature" error code in test
Conditionals and loops now have unstable features, and `feature_err` has
its own error code. I think that `feature_err` should take an error code
as a parameter, but don't have the energy to make this change throughout
the codebase. Also, the error code system may be torn out entirely.
bors [Fri, 13 Dec 2019 03:22:20 +0000 (03:22 +0000)]
Auto merge of #67271 - Centril:rollup-i71iqkv, r=Centril
Rollup of 6 pull requests
Successful merges:
- #66341 (Match `VecDeque::extend` to `Vec::extend_desugared`)
- #67243 (LinkedList: drop remaining items when drop panics)
- #67247 (Don't suggest wrong snippet in closure)
- #67250 (Remove the `DelimSpan` from `NamedMatch::MatchedSeq`.)
- #67251 (Require `allow_internal_unstable` for stable min_const_fn using unsta…)
- #67269 (parser: recover on `&'lifetime mut? $pat`.)
Rollup merge of #67250 - nnethercote:rm-DelimSpan-from-NamedMatch-MatchedSeq, r=Centril
Remove the `DelimSpan` from `NamedMatch::MatchedSeq`.
Because it's unused. This then allows the removal of
`MatcherPos::sp_open`. It's a tiny perf win, reducing instruction counts
by 0.1% - 0.2% on a few benchmarks.
Rollup merge of #66341 - crgl:vec-deque-extend, r=Amanieu
Match `VecDeque::extend` to `Vec::extend_desugared`
Currently, `VecDeque::extend` [does not reserve at all](https://github.com/rust-lang/rust/pull/65069#discussion_r333166522). This implementation still runs a check every iteration of the loop, but should reallocate at most once for the common cases where the `size_hint` lower bound is exact. Further optimizations in the future could improve this for some common cases, but given the complexity of the `Vec::extend` implementation it's not immediately clear that this would be worthwhile.
Alex Crichton [Fri, 13 Dec 2019 00:47:42 +0000 (16:47 -0800)]
std: Implement `LineWriter::write_vectored`
This commit implements the `write_vectored` method of the `LineWriter`
type. First discovered in bytecodealliance/wasmtime#629 the
`write_vectored` method of `Stdout` bottoms out here but only ends up
writing the first buffer due to the default implementation of
`write_vectored`.
Like `BufWriter`, however, `LineWriter` can have a non-default
implementation of `write_vectored` which tries to preserve the
vectored-ness as much as possible. Namely we can have a vectored write
for everything before the newline and everything after the newline if
all the stars align well.
Also like `BufWriter`, though, special care is taken to ensure that
whenever bytes are written we're sure to signal success since that
represents a "commit" of writing bytes.
In particular, it has bugged me for some time that `process_cycles` is
currently located before `mark_still_waiting_nodes` despite being called
afterwards.
`NodeState` has two states, `Success` and `Done`, that are only used
within `ObligationForest` methods. This commit removes them, and renames
the existing `Waiting` state as `Success`.
We are left with three states: `Pending`, `Success`, and `Error`.
`Success` is augmented with a new `WaitingState`, which indicates when
(if ever) it was last waiting on one or more `Pending` nodes. This
notion of "when" requires adding a "process generation" to
`ObligationForest`; it is incremented on each call to
`process_obligtions`.
This commit is a performance win.
- Most of the benefit comes from `mark_as_waiting` (which the commit
renames as `mark_still_waiting_nodes`). This function used to do two
things: (a) change all `Waiting` nodes to `Success`, and (b) mark all
nodes that depend on a pending node as `Waiting`. In practice, many
nodes went from `Waiting` to `Success` and then immediately back to
`Waiting`. The use of generations lets us skip step (a).
- A smaller benefit comes from not having to change nodes to the `Done`
state in `process_cycles`.
Aaron Hill [Thu, 12 Dec 2019 15:51:19 +0000 (10:51 -0500)]
Fix weird implicit dependency between rustllvm and rustc_codegen_llvm
rustllvm relies on the `LLVMRustStringWriteImpl` symbol existing, but
this symbol was previously defined in a *downstream* crate
(rustc_codegen_llvm, which depends on rustc_llvm.
While this somehow worked under the old 'separate bootstrap step for
codegen' scheme, it meant that rustc_llvm could not actually be built by
itself, since it relied linking to the downstream rustc_codegen_llvm
crate.
Now that librustc_codegen_llvm is just a normal crate, we actually try
to build a standalone rustc_llvm when we run tests. This commit moves
`LLVMRustStringWriteImpl` into rustc_llvm (technically the rustllvm
directory, which has its contents built by rustc_llvm). This ensures
that we can build each crate in the graph by itself, without requiring
that any downstream crates be linked in as well.
Remove the `DelimSpan` from `NamedMatch::MatchedSeq`.
Because it's unused. This then allows the removal of
`MatcherPos::sp_open`. It's a tiny perf win, reducing instruction counts
by 0.1% - 0.2% on a few benchmarks.
Similarly to https://github.com/rust-lang/rust/pull/67106 this was an issue with visitor discipline.
Impl items were visited as a part of visiting `ast::ItemKind::Impl`, but they should be visit-able in isolation from their parents as well, because that's how they are visited when they are expanded from macros.
I've checked that all the remaining `resolve_visibility` calls are used correctly.
Yuki Okushi [Thu, 12 Dec 2019 01:09:21 +0000 (10:09 +0900)]
Rollup merge of #67215 - nnethercote:fix-Zprint-type-size-zero-sized-fields, r=pnkfelix
Fix `-Z print-type-sizes`'s handling of zero-sized fields.
Currently, the type `struct S { x: u32, y: u32, tag: () }` is
incorrectly described like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size field `.x`: 4 bytes
print-type-size field `.tag`: 0 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size padding: 4 bytes
print-type-size field `.y`: 4 bytes, alignment: 4 bytes
```
Specifically:
- The `padding` line is wrong. (There is no padding.)
- The `offset` and `alignment` on the `.tag` line shouldn't be printed.
The problem is that multiple fields can end up with the same offset, and
the printing code doesn't handle this correctly.
This commit fixes it by adjusting the field sorting so that zero-sized fields
are dealt with before non-zero-sized fields. With that in place, the
printing code works correctly.
The commit also corrects the "something is very wrong" comment.
The new output looks like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size field `.tag`: 0 bytes
print-type-size field `.x`: 4 bytes
print-type-size field `.y`: 4 bytes
```
r? @pnkfelix
Yuki Okushi [Thu, 12 Dec 2019 01:09:19 +0000 (10:09 +0900)]
Rollup merge of #66983 - weiznich:bugfix/issue_66295, r=estebank
Fix `unused_parens` triggers on macro by example code
Fix #66295
Unfortunately this does also break [an existing test](https://github.com/rust-lang/rust/blob/4787e97475de6be9487e3d9255a9c2d3c0bf9252/src/test/ui/lint/issue-47775-nested-macro-unnecessary-parens-arg.rs#L22). I'm not sure how to handle that, because that seems to be quite similar to the allowed cases
If this gets accepted it would be great to backport this fix to beta.
Yuki Okushi [Thu, 12 Dec 2019 01:09:15 +0000 (10:09 +0900)]
Rollup merge of #62514 - stephaneyfx:box-ffi, r=nikomatsakis
Clarify `Box<T>` representation and its use in FFI
This officializes what was only shown as a code example in [the unsafe code guidelines](https://rust-lang.github.io/unsafe-code-guidelines/layout/function-pointers.html?highlight=box#use) and follows [the discussion](https://github.com/rust-lang/unsafe-code-guidelines/issues/157) in the corresponding repository.
It is also related to [the issue](https://github.com/rust-lang/rust/issues/52976) regarding marking `Box<T>` `#[repr(transparent)]`.
If the statement this PR adds is incorrect or a more in-depth discussion is warranted, I apologize. Should it be the case, the example in the unsafe code guidelines should be amended and some document should make it clear that it is not sound/supported.
bors [Wed, 11 Dec 2019 23:00:38 +0000 (23:00 +0000)]
Auto merge of #66650 - matthewjasper:nonuniform-array-move, r=pnkfelix
Remove uniform array move MIR passes
This PR fixes a number of bugs caused by limitations of this pass
* Projections from constant indexes weren't being canonicalized
* Constant indexes from the start weren't being canonicalized (they could have different min_lengths)
* It didn't apply to non-moves
This PR makes the following changes to support removing this pass:
* ConstantIndex of arrays are now generated in a canonical form (from the start, min_length is the actual length).
* Subslices are now split when generating move paths and when checking subslices have been moved.
Additionally
* The parent move path of a projection from an array element is now calculated correctly
Andrea Canciani [Wed, 11 Dec 2019 20:24:35 +0000 (21:24 +0100)]
Improve `str` prefix/suffix comparison
The comparison can be performed on the raw bytes, as the chars can
only match if their UTF8 encoding matches.
This avoids the `is_char_boundary` checks and translates to a straight
`u8` slice comparison which is optimized to a memcmp or inline
comparison where appropriate.