Skip to content
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

Closed
nikomatsakis opened this issue Jan 17, 2016 · 8 comments
Closed

Error reporting for trait failures should give backtrace #30976

nikomatsakis opened this issue Jan 17, 2016 · 8 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-traits Area: Trait system C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

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 that Foo: ?Debug, then we would print something like:

  • Vec<Box<Foo>>: Debug does not hold
    • impl from stdlib for Vec does not apply because Box<Foo>: Debug does not hold:
    • impl from stdlib for Box does not apply because Foo: Debug does not hold:
    • no impl of Debug for Foo found

As 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

@nikomatsakis nikomatsakis added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-traits Area: Trait system T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 17, 2016
@nikomatsakis nikomatsakis changed the title Error reporting can now give backtrace Error reporting for trait failures should give backtrace Jan 17, 2016
@huonw huonw added the A-diagnostics Area: Messages for errors, warnings, and lints label Jan 17, 2016
@aturon
Copy link
Member

aturon commented Jan 19, 2016

I'd like to take this on, but wanted to check in with @arielb1 -- were you thinking of doing this?

@arielb1
Copy link
Contributor

arielb1 commented Jan 19, 2016

I will try to do it today.

@GuillaumeGomez
Copy link
Member

Any news on this?

@golddranks
Copy link
Contributor

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:
https://www.reddit.com/r/rust/comments/49414d/reference_must_be_valid_for_the_static_lifetime/d0pgtos

@steveklabnik steveklabnik removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 9, 2017
@steveklabnik
Copy link
Member

Triage: this seems like a huge feature. @nikomatsakis is there any possibility of something like Chalk making this feasible?

@arielb1
Copy link
Contributor

arielb1 commented Sep 24, 2018

@steveklabnik

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.

@crlf0710 crlf0710 added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 11, 2020
@estebank
Copy link
Contributor

I believe that the current output of ObligationCauses fulfills the original request of this ticket.

@estebank
Copy link
Contributor

I still believe this is done. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-traits Area: Trait system C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants