use closure def-id in returns, but base def-id in locals
The refactorings to handle `let x: impl Trait` wound up breaking `impl Trait` in closure return types. I think there are some deeper problems with the code in question, but this a least should make @eddyb's example work.
Fixes#54593
r? @eddyb
Rollup of 8 pull requests
Successful merges:
- #54564 (Add 1.29.1 release notes)
- #54567 (Include path in stamp hash for debuginfo tests)
- #54577 (rustdoc: give proc-macros their own pages)
- #54590 (std: Don't let `rust_panic` get inlined)
- #54598 (Remove useless lifetimes from `Pin` `impl`s.)
- #54604 (Added help message for `self_in_typedefs` feature gate)
- #54635 (Improve docs for std::io::Seek)
- #54645 (Compute Android gdb version in compiletest)
rustc: keep a Span for each predicate in ty::GenericPredicates.
This should allow finer-grained diagnostics, including migration suggestions for #54090.
(Note that I haven't changed most of the users of `predicates_of` to use the new spans)
r? @nikomatsakis
codegen_llvm: check inline assembly constraints with LLVM
---%<---
Hey all,
As issue #54130 highlights, constraints are not checked and passing bad constraints to LLVM can crash it since a `Verify()` call is placed inside an assertion (see: `src/llvm/lib/IR/InlineAsm.cpp:39`).
As this is my first PR to the Rust compiler (woot! 🎉), there might be better ways of achieving this result. In particular, I am not too happy about generating an error in codegen; it would be much nicer if we did it earlier. However, @rkruppe [noted on IRC](https://botbot.me/mozilla/rustc/2018-09-25/?msg=104791581&page=1) that this should be fine for an unstable feature and a much better solution than the _status quo_, which is an ICE.
Thanks!
--->%---
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").
Fixes: #54130
Signed-off-by: Levente Kurusa \<lkurusa@acm.org\>
Use full name to identify a macro in a `FileName`.
Before this two macros with same name would be indistinguishable inside a `FileName`. This caused a bug in incremental compilation (see #53097) since two different macros would map out to the same `StableFilemapId`.
Fixes#53097.
r? @nrc
RFC 2093 (tracking issue #44493) lets us leave off
commonsensically inferable `T: 'a` outlives requirements. (A separate
feature-gate was split off for the case of 'static lifetimes, for
which questions still remain.) Detecting these was requested as an
idioms-2018 lint.
It turns out that issuing a correct, autofixable suggestion here is
somewhat subtle in the presence of other bounds and generic
parameters. Basically, we want to handle these three cases:
• One outlives-bound. We want to drop the bound altogether, including
the colon—
MyStruct<'a, T: 'a>
^^^^ help: remove this bound
• An outlives bound first, followed by a trait bound. We want to
delete the outlives bound and the following plus sign (and
hopefully get the whitespace right, too)—
MyStruct<'a, T: 'a + MyTrait>
^^^^^ help: remove this bound
• An outlives bound after a trait bound. We want to delete the
outlives lifetime and the preceding plus sign—
MyStruct<'a, T: MyTrait + 'a>
^^^^^ help: remove this bound
This gets (slightly) even more complicated in the case of where
clauses, where we want to drop the where clause altogether if there's
just the one bound. Hopefully the comments are enough to explain
what's going on!
A script (in Python, sorry) was used to generate the
hopefully-sufficiently-exhaustive UI test input. Some of these are
split off into a different file because rust-lang-nursery/rustfix#141
(and, causally upstream of that, #53934) prevents them from being
`run-rustfix`-tested.
We also make sure to include a UI test of a case (copied from RFC
2093) where the outlives-bound can't be inferred. Special thanks to
Niko Matsakis for pointing out the `inferred_outlives_of` query,
rather than blindly stripping outlives requirements as if we weren't a
production compiler and didn't care.
This concerns #52042.
Migrate `src/test/ui/run-pass/*` back to `src/test/run-pass/`.
Moves all the tests from `src/test/ui/run-pass/**` back to `src/test/run-pass/`.
This should have no impact on our overall testing completeness due to PR #54223Fix#54047
[NLL] Get Polonius borrow check to work in simple cases
* Restores the generation of outlives facts from subtyping.
* Restore liveness facts.
* Generate invalidates facts at the start point of each location,
where we check for errors.
* Add a small test for simple cases (previously these cases have compiled, and more recently ICEd).
Closes#54212
cc #53142 (will need test)
### Known limitations
* Two phase borrows aren't implemented for Polonius yet
* Invalidation facts haven't been updated for some of the recent changes to make `Drop` terminators access fewer things.
* Fact generation is not as optimized as it could be.
* Around 30 tests fail in compare mode, often tests that are ignored in nll compare mode
r? @nikomatsakis
NLL: regression test for "dropck: track order of destruction for r-value temporaries"
Once this lands, we can remove the E-needstest from #22323.
(We shouldn't close the bug itself, however, because we are leaving the NLL-fixed-by-NLL bugs open until NLL is turned on by default.)
Using the `closure_base_def_id` indiscriminantely, as we were doing
before, winds up "going wrong" if the closure type includes the `impl
Trait` from the parent. The problem arises because the return value
for closures is inferred and meant to treat the return
type *opaquely*, so we don't want to be "desugaring" it into the
underlying type.
* Restores the generation of outlives facts from subtyping.
* Restore liveness facts.
* Generate invalidates facts at the start point of each location,
where we check for errors.
* Add a small test for simple cases.
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.
Stabilize pattern_parentheses feature
Addresses #51087 .
Stabilizes the previously unstable feature `pattern_parentheses` which enables the use of `()` in match patterns.
`impl trait` in bindings (feature: impl-trait-existential-types)
This PR enables `impl Trait` syntax (opaque types) to be used in bindings, e.g.
* `let foo: impl Clone = 1;`
* `static foo: impl Clone = 2;`
* `const foo: impl Clone = 3;`
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`.
CC @cramertj @oli-obk @eddyb @Centril @varkor
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.
cc https://github.com/rust-lang/rust/issues/53834
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
r? @nikomatsakis
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.
[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`.
We also now handle enums containing `Drop` types.
Closes#53569
r? @nikomatsakis
cc @pnkfelix
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.
This also allows us to handle enums in a simpler way, since we don't
have to construct any new places.
When dropping a self-borrowing struct we shouldn't add a "values in a
scope are dropped in the opposite order they are defined" message,
since there is only one value being dropped.
Error now correctly checks whether the borrow that does not live
long enough is being returned before annotating the error with the
arguments and return type from the signature - as this would not be
relevant if the borrow was not being returned.
