Show pending obligations as unsatisfied constraints in report_similar_impl_candidates
#134348
+26
−4
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wesleywiser (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
rustbot
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
From the CI failure, it looks like the patch introduces a lot of redundant hints with constraints that are basically equivalent to the original constraint. I can try to work on hiding pending obligations that match the original. But I'm not quite sure how to do that within |
compiler-errors
requested changes
Dec 15, 2024
There was a problem hiding this comment.
I'm not totally certain what the motivation here is because there's no test and the issue you linked has a pretty large minimization, so I'm not actually sure what the root cause is and whether this is actually the best way to show that information.
Can you try to turn this into a more minimal example to try to explain better what information the compiler is missing in its diagnostics outputs?
Otherwise I'm not totally certain we can give good feedback on the approach in this PR, especially because making a totally new way of reporting unsatisfied predicates on a pretty common codepath (for unsatisfied impls) seems a bit excessive on first glance.
| @@ -17,6 +17,8 @@ use crate::traits::Obligation; | |||
| pub enum ScrubbedTraitError<'tcx> { | |||
| /// A real error. This goal definitely does not hold. | |||
| TrueError, | |||
| // A select error with pending obligations | |||
| Select(PredicateObligations<'tcx>), | |||
There was a problem hiding this comment.
I understand that it's not really documented, but this is antithetical to the design of ScrubbedTraitError. That type should be very lightweight.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #134346
Summary
This PR attempts to fix the issue in #134346, by additional
helphints for each unsatisfied indirect constraint inside a blanket implementation.Details
To provide the extra information, a new variant
Select(PredicateObligations<'tcx>)is added toScrubbedTraitError<'tcx>to extract thepending_obligationsreturned fromselect_where_possible. Then insidereport_similar_impl_candidates, we iterate through every pending obligation in the errors, and print them out as ahelphint.Potential Issues
This is my first contribution to the Rust compiler project. I'm not sure of the best way to present the error messages, or handle them anywhere else in the codebase. If there are better ways to implement the improvement, I'm happy to modify the PR according to the suggestions.
An unresolved issue here is that the fix is only implemented for the old Rust trait solver. Compared to
OldSolverError, I don't see thepending_obligationsfield to be present insideNextSolverError. So I'm unsure of the best way to keep this forward compatible with the upcoming trait solver.I'm also not sure if the fix here would produce too noisy errors outside of my specific use case. When I test this fix with more complex projects that I have, the error messages may contain many unresolved constraints. However when scanning through all items, I determined that none of the listed unresolved constraints should be considered uninformative noise. Hence, I do think that it is essential to have all unresolved constraints listed in the error message.