| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Once this anonymization has performed, we have no
way of recovering the original names during NLL
borrow checking. Keeping the original names allows
error messages in full NLL mode to contain the original
bound region names.
As a result, the typeck results may contain types that
differ only in the names used for their bound regions. However,
anonimization of bound regions does not guarantee that
all distinct types are unqual (e.g. not subtypes of each other).
For example, `for<'a> fn(&'a u32, &'a u32)` and
`for<'b, 'c> fn(&'b u32, &'c u32)` are subtypes of each other,
as explained here:
https://github.com/rust-lang/rust/blob/63cc2bb3d07d6c726dfcdc5f95cbe5ed4760641a/compiler/rustc_infer/src/infer/nll_relate/mod.rs#L682-L690
Therefore, any code handling types with higher-ranked regions already
needs to handle the case where two distinct `Ty`s are 'actually'
equal.
|
|
Matthew's work on improving NLL's "higher-ranked subtype error"s
This PR rebases `@matthewjasper's` [branch](https://github.com/matthewjasper/rust/tree/nll-hrtb-errors) which has great work to fix the obscure higher-ranked subtype errors that are tracked in #57374.
These are a blocker to turning full NLLs on, and doing some internal cleanups to remove some of the old region code.
The goal is so `@nikomatsakis` can take a look at this early, and I'll then do my best to help do the changes and followup work to land this work, and move closer to turning off the migration mode.
I've only updated the branch and made it compile, removed a warning or two.
r? `@nikomatsakis`
(Here's the [zulip topic to discuss this](https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/.2357374.3A.20improving.20higher-ranked.20subtype.20errors.20via.20.2386700) that Niko wanted)
|
|
|
|
|
|
These 2 tests are ignored in the NLL compare-mode, and are ignored in
the polonius compare-mode for the same reasons.
|
|
|
|
The bug was revealed by the behavior of the old-lub-glb-hr-noteq1.rs
test. The old-lub-glb-hr-noteq2 test shows the current 'order dependent'
behavior of coercions around higher-ranked functions, at least when
running with `-Zborrowck=mir`.
Also, run compare-mode=nll.
|
|
Revert the code that states that upcasting traits requires full
equality and change to require that the source type is a subtype of
the target type, as one would expect. As the comment states, this was
an old bug that we didn't want to fix yet as it interacted poorly with
the old leak-check. This fixes the old-lub-glb-object test, which was
previously reporting too many errors (i.e., in the previous commit).
|
|
In particular, it no longer occurs during the subtyping check. This is
important for enabling lazy normalization, because the subtyping check
will be producing sub-obligations that could affect its results.
Consider an example like
for<'a> fn(<&'a as Mirror>::Item) =
fn(&'b u8)
where `<T as Mirror>::Item = T` for all `T`. We will wish to produce a
new subobligation like
<'!1 as Mirror>::Item = &'b u8
This will, after being solved, ultimately yield a constraint that `'!1
= 'b` which will fail. But with the leak-check being performed on
subtyping, there is no opportunity to normalize `<'!1 as
Mirror>::Item` (unless we invoke that normalization directly from
within subtyping, and I would prefer that subtyping and unification
are distinct operations rather than part of the trait solving stack).
The reason to keep the leak check during coherence and trait
evaluation is partly for backwards compatibility. The coherence change
permits impls for `fn(T)` and `fn(&T)` to co-exist, and the trait
evaluation change means that we can distinguish those two cases
without ambiguity errors. It also avoids recreating #57639, where we
were incorrectly choosing a where clause that would have failed the
leak check over the impl which succeeds.
The other reason to keep the leak check in those places is that I
think it is actually close to the model we want. To the point, I think
the trait solver ought to have the job of "breaking down"
higher-ranked region obligation like ``!1: '2` into into region
obligations that operate on things in the root universe, at which
point they should be handed off to polonius. The leak check isn't
*really* doing that -- these obligations are still handed to the
region solver to process -- but if/when we do adopt that model, the
decision to pass/fail would be happening in roughly this part of the
code.
This change had somewhat more side-effects than I anticipated. It
seems like there are cases where the leak-check was not being enforced
during method proving and trait selection. I haven't quite tracked
this down but I think it ought to be documented, so that we know what
precisely we are committing to.
One surprising test was `issue-30786.rs`. The behavior there seems a
bit "fishy" to me, but the problem is not related to the leak check
change as far as I can tell, but more to do with the closure signature
inference code and perhaps the associated type projection, which
together seem to be conspiring to produce an unexpected
signature. Nonetheless, it is an example of where changing the
leak-check can have some unexpected consequences: we're now failing to
resolve a method earlier than we were, which suggests we might change
some method resolutions that would have been ambiguous to be
successful.
TODO:
* figure out remainig test failures
* add new coherence tests for the patterns we ARE disallowing
|
|
This reverts commit 2e01db4b396a1e161f7a73933fff34bc9421dba0.
|
|
Also, update the affected tests. This seems strictly better but it is
actually more permissive than I initially intended. In particular it
accepts this
```
forall<'a, 'b> {
exists<'intersection> {
'a: 'intersection,
'b: 'intersection,
}
}
```
and I'm not sure I want to accept that. It implies that we have a
`'empty` in the new universe intoduced by the `forall`.
|
|
|
|
|
|
|
|
|
|
This preserves the error you currently get on stable for the
old-lub-glb-object.rs test.
|
|
One surprise: old-lub-glb-object.rs, may indicate a bug
|
|
Still not great, but good enough to land this PR.
|
|
|
|
Fixes #33684
|
|
When we coerce `dyn Foo` to `dyn Bar`, that is OK as long as `Foo` is
usable in all contexts where `Bar` is usable (hence using the source
must be a subtype of the target).
This is needed for the universe-based code to handle
`old-lub-glb-object`; that test used to work sort of by accident
before with the old code.
|
|
|
|
|
|
The `dyn Trait` syntax was stabilized in 199ee327. Resolves #49277.
|
|
|
|
|
|
|
|
Use span label instead of span note for single line spans in
"incompatible arm" diagnostic.
|
|
|
|
|
