Maintain chain of derived obligations #69793

estebank · 2020-03-07T00:25:43Z

When evaluating the derived obligations from super traits, maintain a
reference to the original obligation in order to give more actionable
context in the output.

Continuation (and built on) #69745, subset of #69709.

r? @eddyb

src/librustc_infer/traits/wf.rs

eddyb · 2020-03-12T16:15:20Z

src/librustc_infer/traits/wf.rs

+                let parent_trait_ref = obligation
+                    .predicate
+                    .to_opt_poly_trait_ref()
+                    .unwrap_or_else(|| ty::Binder::dummy(*trait_ref));


I think "parent" implies you should always use trait_ref, while obligation.predicate is used for the "child" obligation that this closure produces.

I don't think that's right. Changing this to be let parent_trait_ref = ty::Binder::dummy(*trait_ref); causes the output to be nonsensical.

From:

error[E0277]: the trait bound `T: MyDisplay` is not satisfied --> $DIR/issue-65774-2.rs:16:6 | LL | trait MPU { | --- LL | type MpuConfig: MyDisplay = T; | --------- required by this bound in `MPU` ... LL | impl MPU for S { } | ^^^ the trait `MyDisplay` is not implemented for `T` | = note: required because of the requirements on the impl of `MyDisplay` for `<S as MPU>::MpuConfig`

to

error[E0277]: the trait bound `T: MyDisplay` is not satisfied --> $DIR/issue-65774-2.rs:16:6 | LL | trait MPU { | --- LL | type MpuConfig: MyDisplay = T; | --------- required by this bound in `MPU` ... LL | impl MPU for S { } | ^^^ the trait `MyDisplay` is not implemented for `T` | = note: required because of the requirements on the impl of `MPU` for `S`

In my eyes the first one is clearly correct, while the second one is clearly incorrect.

How is that error even possible? Do we not check associated type defaults?!
cc @nikomatsakis did we create another type alias situation?

That error happens if we use ty::Binder::dummy(*trait_ref) directly, it just means that trait_ref is not what we want as the parent_trait_ref.

The associated type default is malformed inside the trait.
There should be no errors in impls, only one in the trait itself.

One of the reasons I'm saying that is because this output:

= note: required because of the requirements on the impl of `MPU` for `S`

Is the only meaningful cause for something that the impl caused, try examples that don't involve associated type defaults.

It only looks weird because the whole error is nonsensical to begin with.
It shouldn't error in the impl when the trait definition is clearly wrong.

eddyb · 2020-03-12T16:18:00Z

src/test/ui/associated-types/issue-65774-1.stderr

@@ -16,6 +16,8 @@ LL |     type MpuConfig: MyDisplay = T;
 ...
 LL | impl MPU for S { }
   |      ^^^ the trait `MyDisplay` is not implemented for `T`
+   |
+   = note: required because of the requirements on the impl of `MyDisplay` for `<S as MPU>::MpuConfig`


Okay we probably do need something different because it's already handled by "required by this bound in MPU" above apparently, and better? So we end up with duplication that mentions "impl" even if none is responsible.

I think that the current code appropriately handles these cases by adding a new DerivedObligation variant. I'd like to unify BuiltingDerivedObligation, ImplDerivedObligation and DerivedObligation and add a field to differentiate between them, but I haven't done so as it'll require changing a couple of extra places that I didn't want to muck about with earlier. I can do that in this PR if you prefer (but will add to the diff).

eddyb · 2020-03-12T16:18:53Z

src/librustc_infer/traits/wf.rs

+                    parent_trait_ref,
+                    parent_code: Rc::new(obligation.cause.code.clone()),
+                };
+                cause.code = traits::ObligationCauseCode::ImplDerivedObligation(derived_cause);
                extend_cause_with_original_assoc_item_obligation(


Maybe extend_cause_with_original_assoc_item_obligation should use a derived cause only if it doesn't apply an associated type bound cause?

estebank · 2020-04-09T01:01:27Z

I'm trying out a couple of things to remove the current hack and actually propagate the spans correctly. If I get things right, the whole of extend_cause_with_original_assoc_item_obligation will go away. For now, I slashed a significant part of it and am using it only to point at the correct associated type.

estebank · 2020-04-11T18:40:46Z

src/test/ui/traits/traits-assoc-type-in-supertrait-bad.stderr

 error[E0271]: type mismatch resolving `<std::vec::IntoIter<i32> as std::iter::Iterator>::Item == u32`
-  --> $DIR/traits-assoc-type-in-supertrait-bad.rs:11:6
+  --> $DIR/traits-assoc-type-in-supertrait-bad.rs:12:16
   |
-LL | impl Foo for IntoIter<i32> {
-   |      ^^^ expected `i32`, found `u32`
+LL |     type Key = u32;
+   |                ^^^ expected `i32`, found `u32`


I'm looking at keeping enough information around for obligations born out of projections, but this might take a while. At the same time, these are the ones that will be the most useful to fix.

Note to self: For these we need to look in select.rs and project.rs and walk back from confirm_impl_candidate to see how to keep a chain of obligations instead of what we have now where we have a single step.

estebank · 2020-04-11T21:18:28Z

I think this PR is ready to be reviewed again.

src/test/ui/associated-types/defaults-unsound-62211-1.stderr

nikomatsakis · 2020-04-15T21:46:02Z

src/test/ui/associated-types/defaults-unsound-62211-1.stderr

+   |       -------------
+...
+LL |     + Deref<Target = str>
+   |       ------------------- required by this bound in `UncheckedCopy`


really, this bound is on the associated type -- I've been wanting to refactor the setup that we use for this for some time, actually...I guess orthogonal from this PR, but we could potentially detect it and underline the associated type. I'm imagining that we look for a bound whose self type is <Self as Trait<...>>::Item basically.

This is true, but for the output to work correctly we'll need to collect more information in BindingObligation. I'd prefer to do so in a separate PR, as this one is just making it more common, not introducing it. I think the changes will have to be in nominal_obligations.

Separate PR seems good.

src/test/ui/associated-types/issue-65774-2.stderr

nikomatsakis · 2020-04-15T21:48:21Z

The code all seems fine to me, to be honest, but I have to admit I'm not really sure why these changes do what they do. =) I think I would need to spend more time reading into the surrounding code to bring it back in cache.

nikomatsakis · 2020-04-17T11:34:19Z

src/test/ui/issues/issue-65673.stderr

 LL |     type Ctx;
-   |          --- associated type defined here
+   |     --------- required by this bound in `WithType`


I wonder if we want to be careful about the implied Sized bounds? Perhaps something we can leave for follow-up.

nikomatsakis · 2020-04-17T11:36:19Z

src/test/ui/suggestions/missing-assoc-type-bound-restriction.stderr

 ...
 LL |     type Assoc = ChildWrapper<T::Assoc>;
-   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Child<A>` is not implemented for `<T as Parent>::Assoc`
+   |                  ^^^^^^^^^^^^^^^^^^^^^^ the trait `Child<A>` is not implemented for `<T as Parent>::Assoc`


This is mildly confusing, because the error here is only "indirectly" attributable to the associtaed type -- I assume it steps from the fact that we have an impl<A, T> Child<A> for ChildWrapper<T> where T: Child<A>?

Yep. And it's a case I would like to improve. I think that for this we need to look in select.rs or project.rs to keep more information there, right now we're dropping too much on the floor for us to figure these out.

nikomatsakis · 2020-04-17T11:40:08Z

@bors r+

PS, @eddyb, not trying to step on your toes, just lift your burden -- I think your concerns were resolved, but if I'm wrong, feel free to r- or at least comment.

bors · 2020-04-17T11:40:09Z

📌 Commit 71a763e9345ea790b747ffd8bf8364eb3ed4487f has been approved by nikomatsakis

eddyb · 2020-04-17T11:43:55Z

Only thing I can see at a glance is descr methods.
Please use tcx.def_kind(def_id).descr() instead.

@bors r-

eddyb · 2020-04-17T11:47:02Z

Although, uhh, #70043 hasn't landed yet, I wonder what's up with that.
EDIT: I'm taking over that PR and blocking this one on it.

estebank · 2020-04-18T23:33:47Z

@eddyb given that that PR is now blocked as well, I'm reworking the last commit to not introduce the new descr methods and instead of labels saying required by a bound in this trait changing them to required by a bound in this. That way we can land this PR and fix that label at a later time.

When evaluating the derived obligations from super traits, maintain a reference to the original obligation in order to give more actionable context in the output.

estebank · 2020-04-19T00:22:51Z

@bors r=nikomatsakis

I'm pushing to merge with the change in the previous comment. The queue is quite slow today so it should give you @eddyb enough time to revert the approval if you disagree :)

bors · 2020-04-19T00:22:52Z

📌 Commit d9a5419 has been approved by nikomatsakis

bors · 2020-04-19T06:42:57Z

⌛ Testing commit d9a5419 with merge e7497a8...

bors · 2020-04-19T10:01:04Z

☀️ Test successful - checks-azure
Approved by: nikomatsakis
Pushing e7497a8 to master...

rust-highfive assigned eddyb Mar 7, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 7, 2020

This comment has been minimized.

Sign in to view

estebank force-pushed the predicate-obligations-4 branch from 451d602 to 704f4d5 Compare March 7, 2020 00:46

estebank mentioned this pull request Mar 7, 2020

Maintain predicate obligation chain for more detailed diagnostics #69709

Closed

eddyb reviewed Mar 7, 2020

View reviewed changes

src/librustc_infer/traits/wf.rs Outdated Show resolved Hide resolved

eddyb reviewed Mar 12, 2020

View reviewed changes

This comment has been minimized.

Sign in to view

JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 28, 2020

estebank mentioned this pull request Apr 2, 2020

Remove duplicated code in trait selection #70641

Merged

joelpalmer added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 6, 2020

This comment has been minimized.

Sign in to view

estebank added the S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. label Apr 6, 2020

estebank force-pushed the predicate-obligations-4 branch from 6d8923b to 5991685 Compare April 8, 2020 23:17

estebank force-pushed the predicate-obligations-4 branch from 53cb43c to 828073f Compare April 11, 2020 18:38

estebank commented Apr 11, 2020

View reviewed changes

nikomatsakis reviewed Apr 15, 2020

View reviewed changes

estebank force-pushed the predicate-obligations-4 branch from 07b0e90 to 71a763e Compare April 16, 2020 17:38

nikomatsakis approved these changes Apr 17, 2020

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 17, 2020

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Apr 17, 2020

eddyb added the S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. label Apr 17, 2020

estebank added 4 commits April 18, 2020 16:37

Maintain chain of derived obligations

ad1c23c

When evaluating the derived obligations from super traits, maintain a reference to the original obligation in order to give more actionable context in the output.

Remove AssocTypeBound and propagate bound Spans

6bc55c7

Do not emit note for projected derived obligations

ce936e9

Add label to item source of bound obligation

d9a5419

estebank force-pushed the predicate-obligations-4 branch from 71a763e to d9a5419 Compare April 19, 2020 00:20

bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 19, 2020

bors mentioned this pull request Apr 19, 2020

Dogfood more or_patterns in the compiler #71231

Merged

bors merged commit e7497a8 into rust-lang:master Apr 19, 2020

This was referenced Apr 19, 2020

Simplify local_def_id and as_local_hir_id #71215

Merged

On type mismatch involving associated type, suggest constraint #71108

Merged

chrissimpkins mentioned this pull request Apr 22, 2020

Regression in spacing of left margin in diagnostics #71363

Closed

xiaotianrandom mentioned this pull request May 31, 2020

Wrong obligation cause span of associated type mismatch #72806

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Maintain chain of derived obligations #69793

Maintain chain of derived obligations #69793

estebank commented Mar 7, 2020

This comment has been minimized.

This comment has been minimized.

eddyb Mar 12, 2020

estebank Apr 8, 2020

eddyb Apr 8, 2020

estebank Apr 9, 2020

eddyb Apr 9, 2020

eddyb Apr 9, 2020

eddyb Mar 12, 2020

estebank Apr 11, 2020

eddyb Mar 12, 2020

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

estebank commented Apr 9, 2020

estebank Apr 11, 2020 •

edited

Loading

estebank commented Apr 11, 2020

nikomatsakis Apr 15, 2020

estebank Apr 16, 2020 •

edited

Loading

nikomatsakis Apr 17, 2020

nikomatsakis commented Apr 15, 2020

nikomatsakis Apr 17, 2020

nikomatsakis Apr 17, 2020

estebank Apr 17, 2020

nikomatsakis commented Apr 17, 2020

bors commented Apr 17, 2020

eddyb commented Apr 17, 2020 •

edited

Loading

eddyb commented Apr 17, 2020 •

edited

Loading

estebank commented Apr 18, 2020

estebank commented Apr 19, 2020

bors commented Apr 19, 2020

bors commented Apr 19, 2020

bors commented Apr 19, 2020

Maintain chain of derived obligations #69793

Maintain chain of derived obligations #69793

Conversation

estebank commented Mar 7, 2020

This comment has been minimized.

This comment has been minimized.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

estebank commented Apr 9, 2020

estebank Apr 11, 2020 • edited Loading

Choose a reason for hiding this comment

estebank commented Apr 11, 2020

Choose a reason for hiding this comment

estebank Apr 16, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Apr 15, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Apr 17, 2020

bors commented Apr 17, 2020

eddyb commented Apr 17, 2020 • edited Loading

eddyb commented Apr 17, 2020 • edited Loading

estebank commented Apr 18, 2020

estebank commented Apr 19, 2020

bors commented Apr 19, 2020

bors commented Apr 19, 2020

bors commented Apr 19, 2020

estebank Apr 11, 2020 •

edited

Loading

estebank Apr 16, 2020 •

edited

Loading

eddyb commented Apr 17, 2020 •

edited

Loading

eddyb commented Apr 17, 2020 •

edited

Loading