Fix method resolution for inherent array impls #10017
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The first change is correct. Changing how arrays are derefed is not the right thing to do though. To get this working properly, we'll probably need to implement some more of const generics (in particular, lowering them during type lowering), which is a bigger refactoring. I would actually expect it to somewhat work though, since we treat unknown consts as 'equal' to other consts. |
|
@flodiebold thanks for taking a look. |
bors bot
added a commit
that referenced
this pull request
Sep 8, 2021
10180: Fix resolution for inherent array methods r=flodiebold a=yotamofek My second attempt at fixing #9992 , previous attempt was here: #10017 , but the logic was broken. I know that this is not an ideal solution.... that would require, IIUC, a pretty big overhaul of the const generics handling in `rust-analyzer`. But, given that some of the array methods were/are being stabilized (e.g. rust-lang/rust#87174 ), I think it'll be very beneficial to `rust-analyzer` users to have some preliminary support for them. (I know it's something I've been running into quite a lot lately :) ) As far as my limited understanding of this project's architecture goes, I think this isn't the worst hack in the world, and shouldn't be too much of a hassle to undo if/when const generics become better supported. If the maintainers deem this approach viable, I'll want to add some comments, emphasizing the purpose of this code, and that it should be removed at some point in the future. Co-authored-by: Yotam Ofek <yotam.ofek@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've been trying to solve #9992 on my own, even though I really don't understand the internals of
rust-analyzerenough, but I hacked up something that seems to solve the issue!As far as I can tell, the problem with resolving methods from std's (pretty recently added) impls on array, was caused by two separate issues, which are fixed by the two separate commits in this PR:
TyKind::Arraywere not registered forTyFingerprint::Arrayrust-analyzer, are registered for[T; {unknown}], while the receiver has a concrete len. I added the array Ty with an unknown const len as one of the targets for auto-derefing, which makesis_valid_candidatecorrectly returntruein these cases.So just to re-iterate, I have no idea if these changes actually make sense, but I thought opening a PR is worth a shot. :) And if not, I would love to get some pointers and keep working on this.
Thanks!