NLL: Fix bug in associated constant type annotations.
Fixes#57280.
This PR reverses the variance used when relating types from the type
annotation of an associated constant - this matches the behaviour of the
lexical borrow checker and fixes a bug whereby matching a `&'a str`
against a `&'static str` would produce an error.
r? @nikomatsakis
tests: Do not use `-Z parse-only`, continue compilation to test recovery
Make tests closer to reality!
The next step will be enabling `-Z continue-parse-after-error` by default and looking at the regressions.
A few instances of `-Z parse-only` are kept when it's appropriate, see e.g `ui/impl-trait/impl-trait-plus-priority.rs`, which tests mostly semantically wrong code and would generate too much useless noise if allowed to continue.
use structured suggestion for method calls
Furthermore, don't suggest calling the method if it is part of a place
expression, as this is invalid syntax.
I'm thinking it might be worth putting a label on the method assignment span like "this is a method" and removing the span from the "methods are immutable" text so it isn't reported twice.
The suggestions in `src/test/ui/did_you_mean/issue-40396.stderr` are suboptimal. I could check if the containing expression is `BinOp`, but I'm not sure if that's general enough. Any ideas?
r? @estebank
Fix#56806 by using `delay_span_bug` in object safety layout sanity checks
It's possible that `is_object_safe` is called on a trait method that with an invalid receiver type. This caused an ICE in #56806, because `receiver_is_dispatchable` returns `true` for `self: Box<dyn Trait>`, which causes one of the layout sanity checks in object_safety.rs to fail. Replacing `bug!` with `delay_span_bug` solves this.
The fact that `receiver_is_dispatchable` returns `true` here could be considered a bug. It passes the check that the method implements, though: `Box<dyn Trait>` implements `DispatchFromDyn<Box<dyn Trait>>` because `dyn Trait` implements `Unsize<dyn Trait>`. It would be good to hear what @eddyb and @nikomatsakis think.
Note that I only added a test for the case encountered in #56806. I could not come up with a case that triggered an ICE from the other check, `bug!("receiver when Self = dyn Trait should be ScalarPair, found Scalar")`. There is no way, to my knowledge, that you can make `receiver_is_dispatchable` return true but still have a `Scalar` ABI when `Self = dyn Trait`.
One other case I encountered while debugging #56806 was that if you have a type parameter `T` that implements `Deref<Target=Self>` and `DispatchFromDyn<T>`, and use it as a method receiver, it will cause an ICE during `is_object_safe` because `T` has no layout ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d9b7497b3be0ca8382fa7d9497263214)):
```rust
trait Trait<T: Deref<Target=Self> + DispatchFromDyn<T>> {
fn foo(self: T) -> dyn Trait<T>;
}
```
I don't intend to remove the ICE there because it is a pathological case, especially since there is no way to implement `DispatchFromDyn<T>` for `T` — the checks in typeck/coherence/builtin.rs do not allow that.
fixes#56806
r? @varkor
NLL: Add closure cannot be moved note.
Fixes#57098.
This PR extends existing logic for checking whether a closure that
is `FnOnce` and therefore moves variables that it captures from the
environment has already been invoked when being invoked again.
Now, this logic will also check whether the closure is being moved after
previously being moved or invoked and add an appropriate note.
r? @pnkfelix
Add support for trait-objects without a principal
The hard-error version of #56481 - should be merged after we do something about the `traitobject` crate.
Fixes#33140.
Fixes#57057.
r? @nikomatsakis
Implement the Re-rebalance coherence RFC
This is the first time I touch anything in the compiler so just tell me if I got something wrong.
Big thanks to @sgrif for the pointers where to look for those things.
cc #55437
It's possible that `is_object_safe` is called on a trait that is ill-formed, and we shouldn't ICE unless there are no errors being raised. Using `delay_span_bug` solves this.
fixes#56806
make `panictry!` private to libsyntax
This commit completely removes usage of the `panictry!` macro from
outside libsyntax. The macro causes parse errors to be fatal, so using
it in libsyntax_ext caused parse failures *within* a syntax extension to
be fatal, which is probably not intended.
Furthermore, this commit adds spans to diagnostics emitted by empty
extensions if they were missing, à la #56491.
This commit reverses the variance used when relating types from the type
annotation of an associated constant - this matches the behaviour of the
lexical borrow checker and fixes a bug whereby matching a `&'a str`
against a `&'static str` would produce an error.
Universes
This PR transitions the compiler to use **universes** instead of the **leak-check**. It is marked as [WIP] for a few reasons:
- The diagnostics at present are terrible =)
- This changes the behavior of coherence, regressing some things that used to compile
The goals of this PR at present are:
- To start getting some eyes on the code
- To do a crater run
- To see the full travis results (due to https://github.com/rust-lang/rust/issues/52452, I am not able to run the full test suite locally anymore at present)
The first few commits in the PR are changing how `evaluate` treats regions. We now track whether region comparisons occurred, reverting the "staticized" query approach that @arielb1 put in. The problem with "staticized" queries is that it relied on the leak-check to get higher-ranked things correct, and we are removing the leak-check in this PR series, so that caused problems.
You can see at the end a collection of test updates. Mostly we behave the same but with atrocious diagnostics, but there are a number of cases where we used to error and now no longer do, as well as single case where we used to **not** error but we now do (the coherence-subtyping change).
(Note: it would be possible to do a version of leak-check that propagates universe information and recover the old behavior. I am reluctant to do so because I'd like to leave us room to get more precise -- e.g., I want to eventually handle things like `exists<'a> { for<'b> { if ('a: 'b) { 'a: 'b } } }` which presently the leak-check cannot cope with etc. Also because it seems more consistent to me: most folks I've talked to expect the new behavior and are surprised to learn that binding sites were so significant before when it comes to coherence. One question is, though, to what extent are people relying on this in the wild?)
