-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Error reporting for trait failures should give backtrace #30976
Comments
I'd like to take this on, but wanted to check in with @arielb1 -- were you thinking of doing this? |
I will try to do it today. |
Any news on this? |
If I understand this issue correctly, this would help for the error messages to "bridge the gap" in problems like this: https://www.reddit.com/r/rust/comments/417s0f/question_about_generics_and_api_declarations/cz0cyse My question is: is there any similar diagnostic feature planned for backtracing lifetime obligations? I recently saw a problem where such an error message would've been very helpful: |
Triage: this seems like a huge feature. @nikomatsakis is there any possibility of something like Chalk making this feasible? |
I think we give trait error backtraces for quite some time, but they are somewhat badly-formatted, so this is somewhat of a diagnostic issue. |
I believe that the current output of |
I still believe this is done. Closing. |
Now that #30533 has landed, we can change how we report trait errors to give a complete backtrace. In fact, I suspect the most intuitive thing would be to start from the root obligation and print that, and then show the chain of reasoning which ultimately failed. For example, if we had
Vec<Box<Foo>>: Debug
and it turns out thatFoo: ?Debug
, then we would print something like:Vec<Box<Foo>>: Debug
does not holdVec
does not apply becauseBox<Foo>: Debug
does not hold:Box
does not apply becauseFoo: Debug
does not hold:Debug
forFoo
foundAs part of this, we will want to (I think) change how we assign "causes" to the subobligations. Currently, we propagate the cause of the root obligation. I think what we want to do instead is to assign a cause that indicates the impl whence the subobligation was created. That way, when printing the backtrace, we can walk through the impls and show them to the user.
PS, I know there is a duplicate of various existing bug reports. I didn't really look, but we should try to gather up all the various examples into one master bug. Perhaps this one?
cc @aturon @arielb1
The text was updated successfully, but these errors were encountered: