-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Error reporting for trait cycles could be improved #30974
Copy link
Copy link
Closed
Labels
A-trait-systemArea: Trait systemArea: Trait systemC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-trait-systemArea: Trait systemArea: Trait systemC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
The new fulfillment context from #30533 can detect and extract cycles in the trait resolution graph, but (for the most part) it still reports them the same way as any other overflow. We can do a lot better. In fact, it does do a lot better, for the
Sizedtrait in particular. This machinery could surely be adopted:We could probably stop aborting compilation too, but it'd be just a touch trickier. I think the most correct thing would be to refactor the fulfillment context interface to transmit back "overflow" as a distinct category from other errors. This is because overflow seems different from the absence of an impl. OTOH, I'm not sure if this matters in practice, particularly if we adapt the way we handle negative reasoning. Perhaps the absence of an impl and overflow can both be treated as an error in that case.
cc @aturon @arielb1