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

Allow printing TraitRef and TraitPredicate with Infcx information #125262

Closed
wants to merge 4 commits into from

Conversation

BoxyUwU
Copy link
Member

@BoxyUwU BoxyUwU commented May 18, 2024

This PR is a bit of a mess apologies. I've tried to split up into two commits.

The first commit makes the Infcx in WithInfcx be stored inside of an Option and makes NoInfcx into an uninhabited type so that we do not have a type that is not anything like an Infcx implement the InferCtxtLike trait and then get constructed and passed to places that expect an infcx. Generally the "leafs" of debug printing do not share codepaths for printing with or without an infcx and so need to be able to determine which to use.

While updating the leaves to match on the Option I changed the debug printing of inference variables to be ?0_..t for when we cant probe the variable ?0 instead of "silently" downgrading to normal Debug printing. I'm not sure how valuable this is but it was easy to do and given how many places accidentally are not going through the DebugWithInfcx trait it seems valuable to be able to tell in logs if an inference variable is being printed through the wrong trait or just doesnt have a universe available.

As an example of not going through the right trait, it seems like the Ty: DebugWithInfcx impl just.... did not actually pass through to TyKind: DebugWithInfcx and so would not ever print out the universes ^^' fixed that in this commit too.

The second commit actually introduces the DebugWithInfcx implementations for TraitRef and TraitPredicate. Previously TraitPredicate was formatted as: TraitPredicate(<T as Trait<U>>, polarity::Positive) and now it is (T: Trait<U>). This should hopefully make reading debug logs involving lots of trait bounds easier (and it'll get a lot better with custom Binder Debug impls) TraitRef's formatting has not really changed. Previously it was <T as Trait<U>> and now it is (T as Trait<U>).

r? @compiler-errors

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 18, 2024
@@ -16,7 +16,7 @@ LL | / fn foo() -> Bar
LL | | where
LL | | Bar: Send,
| |______________^
= note: ...which requires revealing opaque types in `[Binder { value: TraitPredicate(<Bar as core::marker::Send>, polarity:Positive), bound_vars: [] }]`...
= note: ...which requires revealing opaque types in `[Binder { value: (Alias(Opaque, AliasTy { args: [], def_id: DefId(0:7 ~ in_where_clause[cb1b]::Bar::{opaque#0}) }): core::marker::Send), bound_vars: [] }]`...
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit unfortunate lol. we actually print the Tys in TraitPredicate/TraitRef using Debug now and the debug printing for aliases is not super concise

Copy link
Member Author

@BoxyUwU BoxyUwU left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@bors
Copy link
Contributor

bors commented May 19, 2024

☔ The latest upstream changes (presumably #125230) made this pull request unmergeable. Please resolve the merge conflicts.

@BoxyUwU BoxyUwU force-pushed the trait_ref_debug_printing branch from 4cde784 to 876d181 Compare May 19, 2024 11:59
@bors
Copy link
Contributor

bors commented May 21, 2024

☔ The latest upstream changes (presumably #125284) made this pull request unmergeable. Please resolve the merge conflicts.

@BoxyUwU BoxyUwU closed this Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants