-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Matthew's work on improving NLL's "higher-ranked subtype error"s #86700
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still looking at the two big "adding" files, but otherwise it looks great so far! Only a couple of nitpicks that I noticed, but very little that would need addressing on this PR.
| ^^^^^^^ one type is more general than the other | ||
| | ||
= note: expected type `&'a ()` | ||
found reference `&()` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if we could reach parity with the non-nll output:
error[E0308]: mismatched types
--> $DIR/higher-ranked-projection.rs:25:5
|
LL | foo(());
| ^^^ lifetime mismatch
|
= note: expected type `&'a ()`
found type `&()`
note: the lifetime requirement is introduced here
--> $DIR/higher-ranked-projection.rs:15:33
|
LL | where for<'a> &'a T: Mirror<Image=U>
| ^^^^^^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some good news and less good news here. The good news is, this PR uses basically the same piece of code that emits the error above, the "nice region errors" (I take that back the error above is not a nice region error 😅 but some of the others in the blessed test expectations are), so it's at least not impossible to reach parity. I believe this was purposeful and one of Matthew's goals (I'm only the slightly-informed messenger here).
The "bad" news is the data: I don't think I have access to the actual same ObligationCause
s in this case (or couldn't find them when I looked) so if you or @nikomatsakis (I know he won't see this notification, it's more of a message for when/if he also reviews this PR) can point me in the right direction to add them, I'll be glad to work on this more.
To be more specific, the migrate-mode error note above is emitted by report_placeholder_failure
which specifically looks for a BindingObligation
cause.
With this PR, this is an UpperBoundUniverseConflict
but with types value pairs, so the nice region error is not actually emitted as these placeholder conflicts are only about placeholder and traits mismatches. The obligation available is however a MiscObligation
here. (I believe it's this dummy one).
Funnily enough, report_placeholder_failure
would emit what this PR emits, in such fallback cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I'm not sure off hand how to get that obligation cause, it's probably going to take a bit of threading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, thank you. I will look into it when I can.
Do you and @estebank agree that we could leave this topic for follow-up improvement PRs ? (Esteban has mentioned this on other suggestions, and I presume it would be ok for this suggestion as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as we don't turn NLL on without addressing this, I'm ok with it.
--> $DIR/issue-59311.rs:17:9 | ||
| | ||
LL | v.t(|| {}); | ||
| ^^^^^ | ||
| | ||
= note: could not prove for<'a> &'a V: 'static |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would point at the where
clause as well. (not for this PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not actually be an error - see #89409. However, it occurs both with and without #![feature(nll)]
, so I don't think we need to address this before turning on NLL mode.
= note: `SomeStruct` must implement `Foo<(&'0 isize, &'1 isize)>`, for any two lifetimes `'0` and `'1`... | ||
= note: ...but it actually implements `Foo<(&'2 isize, &'2 isize)>`, for some specific lifetime `'2` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would point at the impl
and the where
clause in want_foo2
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In both NLL and non-nll mode, we don't point at the impl
or where
clause. I think this could be an separate diagnostics issue, independent of the NLL transition.
fn next_placeholder_region(&mut self, placeholder: ty::PlaceholderRegion) -> ty::Region<'tcx> { | ||
if let Some(borrowck_context) = &mut self.borrowck_context { | ||
borrowck_context.constraints.placeholder_region(self.infcx, placeholder) | ||
} else { | ||
self.infcx.tcx.lifetimes.re_erased | ||
} | ||
self.borrowck_context.constraints.placeholder_region(self.infcx, placeholder) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change doesn't break anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't expect it to, this Option
was only used with a Some
, but it's easier to see in the individual commit
compiler/rustc_trait_selection/src/traits/query/type_op/implied_outlives_bounds.rs
Show resolved
Hide resolved
056e631
to
eaa934b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I reviewed the PR. I understand what it's doing. I'm mildly worried about the lack of DRY, though, I'd like it if it the query impl and the code to "re-run the query and report errors" were combined more clearly-- or at least in the same file or something!
I'm imagining it's probably possible to have some kind of helper function that both of them can call?
placeholder_region: ty::Region<'tcx>, | ||
error_region: Option<ty::Region<'tcx>>, | ||
) -> Option<DiagnosticBuilder<'tcx>> { | ||
tcx.infer_ctxt().enter_with_canonical(span, &self.canonical_query, |ref infcx, key, _| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, this seems awfully "non-DRY", right? It'd be nice if this shared some of the same code as the query itself..?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the one hand, I agree the duplication is to be avoided, so I added a helper function to share most of the query code for type_op_prove_predicate
. Let me know if that's more to your liking.
On the other hand, these type op queries are super small and have not changed in the last 3 years, and since the normalize step to get the obligations in the diagnostics is different from the query's, I have not done this for the other type op type_op::Normalize
: it would only de-dupe a single register_predicate_obligations
call.
I think the functional difference between the two is the query fails to normalize this (but maybe it's some subtle interaction with the leak-check there, or maybe the difference would be erased by some of the fixes in #85499, I don't know).
I can add a FIXME to at least track this in the list of remaining tasks to be done to turn full NLLs on, if that's OK with you ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's ok
| ^^^^^^^ one type is more general than the other | ||
| | ||
= note: expected type `&'a ()` | ||
found reference `&()` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I'm not sure off hand how to get that obligation cause, it's probably going to take a bit of threading.
This comment has been minimized.
This comment has been minimized.
eaa934b
to
2cf4b87
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pushing this forwards.
{ | ||
fn to_universe_info(self, _base_universe: ty::UniverseIndex) -> UniverseInfo<'tcx> { | ||
// Ascribe user type isn't usually called on types that have different | ||
// bound regions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note for a future PR: I believe there is one test case that is affected by this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it was in one of the last few remaining instances of the old "higher-ranked subtype" errors involving type ascription ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After checking this, it's all of those.
compiler/rustc_mir/src/borrow_check/diagnostics/bound_region_errors.rs
Outdated
Show resolved
Hide resolved
Co-authored-by: matthewjasper <20113453+matthewjasper@users.noreply.github.com>
@bors r+ |
📋 Looks like this PR is still in progress, ignoring approval. Hint: Remove [WIP] from this PR's title when it is ready for review. |
r=me @lqd when not WIP :) |
WIP removed, FIXME added. I'll trigger bors once CI passes. |
@bors r=nikomatsakis I'll update the tracking issue to mention the actual state of the errors, and the known work remaining to be done (matching the non-NLL output, cleaning up the normalize type op query, improve errors for the type ascription type op query as Matthew mentioned) |
📌 Commit 8343806 has been approved by |
☀️ Test successful - checks-actions |
…sakis Handle type ascription type ops in NLL HRTB diagnostics Currently, there are still a few cases of the "higher-ranked subtype error" of yore, 4 of which are related to type ascription. This PR is a follow-up to rust-lang#86700, adding support for type ascription type ops, and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer, especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157), or an imprecision in some parts of normalization as [described here](rust-lang#86700 (comment))). Since we discussed these recently: - [here](rust-lang#86700 (comment)), cc `@matthewjasper,` - and [here](rust-lang#57374 (comment)), cc `@Aaron1011.` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? `@estebank` (so that they shake their fist at NLL's general direction less often) or `@nikomatsakis` or matthew or aaron, the more the merrier.
…sakis Handle type ascription type ops in NLL HRTB diagnostics Currently, there are still a few cases of the "higher-ranked subtype error" of yore, 4 of which are related to type ascription. This PR is a follow-up to rust-lang#86700, adding support for type ascription type ops, and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer, especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157), or an imprecision in some parts of normalization as [described here](rust-lang#86700 (comment))). Since we discussed these recently: - [here](rust-lang#86700 (comment)), cc ``@matthewjasper,`` - and [here](rust-lang#57374 (comment)), cc ``@Aaron1011.`` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ``@estebank`` (so that they shake their fist at NLL's general direction less often) or ``@nikomatsakis`` or matthew or aaron, the more the merrier.
…sakis Handle type ascription type ops in NLL HRTB diagnostics Currently, there are still a few cases of the "higher-ranked subtype error" of yore, 4 of which are related to type ascription. This PR is a follow-up to rust-lang#86700, adding support for type ascription type ops, and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer, especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157), or an imprecision in some parts of normalization as [described here](rust-lang#86700 (comment))). Since we discussed these recently: - [here](rust-lang#86700 (comment)), cc ```@matthewjasper,``` - and [here](rust-lang#57374 (comment)), cc ```@Aaron1011.``` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ```@estebank``` (so that they shake their fist at NLL's general direction less often) or ```@nikomatsakis``` or matthew or aaron, the more the merrier.
…sakis Handle type ascription type ops in NLL HRTB diagnostics Currently, there are still a few cases of the "higher-ranked subtype error" of yore, 4 of which are related to type ascription. This PR is a follow-up to rust-lang#86700, adding support for type ascription type ops, and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer, especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157), or an imprecision in some parts of normalization as [described here](rust-lang#86700 (comment))). Since we discussed these recently: - [here](rust-lang#86700 (comment)), cc ````@matthewjasper,```` - and [here](rust-lang#57374 (comment)), cc ````@Aaron1011.```` It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr). r? ````@estebank```` (so that they shake their fist at NLL's general direction less often) or ````@nikomatsakis```` or matthew or aaron, the more the merrier.
This PR rebases @matthewjasper's branch 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 that Niko wanted)