Niko Matsakis [Mon, 17 Sep 2018 18:00:33 +0000 (14:00 -0400)]
use approx. bounds to decide whether to add outlives obligations
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`.
Niko Matsakis [Wed, 12 Sep 2018 21:48:51 +0000 (17:48 -0400)]
apply `process_registered_region_obligations` at the end of regionck
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.
Auto merge of #54199 - nikomatsakis:predicate_may_hold-failure, r=eddyb
overlook overflows in rustdoc trait solving
Context:
The new rustdoc "auto trait" feature walks across impls and tries to run trait solving on them with a lot of unconstrained variables. This is prone to overflows. These overflows used to cause an ICE because of a caching bug (fixed in this PR). But even once that is fixed, it means that rustdoc causes an overflow rather than generating docs.
This PR therefore adds a new helper that propagates the overflow error out. This requires rustdoc to then decide what to do when it encounters such an overflow: technically, an overflow represents neither "yes" nor "no", but rather a failure to make a decision. I've decided to opt on the side of treating this as "yes, implemented", since rustdoc already takes an optimistic view. This may prove to include too many items, but I *suspect* not.
We could probably reduce the rate of overflows by unifying more of the parameters from the impl -- right now we only seem to consider the self type. Moreover, in the future, as we transition to Chalk, overflow errors are expected to just "go away" (in some cases, though, queries might return an ambiguous result).
Fixes #52873
cc @QuietMisdreavus -- this is the stuff we were talking about earlier
cc @GuillaumeGomez -- this supersedes #53687
Auto merge of #53824 - ljedrz:begone_onevector, r=michaelwoerister
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.
Auto merge of #54575 - pietroalbini:rollup, r=pietroalbini
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)
Proc-macros don't emit their attributes or source spans across crates.
This means that rustdoc can't actually see the docs of a proc-macro if
it wasn't defined in the active crate, and attempting to inline it
creates an empty page with no docs or source link. In lieu of attempting
to fix that immediately, this commit forces proc-macro re-exports to
never inline, which at least creates usable links to complete
documentation.
Pietro Albini [Tue, 25 Sep 2018 20:34:51 +0000 (22:34 +0200)]
Rollup merge of #54558 - tromey:find-filecheck, r=nikomatsakis
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.
Pietro Albini [Tue, 25 Sep 2018 20:34:50 +0000 (22:34 +0200)]
Rollup merge of #54557 - michaelwoerister:dont-auto-share-generics-for-incr-comp, r=alexcrichton
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.
Pietro Albini [Tue, 25 Sep 2018 20:34:46 +0000 (22:34 +0200)]
Rollup merge of #54529 - michaelwoerister:dont-unwind-test, 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.
Pietro Albini [Tue, 25 Sep 2018 20:34:38 +0000 (22:34 +0200)]
Rollup merge of #54058 - Kerollmops:slice-dedup, r=shepmaster
Introduce the partition_dedup/by/by_key methods for slices
This PR propose to add three methods to the slice type, the `partition_dedup`, `partition_dedup_by` and `partition_dedup_by_key`. The two other methods are based on `slice::partition_dedup_by`.
These methods take a mutable slice, deduplicates it and moves all duplicates to the end of it, returning two mutable slices, the first containing the deduplicated elements and the second all the duplicates unordered.
```rust
let mut slice = [1, 2, 2, 3, 3, 2];
let (dedup, duplicates) = slice.partition_dedup();
The benefits of adding these methods is that it is now possible to:
- deduplicate a slice without having to allocate and possibly clone elements on the heap, really useful for embedded stuff that can't allocate for example.
- not loose duplicate elements, because, when using `Vec::dedup`, duplicates elements are dropped. These methods add more flexibillity to the user.
Note that this is near a copy/paste of the `Vec::dedup_by` function, once this method is stable the goal is to replace the algorithm in `Vec` by the following.
```rust
pub fn Vec::dedup_by<F>(&mut self, same_bucket: F)
where F: FnMut(&mut T, &mut T) -> bool
{
let (dedup, _) = self.as_mut_slice().partition_dedup_by(same_bucket);
let len = dedup.len();
self.truncate(len);
}
```
This is part of [RFC 2071](https://github.com/rust-lang/rfcs/blob/master/text/2071-impl-trait-existential-types.md) ([tracking issue](https://github.com/rust-lang/rust/issues/34511)), but exists behind the separate feature gate `impl_trait_in_bindings`.
resolve: Do not block derive helper resolutions on single import resolutions
Derive helpers conflict currently conflict with anything else, so if some resolution from a single import appears later, it will result in error anyway
codegen_llvm: check inline assembly constraints with LLVM
LLVM provides a way of checking whether the constraints and the actual
inline assembly make sense. This commit introduces a check before
emitting code for the inline assembly. If LLVM rejects the inline
assembly (or its constraints), then the compiler emits an error E0668
("malformed inline assembly").
Tom Tromey [Tue, 25 Sep 2018 18:27:09 +0000 (12:27 -0600)]
Include path in stamp hash for debuginfo tests
The debuginfo tests are exposed to the environment in a couple of
ways: the path to the gdb executable matters, as does the Python path
used when loading lldb.
This patch incorporates these paths into the hash that is written to
the stamp file, so that changing the path will cause the tests to be
re-run.
Auto merge of #54411 - cramertj:await-keyword-error, r=nikomatsakis
Make "await" a pseudo-edition keyword
This change makes "await" ident an error in 2018 edition without async_await
feature and adds "await" to the 2018 edition keyword lint group that
suggest migration on the 2015 edition.
Tom Tromey [Tue, 25 Sep 2018 15:13:02 +0000 (09:13 -0600)]
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.
Auto merge of #53693 - scottmcm:marker-trait-attribute, r=nikomatsakis
Support an explicit annotation for marker traits
From the tracking issue for rust-lang/rfcs#1268:
> It seems obvious that we should make a `#[marker]` annotation. ~ https://github.com/rust-lang/rust/issues/29864#issuecomment-368959441
This PR allows you to put `#[marker]` on a trait, at which point:
- [x] The trait must not have any items ~~All of the trait's items must have defaults~~
- [x] Any impl of the trait must be empty (not override any items)
- [x] But impls of the trait are allowed to overlap
Auto merge of #53438 - matthewjasper:permissive-match-access, r=pnkfelix
[NLL] Be more permissive when checking access due to Match
Partially addresses #53114. notably, we should now have parity with AST borrowck. Matching on uninitialized values is still forbidden.
* ~~Give fake borrows for match their own `BorrowKind`~~
* ~~Allow borrows with this kind to happen on values that are already mutably borrowed.~~
* ~~Track borrows with this type even behind shared reference dereferences and consider all accesses to be deep when checking for conflicts with this borrow type. See [src/test/ui/issues/issue-27282-mutate-before-diverging-arm-3.rs](https://github.com/rust-lang/rust/commit/cb5c989598178af505fb215dd97afca8cc2b659f#diff-a2126cd3263a1f5342e2ecd5e699fbc6) for an example soundness issue this fixes (a case of #27282 that wasn't handled correctly).~~
* Create a new `BorrowKind`: `Shallow` (name can be bike-shed)
* `Shallow` borrows differ from shared borrows in that
* When we check for access we treat them as a `Shallow(Some(_))` read
* When we check for conflicts with them, if the borrow place is a strict prefix of the access place then we don't consider that a conflict.
* For example, a `Shallow` borrow of `x` does not conflict with any access or borrow of `x.0` or `*x`
* Remove the current fake borrow in matches.
* When building matches, we take a `Shallow` borrow of any `Place` that we switch on or bind in a match, and any prefix of those places. (There are some optimizations where we do fewer borrows, but this shouldn't change semantics)
* `match x { &Some(1) => (), _ => (), }` would `Shallow` borrow `x`, `*x` and `(*x as Some).0` (the `*x` borrow is unnecessary, but I'm not sure how easy it would be to remove.)
* Replace the fake discriminant read with a `ReadForMatch`.
* Change ReadForMatch to only check for initializedness (to prevent `let x: !; match x {}`), but not conflicting borrows. It is still considered a use for liveness and `unsafe` checking.
* Give special cased error messages for this kind of borrow.
Taylor Cramer [Fri, 21 Sep 2018 00:36:31 +0000 (17:36 -0700)]
Make "await" a pseudo-edition keyword
This change makes "await" ident an error in 2018 edition without async_await
feature and adds "await" to the 2018 edition keyword lint group that
suggest migration on the 2015 edition.
Auto merge of #53783 - RalfJung:ptr-docs, r=alexcrichton
Rewrite docs for pointer methods
This takes over https://github.com/rust-lang/rust/pull/51016 by @ecstatic-morse. They did most of the work, I just did some editing.
However, I realized one problem: This updates the docs for the "free functions" in `core::ptr`, but it does not update the copies of these docs for the inherent methods of the `*const T` and `*mut T` types. These getting out-of-sync is certainly bad, but I also don't feel like copying all this stuff around. Instead, we should remove this redundancy. Any good ideas?
Auto merge of #54509 - matthewjasper:better-drop-access, r=pnkfelix
[NLL] Rework checking for borrows conflicting with drops
Previously, we would split the drop access into multiple checks for each
field of a struct/tuple/closure and through `Box` dereferences. This
changes this to check if the borrow is accessed by the drop in
`places_conflict`.
projects / rust.git / log