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: Go to implementation of trait methods #12549

Merged
merged 16 commits into from Jul 18, 2022

Conversation

bitgaoshu
Copy link
Contributor

try goto where the trait method implies, #4558

bitgaoshu and others added 4 commits June 23, 2022 14:01
 - remove Valid, it serves no purpose and just obscures the diff
 - rename some things
 - don't use is_valid_candidate when searching for impl, it's not necessary
@flodiebold
Copy link
Member

Hi, thanks for working on this and sorry for the delay!

I've taken the liberty of changing some things in the hir_ty parts of this, mostly renaming things and removing Valid because it didn't really do anything except make the diff harder to read. I also removed the usage of is_valid_candidate because as far as I can tell, it's not necessary when we already know the trait that is being used.

I'm still a bit unsure about the frontend parts though. For one thing, it's a bit awkward to special-case this for functions, because it should just as well work for associated constants and types. Also, finding the implementation should really already happen in IdentClass::classify_token and not after the fact (try_find_trait_item_definition is IMO not the right place for this, but maybe @Veykril has some thoughts on this).

@flodiebold flodiebold changed the title feat: try goto where trait method implies feat: Go to implementation of trait methods Jun 23, 2022
@Veykril
Copy link
Member

Veykril commented Jun 23, 2022

classify_token_to_impl shouldn't be a thing like that. This resolution should be done in NameRefClass::classify, in fact I don't think there should be any changes to the defs.rs module at all. This PR should affect Semantics::resolve_method_call (for method calls) and Semantics::resolve_path (for function calls) directly or indirectly by changing what these two methods make use of.

So I'd expect the following things to be "specialized" for this:

pub(crate) fn resolve_method_call(
&self,
db: &dyn HirDatabase,
call: &ast::MethodCallExpr,
) -> Option<(FunctionId, Substitution)> {
let expr_id = self.expr_id(db, &call.clone().into())?;
self.infer.as_ref()?.method_resolution(expr_id)
}

and
if let Some(path_expr) = parent().and_then(ast::PathExpr::cast) {
let expr_id = self.expr_id(db, &path_expr.into())?;
let infer = self.infer.as_ref()?;
if let Some(assoc) = infer.assoc_resolutions_for_expr(expr_id) {
return Some(PathResolution::Def(AssocItem::from(assoc).into()));
}

@bitgaoshu
Copy link
Contributor Author

finding the implementation should really already happen in IdentClass::classify_token

This resolution should be done in NameRefClass::classify, in fact I don't think there should be any changes to the defs.rs module at all

yes, my first thought is like that. Then I find it would affect other functionality, like rename.
Then I need tell IdentClass::classify_token , "I want function's impl" , or would affect other functionality.

which is better? in goto_.rs or defs.rs or else?

@Veykril
Copy link
Member

Veykril commented Jun 24, 2022

rename currently has some special casing around the old behaviour and I imagine the goto stuff might as well (or it just has tests that need to be updated). You would need to update those special cases, we should still do the change source_analyzer

@bitgaoshu
Copy link
Contributor Author

I run cargo test in local succeed.

@Veykril
Copy link
Member

Veykril commented Jun 24, 2022

The failing tests in CI are slow-tests which don't run by default as they are stubbed out if a specific ENV var isn't set.

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.

One more small nit from me.

crates/ide-db/src/rename.rs Outdated Show resolved Hide resolved
@Veykril
Copy link
Member

Veykril commented Jul 17, 2022

@flodiebold is this also okay from your PoV? With my nit fixed I'd be inclinced to merge this in that case (after tomorrows release, just to be safe)

@flodiebold
Copy link
Member

Yes, the HIR parts are fine for me.

Since this PR has been a long time coming, maybe we could err on the side of merging and fix the nit separately 😉

@Veykril
Copy link
Member

Veykril commented Jul 17, 2022

Sure, I can fix that one up myself, though I'd still like to wait with merging until after the next release just to be safe :)

@Veykril
Copy link
Member

Veykril commented Jul 18, 2022

Let's get this merged now, very excited about this :)
@bors r+

@bors
Copy link
Collaborator

bors commented Jul 18, 2022

📌 Commit dcb4837 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Jul 18, 2022

⌛ Testing commit dcb4837 with merge c40a60b...

bors added a commit that referenced this pull request Jul 18, 2022
feat: Go to implementation of trait methods

try goto where the trait method implies,  #4558
@bors
Copy link
Collaborator

bors commented Jul 18, 2022

💔 Test failed - checks-actions

@Veykril
Copy link
Member

Veykril commented Jul 18, 2022

Looks like something was made private that the PR is using, will fix that up

@Veykril
Copy link
Member

Veykril commented Jul 18, 2022

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 18, 2022

📌 Commit 38c11be has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Jul 18, 2022

⌛ Testing commit 38c11be with merge 22e53f1...

@bors
Copy link
Collaborator

bors commented Jul 18, 2022

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

@bors bors merged commit 22e53f1 into rust-lang:master Jul 18, 2022
@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

So this is what I feared, this makes some IDE stuff rather slow. Syntax highlighting in bigger files is even worse now than it already is 😓

@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

574ms - trait_impls_in_deps_query (162 calls)
156ms - trait_solve::wait (1418 calls)

Is this just validation taking ages again? We get this on every keystroke even though trait_impls_in_deps_query shouldnt change I think?

@bitgaoshu
Copy link
Contributor Author

sorry about that. i looked back my commits. My initial commit is only affect goto type. but now it seems not. it always try resolve impl when need resolve function . and i think it’s no need.

@Veykril
Copy link
Member

Veykril commented Jul 20, 2022

Yes, the thing is the way its done now is the proper way, name classification should work they way it does now after this PR. It's just unfortunate that for highlighting this isn't really relevant at all and kind of expensive.

bors added a commit that referenced this pull request Jul 21, 2022
fix: Fix `trait_impls_in_deps_query` being called directly instead of as a query

Fixes the inlay hint performance regression introdcuced by #12549
bors added a commit that referenced this pull request Jul 21, 2022
fix: Fix `trait_impls_in_deps_query` being called directly instead of as a query

Fixes the inlay hint performance regression introdcuced by #12549
@lnicola
Copy link
Member

lnicola commented Jul 25, 2022

trait-to-impl.mp4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants