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

Be more careful about elaboration around trait aliases #104745

Closed

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Nov 22, 2022

Fixes four separate (but similar) bugs that were found when it comes to trait aliases, for which the traits::util::elaborate_* methods can return predicates that have a different Self type than the one we started with.

Fixes #104719
Fixes #106238

@rustbot
Copy link
Collaborator

rustbot commented Nov 22, 2022

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

@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 Nov 22, 2022
@bors
Copy link
Contributor

bors commented Nov 23, 2022

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

@bors
Copy link
Contributor

bors commented Nov 25, 2022

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

@jackh726
Copy link
Member

I'm a bit on the fence for this. Seems like there is a better solution to find than filtering predicates in a lot of places.

@compiler-errors
Copy link
Member Author

@jackh726 that's kind of vague -- what better solution are you suggesting?

The fact is that it's really up to the specific code doing the elaboration whether it needs to care about supertraits that share a Self type versus those that don't. We could push this distinction up into the elaboration methods themselves, I guess, but something needs to be doing this filtering.

@jackh726
Copy link
Member

jackh726 commented Jan 7, 2023

It's pretty vague because I don't quite know the right solution - but whatever it is, I don't think it's this. Pushing this up to to elaboration seems reasonable?

bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 12, 2023
…filter-only-super-traits, r=oli-obk

Split implied and super predicate queries, then allow elaborator to filter only supertraits

Split the `super_predicates_of` query into a new `implied_predicates_of` query. The former now only returns the *real* supertraits of a trait alias, and the latter now returns the implied predicates (which include all of the `where` clauses of the trait alias). The behavior of these queries is identical for regular traits.

Now that the two queries are split, we can add a new filter method to the elaborator, `filter_only_self()`, which can be used in instances that we need only the *supertrait* predicates, such as during the elaboration used in closure signature deduction. This toggles the usage of `super_predicates_of` instead of `implied_predicates_of` during elaboration of a trait predicate.

This supersedes rust-lang#104745, and fixes the four independent bugs identified in that PR.
Fixes rust-lang#104719
Fixes rust-lang#106238
Fixes rust-lang#110023
Fixes rust-lang#109514

r? types
@compiler-errors compiler-errors deleted the elaboration-is-weird branch August 11, 2023 20:00
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.

Trait alias: Add trait + dyn causes compiler panic Future in trait_alias causes internal compiler error ?
4 participants