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

[WIP] Implementation of RFC 2289 (associated_type_bounds) #57428

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@alexreg
Copy link
Contributor

alexreg commented Jan 7, 2019

This PR implements the asociated_type_bounds feature.

Very much a work-in-progress; do not review yet.

CC @nikomatsakis @Centril

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Jan 7, 2019

r? @michaelwoerister

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

@michaelwoerister

This comment has been minimized.

Copy link
Contributor

michaelwoerister commented Jan 8, 2019

r? @nikomatsakis for re-assignment.

WIP

@alexreg alexreg force-pushed the alexreg:associated_type_bounds branch from 77d2928 to 2e92e7f Jan 8, 2019

let parent_node_id = self.current_hir_id_owner.get(self.current_hir_id_owner.len() - 1).map(|i|
definitions.def_index_to_node_id(i.0));
let bounds = self.lower_param_bounds(b,
ImplTraitContext::Existential(None, parent_node_id));

This comment has been minimized.

@varkor

varkor Jan 9, 2019

Member

Why do the bounds have a different context to the generics?

This comment has been minimized.

@alexreg

alexreg Jan 9, 2019

Contributor

Because associated type bindings can appear in bounds, but not generics. i.e. you can have existential type Foo = Iterator<Item = impl Clone>;, but existential type Foo<Item = impl Clone> = ...; just makes no sense.

let generics = self.lower_generics(generics, ImplTraitContext::disallowed());

let definitions = self.resolver.definitions();
let parent_node_id = self.current_hir_id_owner.get(self.current_hir_id_owner.len() - 1).map(|i|

This comment has been minimized.

@varkor

varkor Jan 9, 2019

Member

Nit: it's more readable to write |(def_id, _)|, so it's clear even in the argument that it's a tuple.

This comment has been minimized.

@alexreg

alexreg Jan 9, 2019

Contributor

Good point. I usually write that; not sure why I didn't here.

@@ -1351,6 +1352,7 @@ impl<'a> LoweringContext<'a> {
.opt_def_index(exist_ty_node_id)
.unwrap();

let owner = explicit_owner.unwrap_or(exist_ty_node_id);

This comment has been minimized.

@varkor

varkor Jan 9, 2019

Member

Is this (intended to be) used anywhere?

This comment has been minimized.

@alexreg

alexreg Jan 9, 2019

Contributor

Maybe... it was experimentation, because I thought the problem might be that the generated existential type doesn't have the right HIR order or something. But it's probably not that in fact. Well, I'm not sure really.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment