Always generate generics in delegation that match trait in trait impl scenario#153705
Always generate generics in delegation that match trait in trait impl scenario#153705aerooneqq wants to merge 1 commit intorust-lang:mainfrom
Conversation
This comment has been minimized.
This comment has been minimized.
f413a06 to
23a51f5
Compare
| #![allow(incomplete_features)] | ||
| #![allow(late_bound_lifetime_arguments)] | ||
|
|
||
| mod test_1 { |
There was a problem hiding this comment.
Could you add comments to every test case, similarly to the previous PR?
| Hir(DelegationGenerics<&'hir hir::Generics<'hir>>), | ||
| } | ||
|
|
||
| pub(super) enum PropagationKind { |
There was a problem hiding this comment.
Could you add a comment telling what is being propagated here?
| } | ||
| } | ||
|
|
||
| pub(super) fn can_propagate(&self) -> bool { |
There was a problem hiding this comment.
Trivial method, used once, doesn't access anything private, can be inlined.
| // method call will be supported (if HIR generics were not obtained | ||
| // then it means that we did not propagated them, thus we do not need | ||
| // to generate params). | ||
| // FIXME(fn_delegation): in impl trait case we still need to generate |
There was a problem hiding this comment.
"impl trait" usually means impl Trait like in fn foo() -> impl Trait { ... }.
impl Trait for Type { ... } is a "trait impl".
There was a problem hiding this comment.
(In PR title and description too.)
| let prop_kind = if res.is_some_and(|def_id| def_id == root_fn_id) { | ||
| PropagationKind::Allowed | ||
| } else { | ||
| PropagationKind::Forbidden |
There was a problem hiding this comment.
Right now the diagnostics are very bad.
Perhaps it's better to always propagate, but get some "wrong number of passed generic arguments" errors instead of "type annotations needed"? (At least when the generic arguments are not user-specified?)
After #151864 there is a change in delegation code generation in
trait implcases: after #151864 we started to look at user-specified args and generate functions, whose generics may not match the signature of the function that is defined in trait. Such handling of delegation from trait impl is not correct, as the generated function should always have the same generics as its signature function in trait.Considering propagation of generic params, in this PR we do it only if delegation path resolution matches the signature function, in other cases it is not obvious should we propagate generic params or not. As one option we may check generics of delegation path, and if they match generics of signature trait function then propagate them, but I think it is out of scope of this PR for now.
This addresses the "Fix generic params generation in trait impl case" future work from #151864
r? @petrochenkov