-
Notifications
You must be signed in to change notification settings - Fork 182
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
Implement Impl Trait #324
Implement Impl Trait #324
Conversation
12bba67
to
12876a0
Compare
I'll definitely look over this later, but can you add the tests removed in 6252238? |
Thanks, that's really helpful! (wasn't aware that we had those tests) |
1351751
to
df2444a
Compare
ad46c01
to
0653845
Compare
99f2000
to
f42d8c1
Compare
795607b
to
65d118a
Compare
62e0ae4
to
123e0a8
Compare
Needs rebase now, @detrumi =) |
123e0a8
to
9fcbc21
Compare
43fcfef
to
32223e4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments, some of which probably require a bit more discussion to really act on. I am wondering also if we should carve out some slices of this PR to land (e.g., some of the parsing, maybe creating some core data structures, or generalizing AliasEq
to have an enum -- perhaps initially with just one variant for the existing placeholders)
b90a788
to
9e8d974
Compare
c01fe20
to
3b368bb
Compare
@nikomatsakis Could you make some time to do the review you were planning to do? |
Gah @detrumi sorry I forgot! Will try to do so now. |
I think the remaining test failures are because you have to modify the code that generates 'which program clauses might implement a given goal'. In particular, when you run the test, you are asked to prove;
that winds up in this match arm: chalk/chalk-solve/src/clauses.rs Line 147 in 4866423
this has logic for "things derived from traits and impls" and "things where dyn Trait is the self type" but we need some logic for "cases where an alias placeholder is the self type". Something like: if let /* AliasPlaceholder */ = self_ty.data(interner) {
db.opaque_type(...).to_program_clauses(...);
} (BTW, I find the debug output for impl trait types ( |
@detrumi I guess this is waiting on a rebase and then perhaps some more tests? It'd be good to create an updated list of what's left to do. I forget if we decided to defer handling of things generic opaque types like |
Yes, I started on the rebase but quite a lot of things changed last week, so that takes some work 😅 For what's left, the list in #335 is still fairly up-to-date, the only additional points are adding documentation and more tests, which I'd like to do in separate PRs. |
9393d0f
to
41121bf
Compare
@nikomatsakis Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, @detrumi, in doing the final review, I noted one thing I really do think we should fix before landing.
}); | ||
} | ||
|
||
for auto_trait_id in builder.db.auto_traits() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we need to get rid of this method, what I think we should be doing instead is to look and check:
If we are generate clauses for a goal like
Implemented(!T: Foo)
where !T
is an alias placeholder and Foo
is an auto-trait, then we generate these clauses, and otherwise we don't.
The to_program_clauses
trait doesn't work for this, but we can just a free function or another extension trait.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, so we generate such clauses only when there's such a goal. Somewhere around push_auto_trait_impls
probably?
Anyways, I'll just remove this part for now, I'll add it to the list for next steps. With the auto_traits
function removed, it should be ready to merge, right?
pub opaque_ty_ids: BTreeMap<Identifier, OpaqueTyId<ChalkIr>>, | ||
|
||
/// For each opaque type: | ||
pub opaque_ty_data: BTreeMap<OpaqueTyId<ChalkIr>, Arc<OpaqueTyDatum<ChalkIr>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be done in a follow-up PR, but I think we should add a opaque_names: BTreeMap<TraitId<ChalkIr>, Identifier>
or something like that, created during lowering...
opaque_ty: &OpaqueTy<ChalkIr>, | ||
fmt: &mut fmt::Formatter<'_>, | ||
) -> Result<(), fmt::Error> { | ||
write!(fmt, "impl {:?}", opaque_ty.opaque_ty_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...and then reference the opaque_type_names
here to print the name of the opaque type, and not "impl"
fmt: &mut fmt::Formatter<'_>, | ||
) -> Result<(), fmt::Error> { | ||
if let Some(d) = self.opaque_ty_data.get(&opaque_ty_id) { | ||
write!(fmt, "{:?}", d.bound.skip_binders().hidden_ty) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...or maybe here we want to print the name? anyway, somewhere. It'd be nice for opaque types to print out with their name and for the placeholders to print with !Foo
.
Part of #335