-
Notifications
You must be signed in to change notification settings - Fork 0
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
Ambiguity, differing outlives constraints with types equal modulo normalization #57
Comments
Interestingly, the code with fn main() {
let _: Box<dyn Iterator<Item=i32> + '_> = Box::new(vec![1].into_iter());
} |
This may be a problem somewhat specific to |
I think we should consider the three way split of "assemble blanket candidates", "assemble_normalization_step_candidates" and "assemble_candidates_via_self_ty" or whatever |
…nsize-to-dyn-once, r=lcnr Separate `consider_unsize_to_dyn_candidate` from other unsize candidates Move the unsize candidate assembly *just for* `T -> dyn Trait` out of `assemble_candidates_via_self_ty` so that we only consider it once, instead of for every normalization step of the self ty. This makes sure that we don't assemble several candidates that are equal modulo normalization when we really don't care about normalizing the self type of an `T: Unsize<dyn Trait>` goal anyways. Fixes rust-lang/trait-system-refactor-initiative#57 r? lcnr
When coercing
&'?0 <Vec<{integer}> as IntoIterator>::IntoIter
into&'?1 dyn Iterator<Item=i32>
, we end up with two responses.The first has a type-outlives constraint like
<Vec<{integer}> as IntoIterator>::IntoIter: &'?1
, and the second has one likestd::vec::IntoIter<{integer}>: &'?1
. These are identical except for their types being normalized, but that causes us to flounder.The text was updated successfully, but these errors were encountered: