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

Provide array impls for arrays up to length 44 #51192

Closed
alex opened this issue May 29, 2018 · 9 comments
Closed

Provide array impls for arrays up to length 44 #51192

alex opened this issue May 29, 2018 · 9 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@alex
Copy link
Member

alex commented May 29, 2018

Currently various traits are provided for arrays up to length 32: https://github.com/rust-lang/rust/blob/master/src/libcore/array.rs#L259-L264

I'm requesting this be extended up to length 44.

Why? Because bindgen relies on AsMut<[T]> for fixed-size arrays, and the linux kernel has some structs with 44-element arrays. Providing impls up to length 44 would permit bindgening the full kernel headers without needing to whitelist/blacklist elements. I realize this is vaguely whack-a-mole, but it's a valuable use-case in my, 100% biased, opinion.

If this idea is acceptable, I'm happy to prepare a patch.

@varkor
Copy link
Member

varkor commented May 29, 2018

Once const generics are implemented, we'll be able to implement traits on arrays for any length. It's probably better to wait till then, rather than special-casing for a particular codebase now.

@alex
Copy link
Member Author

alex commented May 29, 2018

Yes, that's clearly the right long term solution. The nice thing about the short term solution is that I could have a patch in in an hour and be able to use it in tomorrow's nightly :-)

@Mark-Simulacrum Mark-Simulacrum added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jun 2, 2018
@alex
Copy link
Member Author

alex commented Jun 2, 2018

I've gone ahead and submitted #51318. If the core team has interest in this, the PR is available for consideration.

@mark-i-m
Copy link
Member

mark-i-m commented Jun 2, 2018

@alex How are you bindgen-ing linux kernel headers? TMK linux relies on a handful of gcc optimizations, attributes, and non-standard extensions, so you can't use clang to compile it. Is that outdated knowledge?

@mark-i-m
Copy link
Member

mark-i-m commented Jun 2, 2018

@varkor Is there an idea of how long it will be before basic const generics are ready? (btw, thanks for all your work on that!)

@varkor
Copy link
Member

varkor commented Jun 3, 2018

@mark-i-m: before the focus switched to the refactorings (which are now almost done), I felt we were relatively close to an initial implementation. It's hard to give a good estimate, because quite a lot has changed since then, but personally I'd really like to aim for something working by July or so (as soon as #48149 is merged, I think we'll be in a position to make swift headway).

@alex
Copy link
Member Author

alex commented Jun 3, 2018

@mark-i-m you can look at https://github.com/alex/linux-kernel-module-rust to see how it works. It seems to be working at any rate 🤷‍♂️

@mark-i-m
Copy link
Member

mark-i-m commented Jun 3, 2018

@alex It looks like it is close, but not quite there yet. https://lwn.net/Articles/734071/... It will probably work until you need touch a weirder data structure like struct page...

Anyway I don't want to derail the thread...

Given that const generics on nightly might be only a month away, my vote would be to wait...

@varkor
Copy link
Member

varkor commented Jun 3, 2019

There's a proper tracking issue for this here now: #61415.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants