Skip to content
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

FIX: generic parameters handling by the generate_delegate_trait assist #15520

Closed

Conversation

ponyii
Copy link
Contributor

@ponyii ponyii commented Aug 27, 2023

A part of #15108
I'm going to write a separate PR to solve the problem completely; currently only impl bofy generation is fixed, but generation of the impl ... line itself is to be overhauled.

The code might look somewhat complicated, but basically the changes are as follows:

  1. the destribution of generic params between trait and type is memorized (see item_tree.rs);
  2. the path transformation source scope is updated to handle generic params correctly (see generate_delegate_trait.rs)

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 27, 2023
@ponyii ponyii force-pushed the fix/delegate-trait-impl-assist branch from d42e56d to 001952d Compare August 27, 2023 12:44
@ponyii ponyii marked this pull request as ready for review August 28, 2023 19:00
@ponyii
Copy link
Contributor Author

ponyii commented Aug 28, 2023

@Veykril, hello! It seems natural to request your review here

Comment on lines 699 to 721
#[derive(Debug, Clone, Eq, PartialEq, Hash)]
pub struct GenericParamGroups {
// pub target_trait: Option<Vec<String>>,
pub self_ty: Option<Vec<String>>,
}

impl GenericParamGroups {
fn from_impl(impl_: &ast::Impl) -> Self {
Self {
// target_trait: Self::get_arg_list(impl_.trait_()),
self_ty: Self::get_arg_list(impl_.self_ty()),
}
}

fn get_arg_list(ty: Option<ast::Type>) -> Option<Vec<String>> {
let list = match ty? {
ast::Type::PathType(p) => p.path()?.segment()?.generic_arg_list(),
_ => None,
};
Some(list?.generic_args().map(|arg| arg.syntax().text().to_string()).collect())
}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the wrong way too approach this. The fix to the issue here should not involve touching item tree whatsoever.

Copy link
Contributor Author

@ponyii ponyii Sep 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to touch it, I'm afraid.

Let's have a look on few relevant lines from the test:

struct S(Foo<i32, bool>);
...
impl<A, B, C> Trait<A, B> for Foo<C, B> { ... }

In this case the assist should turn C and B into i32 and bool repectively. In general, it should get Foo-related generic arguments from the trait implementation and correlate them Foo's parameters within the structure. Consequently, we have to memorize the "distribution" of the generic arguments in impl lines; that's exactly what happens in this file - the names of args pertaining to self_ty are being saved.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That data is already encoded in the sekf_ty TypeRef in the item tree. So you just need to fetch that from there instead, that is check if the TypeRef is a TypeRef::Path and take the generic args from that path instead

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Now these data are fetched from Type instead of TypeRef, but anyway the item tree is unchanged

crates/hir/src/lib.rs Show resolved Hide resolved
@Veykril Veykril added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 8, 2023
@ponyii ponyii requested a review from Veykril September 8, 2023 09:36
@bors
Copy link
Collaborator

bors commented Nov 14, 2023

☔ The latest upstream changes (presumably #15891) made this pull request unmergeable. Please resolve the merge conflicts.

@Veykril Veykril added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 2, 2024
@Veykril
Copy link
Member

Veykril commented Jan 2, 2024

The linked issue has been fixed by a heavy rewrite of the assist in #16112, so sorry for not merging this now, but thanks anyways for your contribution!

@Veykril Veykril closed this Jan 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants