-
Notifications
You must be signed in to change notification settings - Fork 74
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
Stop using old-style simd_shuffle
#350
Conversation
Will be landing #352 first. |
@oli-obk In the newly-introduced CI, the toolchain is pinned to a specific nightly. This PR should probably unpin it, unless there's some other inscrutable compiler error barring that. Note that I am happy to call this "passing" CI if we still have 26 successes and 7 failures on CI. |
how the fuck was that legal |
...hmm. |
I swear I am going to set this repo on fire. |
CI why are you like this. |
Ah there we go. |
It is currently tracked separately from rust-toolchain.toml
64dfa4b
to
c6a25c5
Compare
Thank you! I will try to land some more CI fixes/PRs and then cut 3.9 soon! |
…workingjubilee Forbid old-style `simd_shuffleN` intrinsics Don't merge before rust-lang/packed_simd#350 has made its way to crates.io We used to support specifying the lane length of simd_shuffle ops by attaching the lane length to the name of the intrinsic (like `simd_shuffle16`). After this PR, you cannot do that anymore, and need to instead either rely on inference of the `idx` argument type or specify it as `simd_shuffle::<_, [u32; 16], _>`. r? `@workingjubilee`
Found while fixing rust-lang/rust#113500 (this PR is not necessary, but will allow us to make the compiler simpler)