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

feat: resolve inherent and implemented associated items in docs #15933

Merged
merged 1 commit into from
Jan 3, 2024

Conversation

71
Copy link
Contributor

@71 71 commented Nov 19, 2023

This partially fixes #9694.

Supported:

  • Trait methods and constants.
    • Due to resolution differences pointed out during the review of the PR, trait associated types are not supported.
  • Inherent methods, constants and associated types.
    • Inherent associated types are a nightly feature, and are supported with no additional work in this PR.

Screenshot of VS Code running with the change:

image

You can see that the items are resolved (excl. trait associated types) since they are semantically highlighted in the doc comment.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 19, 2023
@71 71 marked this pull request as ready for review November 19, 2023 13:09
Comment on lines 1447 to 1452
// Q: should this branch be restricted to `iterate_trait_item_candidates()`?
//
// the code below does not seem to be called when adding tests to
// `method_resolution.rs`, so resolution of type aliases is likely performed at some
// other point. due to the marks below, however, the test which ensures that marks have
// corresponding checks will fail
Copy link
Member

Choose a reason for hiding this comment

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

inherent type aliases aren't implemented in r-a, so it would not surprise me that the checks here are unreachable in inherent impls

@@ -154,7 +154,6 @@ pub(crate) fn complete_pattern_path(
}

ctx.iterate_path_candidates(&ty, |item| match item {
AssocItem::TypeAlias(ta) => acc.add_type_alias(ctx, ta),
Copy link
Member

Choose a reason for hiding this comment

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

Why is this gone now?

Copy link
Contributor Author

@71 71 Nov 27, 2023

Choose a reason for hiding this comment

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

Without removing this, a couple of snapshot tests fail because completions for type aliases are emitted several times / duplicated. I figured this code was a added to work around the fact that method_resolution.rs did not consider TypeAliases, which changed in this PR, so I removed these explicit iterations over TypeAliases.

Same for all your other comments for changes in src/completions/*. This is the main thing I'm uncertain about in this PR; it looks like adding support for TypeAliases had impacts in other parts of the code (which led me to make these changes, hence the question "should be only handle TypeAliases when resolving doc comments" above).

With that said, it looks like handling TypeAliases in a generic way in method_resolution.rs allows us to explicitly handle them in other parts of the codebase, so this may be a good thing. I am not aware of why it was handled differently before, though; it's possible that there were strong reasons for handling it differently which this PR breaks (subtly enough that additional tests do not fail).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For instance if I undo this particular diff, I get the following test failure:

---- tests::pattern::enum_qualified stdout ----


error: expect test failed
   --> crates/ide-completion/src/tests/pattern.rs:314:9

You can update all `expect!` tests by running:

    env UPDATE_EXPECT=1 cargo test

To update a single test, place the cursor on `expect` token and use `run` feature of rust-analyzer.

Expect:
----
ct ASSOC_CONST const ASSOC_CONST: ()
bn RecordV {…} RecordV { field$1 }$0
bn TupleV(…)   TupleV($1)$0
bn UnitV       UnitV$0

----

Actual:
----
ct ASSOC_CONST const ASSOC_CONST: ()
ta AssocType   type AssocType = ()
bn RecordV {…} RecordV { field$1 }$0
bn TupleV(…)   TupleV($1)$0
bn UnitV       UnitV$0

----

Diff:
----
ct ASSOC_CONST const ASSOC_CONST: ()
ta AssocType   type AssocType = ()    (NOTE: THIS LINE WAS ADDED)
bn RecordV {…} RecordV { field$1 }$0
bn TupleV(…)   TupleV($1)$0
bn UnitV       UnitV$0

----

For this particular case it looks like the problem is that the AssocType is wrongly suggested, but I do remember that for other changes there were duplicate completions.

@@ -124,14 +111,6 @@ pub(crate) fn complete_expr_path(
ctx.iterate_path_candidates(&ty, |item| {
add_assoc_item(acc, item);
});

// Iterate assoc types separately
ty.iterate_assoc_items(ctx.db, ctx.krate, |item| {
Copy link
Member

Choose a reason for hiding this comment

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

Why is this removed now?

}
Qualified::With { resolution: None, .. } => {}
Qualified::With { resolution: Some(resolution), .. } => {
// Add associated types on type parameters and `Self`.
ctx.scope.assoc_type_shorthand_candidates(resolution, |_, alias| {
Copy link
Member

Choose a reason for hiding this comment

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

same question here

@@ -67,22 +67,9 @@ pub(crate) fn complete_expr_path(
ctx.iterate_path_candidates(ty, |item| {
add_assoc_item(acc, item);
});

// Iterate assoc types separately
ty.iterate_assoc_items(ctx.db, ctx.krate, |item| {
Copy link
Member

Choose a reason for hiding this comment

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

and here

hir::AssocItem::Function(_) | hir::AssocItem::Const(_) => (),
hir::AssocItem::TypeAlias(ty) => acc.add_type_alias(ctx, ty),
hir::AssocItem::Function(_) | hir::AssocItem::Const(_) | hir::AssocItem::TypeAlias(_) => (),
Copy link
Member

Choose a reason for hiding this comment

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

why this change?

}
}

// Q: is it correct to use the same check as `ConstId`?
Copy link
Member

Choose a reason for hiding this comment

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

Should be alright

Copy link
Member

@Veykril Veykril left a comment

Choose a reason for hiding this comment

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

So (finally) revisiting this, it seems weird that method probing / resolution now also supports type aliases, as their resolution works a bit differently. So this seems to be the wrong way to approach this. We might just need to somehow expose a similar API but for type alias resolution that can be used for the doc resolution, I am unsure in what way though.

@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 Jan 2, 2024
@Veykril
Copy link
Member

Veykril commented Jan 3, 2024

Can you squash the last two commits into one? (Or all three up to you), the last commit will noise up git blame unnecessarily.

@71
Copy link
Contributor Author

71 commented Jan 3, 2024

I removed support for type aliases and tried reusing existing features more than before, which significantly simplified the PR.

@71 71 requested a review from Veykril January 3, 2024 14:05
@Veykril
Copy link
Member

Veykril commented Jan 3, 2024

Thanks! I've wanted this for a long time.
@bors r+

@bors
Copy link
Contributor

bors commented Jan 3, 2024

📌 Commit fe6f931 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jan 3, 2024

⌛ Testing commit fe6f931 with merge c3c07c6...

@bors
Copy link
Contributor

bors commented Jan 3, 2024

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing c3c07c6 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support doc links to associated functions on other structs
4 participants