fix(ty): should query impls in nearest block

[bvanjoi]

fix #13895

[lowr]

Thanks for working on this, but I think the problem is much broader. As I commented in the original issue, impls are treated as top-level items in a module even if they are declared inside local blocks, unlike any other kind of items. So we should be able to resolve any associated functions/consts in any impls as long as the the assocs are visible from current module. Take a look at this playground, which rust-analyzer wouldn't be able to resolve the called methods even with this PR (yes I'm being pedantic but it's valid Rust that we should be able to analyze after all :/).

I think this is more of an architectural issue around hir rather than hir-ty. To correctly resolve associated items, we should look into every block in a crate to find impls, but I still haven't got clear vision of how to implement that without breaking current incremental model much.

(This can be a temporary solution that solves most cases though. I'm curious why Rust decided to treat impls differently)

[Veykril]

We don't support those kinds of impls globally intentionally, because doing so would be way too expensive and as you've said, breaks incremental. That kind of code where you split impls across different blocks is questionable in the first place and should be rare to encounter.

[lowr]

Makes sense, do we document it anywhere? I think it's worth noting.

[Veykril]

I don't think it is documented anywhere (only mentioned in some issue somewhere)

[lowr]

Got it, I might go about documenting it somewhere. Thanks for the clarification and sorry for the noise!

[Veykril]

@bors r+

[bors]

📌 Commit 9a15cc8 has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9a15cc8 with merge 75877d7...

[bors]

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