Before, if we had a projection like `<T as Foo<'0>>::Bar: 'x` and a
where clause like `<T as Foo<'a>>::Bar: 'a`, we considered those to
have nothing to do with one another. Therefore, we would use the
"overconstrained" path of adding `T: 'x` and `'0: 'x` requirements. We
now do a "fuzzy" match where we erase regions first and hence we see
the env bound `'a`.
We used to apply it repeatedly as we went, relying on the current
value of the `region_bound_pairs_accum` vector. But now we save those
values into a map, so we can just process all the registered region
obligations at the end.
Remove OneVector, increase related SmallVec capacities
Removes the `OneVector` type alias (equivalent to `SmallVec<[T; 1]>`); it is used in scenarios where the capacity of 1 is often exceeded, which might be nullifying the performance wins (due to spilling to the heap) expected when using `SmallVec` instead of `Vec`.
The numbers I used in this PR are very rough estimates - it would probably be a good idea to adjust some/all of them, which is what this proposal is all about.
It might be a good idea to additionally create some local type aliases for the `SmallVec`s in the `Folder` trait, as they are repeated in quite a few spots; I'd be happy to apply this sort of adjustments.
Stabilize pattern_parentheses feature
Addresses #51087 .
Stabilizes the previously unstable feature `pattern_parentheses` which enables the use of `()` in match patterns.
Rollup of 12 pull requests
Successful merges:
- #53518 (Add doc for impl From in char_convert)
- #54058 (Introduce the partition_dedup/by/by_key methods for slices)
- #54281 (Search box)
- #54368 (Reduce code block sides padding)
- #54498 (The project moved under the Mozilla umbrella)
- #54518 (resolve: Do not block derive helper resolutions on single import resolutions)
- #54522 (Fixed three small typos.)
- #54529 (aarch64-pc-windows-msvc: Don't link libpanic_unwind to libtest.)
- #54537 (Rename slice::exact_chunks() to slice::chunks_exact())
- #54539 (Fix js error)
- #54557 (incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds.)
- #54558 (Improvements to finding LLVM's FileCheck)
Failed merges:
r? @ghost
Improvements to finding LLVM's FileCheck
This patch adds a few improvements to how the build system finds
LLVM's FileCheck program.
* On Fedora, the system LLVM installs FileCheck in the "llvm"
subdirectory of the LLVM libdir. This patch teaches the build
system to look there.
* This adds a configure option to specify which llvm-config executable
to use. This is handy on systems that can parallel install multiple
versions of LLVM; for example I can now:
./configure --llvm-config=/bin/llvm-config-5.0-64
... to build against LLVM 5, rather than whatever the default
llvm-config might be.
* Finally, this adds a configure- and config.toml- option to set the
path to FileCheck. This is handy when building against an LLVM
where FileCheck was not installed. This happens on compatibility
installs of LLVM on Fedora.
incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds.
So far the compiler would automatically enable sharing of monomorphizations for incremental builds. That was OK because without (Thin)LTO this could have very little impact on the runtime performance of the generated code. However, since https://github.com/rust-lang/rust/pull/53673, ThinLTO and incr. comp. can be combined, so the trade-off is not as clear anymore.
This PR removes the automatic tie between the two options. Whether monomorphizations are shared between crates or not now _only_ depends on the optimization level.
r? @alexcrichton
aarch64-pc-windows-msvc: Don't link libpanic_unwind to libtest.
This implements the suggestion from https://github.com/rust-lang/rust/issues/54190#issuecomment-422904437 in order to unbreak bootstrapping for the `aarch64-pc-windows-msvc` target. With this applied and using MSVC 15.8.3 for linking the bootstrap actually works and I can cross-compile a hello-world program.
r? @alexcrichton
resolve: Do not block derive helper resolutions on single import resolutions
Derive helpers currently conflict with anything else, so if some resolution from a single import appears later, it will result in error anyway.
Fixes https://github.com/rust-lang/rust/issues/54471 (stable-to-beta regression)
r? @ghost