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

Array (i.e. the type) methods aren't recognized #9992

Closed
yotamofek opened this issue Aug 22, 2021 · 0 comments
Closed

Array (i.e. the type) methods aren't recognized #9992

yotamofek opened this issue Aug 22, 2021 · 0 comments
Labels
A-nameres name, path and module resolution S-actionable Someone could pick this issue up and work on it right now

Comments

@yotamofek
Copy link
Contributor

Noticed that most of the methods that are defined directly on the core array type are not recognized by rust-analyzer. It also, by extension I guess, breaks type inference.

#![feature(array_methods)]

fn test() {
    let a = [(); 0].each_ref();
}

each_ref doesn't work for "go to def" command, nor does type info on hover. This is also true for (at least) Array::map, each_ref and as_slice, didn't check every single one.

@lnicola lnicola added A-nameres name, path and module resolution S-actionable Someone could pick this issue up and work on it right now labels Aug 22, 2021
bors bot added a commit that referenced this issue Aug 31, 2021
10097: fix: Allow inherent impls for arrays r=jonas-schievink a=jonas-schievink

Part of #9992 (method resolution of these methods still does not work)

bors r+

Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
bors bot added a commit that referenced this issue 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
Labels
A-nameres name, path and module resolution S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

2 participants