Eagerly normalize HIR paths in new trait solver#113473
Eagerly normalize HIR paths in new trait solver#113473compiler-errors wants to merge 1 commit intorust-lang:masterfrom
Conversation
|
I think always using Make the fields of
|
|
@lcnr: In that case, I think I'd just rather put structurally_resolved_ty calls in all of the places where we actually require a structurally resolved type in hir typeck, rather than adding a 3rd field to |
That's also fine 👍 |
|
Actually, changing all the places where I would try the 3 field option above, but literally every current usage of |
cc9bb78 to
4973567
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
| ) -> Ty<'tcx> { | ||
| let container = self.to_ty(container).normalized; | ||
| // We only need to normalize in the old solver | ||
| let container = self.normalize(expr.span, self.to_ty(container)); |
There was a problem hiding this comment.
do we not normalize in the structurally_resolve_type inside of the loop?
There was a problem hiding this comment.
No, structurally resolve only processes obligations in the old solver
| }; | ||
|
|
||
| // FIXME(-Ztrait-solver=next): Can use `try_structurally_resolve` after migration. | ||
| let normalized = |
There was a problem hiding this comment.
| let normalized = | |
| let normalized_ty = |
| self.handle_raw_ty(span, tcx.at(span).type_of(impl_def_id).instantiate_identity()); | ||
| match ty.normalized.ty_adt_def() { | ||
| let ty = tcx.at(span).type_of(impl_def_id).instantiate_identity(); | ||
| let normalized = self.structurally_normalize_after_astconv(span, ty); |
There was a problem hiding this comment.
| let normalized = self.structurally_normalize_after_astconv(span, ty); | |
| let normalized_ty = self.structurally_normalize_after_astconv(span, ty); |
| &[], | ||
| has_self, | ||
| self_ty.map(|s| s.raw), | ||
| self_ty.map(|s| s), |
There was a problem hiding this comment.
| self_ty.map(|s| s), | |
| self_ty, |
?
| ) -> Result<(&'tcx ty::VariantDef, Ty<'tcx>), ErrorGuaranteed> { | ||
| let path_span = qpath.span(); | ||
| let (def, ty) = self.finish_resolving_struct_path(qpath, path_span, hir_id); | ||
| let normalized = self.structurally_normalize_after_astconv(path_span, ty); |
There was a problem hiding this comment.
| let normalized = self.structurally_normalize_after_astconv(path_span, ty); | |
| let normalized_ty = self.structurally_normalize_after_astconv(path_span, ty); |
|
|
||
| // FIXME(-Ztrait-solver=next): This could be replaced with `try_structurally_resolve` | ||
| // calls after the new trait solver is stable. | ||
| /// TODO: I don't know what to call this. |
There was a problem hiding this comment.
why is that method needed 🤔 because we don't want to normalize with the old solver here?
There was a problem hiding this comment.
No, because we need to normalize with the old solver here. This one calls the version of normalize that does both.
|
☔ The latest upstream changes (presumably #113199) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@compiler-errors FYI: when a PR is ready for review, send a message containing |
|
I really don't have the patience to rework this PR. The way that |
always normalize `LoweredTy` in the new solver I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt The infer var replacement for ambiguous projections can in very rare cases: - weaken inference rust-lang/trait-system-refactor-initiative#81 - strengthen inference rust-lang/trait-system-refactor-initiative#7 I do not expect this impact on inference to significantly affect real crates. r? `@compiler-errors`
always normalize `LoweredTy` in the new solver I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt The infer var replacement for ambiguous projections can in very rare cases: - weaken inference rust-lang/trait-system-refactor-initiative#81 - strengthen inference rust-lang/trait-system-refactor-initiative#7 I do not expect this impact on inference to significantly affect real crates. r? ``@compiler-errors``
Rollup merge of rust-lang#120378 - lcnr:normalize-ast, r=compiler-errors always normalize `LoweredTy` in the new solver I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt The infer var replacement for ambiguous projections can in very rare cases: - weaken inference rust-lang/trait-system-refactor-initiative#81 - strengthen inference rust-lang/trait-system-refactor-initiative#7 I do not expect this impact on inference to significantly affect real crates. r? ``@compiler-errors``
TODO: needs a new description now
r? @lcnr