Rollup of 7 pull requests
Successful merges:
- #67026 (Improve diagnostics and code for exhaustiveness of empty matches)
- #67235 (VecDeque: drop remaining items on destructor panic)
- #67254 (dont ICE in case of invalid drop fn)
- #67256 (Reduce allocs for validation errors)
- #67274 (be explicit that mem::uninitialized is the same as MaybeUninit::uninit().assume_init())
- #67278 (`coerce_inner`: use initial `expected_ty`)
- #67280 (docs: std::convert::From: Fix typo)
Failed merges:
r? @ghost
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.
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.
r? @Centril
LinkedList: drop remaining items when drop panics
https://github.com/rust-lang/rust/pull/67235, but for `LinkedList`, which has the same issue.
I've also copied over the other drop-related tests from `VecDeque` since AFAICT `LinkedList` didn't have any.
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.
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`.
Bootstrap: change logic for choosing linker and rpath
This is a follow-up from #66957 and #67023. Apparently there was one more location with a hard-coded list of targets to influence linking.
I've filed #67171 to track this madness.
r? @alexcrichton
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 borrow check::nll submodule
NLL is the only borrow checker now, so no need to have a separate submodule.
@rustbot modify labels: +S-blocked
Waiting on #66815
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.
Make TinyList::remove iterate instead of recurse
Most of the diff is from from rustfmt, the actual change is in line 91..79 (or 79..89 in the "after" diff).
I had converted the other methods to iterate instead of recurse already, so this is the last recursive function on `TinyList`.
resolve: Always resolve visibilities on impl items
Fixes https://github.com/rust-lang/rust/issues/64705.
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.
r? @matthewjasper
