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

Fixed build failures of simd feature on the latest rust nightly #98

Closed
wants to merge 0 commits into from
Closed

Fixed build failures of simd feature on the latest rust nightly #98

wants to merge 0 commits into from

Conversation

programingjd
Copy link
Contributor

The simd feature requires nightly to build, but it doesn't build on the latest nightly because of the dependency on packed_simd_2.

error: unrecognized platform-specific intrinsic function: `simd_shuffle2`
...

There's an issue on the packed_simd repo related to this build failure: Issue 356

I have applied the suggested changes to fix the build: replaced the dependency on packed_simd_2 0.3.8 with a dependency on packed_simd 0.3.9.

Copy link
Contributor

@nyurik nyurik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good overall! Needs a rebase, and there are a few minor things

@@ -0,0 +1,4 @@
[toolchain]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we would want to have nightly toolchain by default. Instead, I think it would be better to add a justfile recipe to compile simd version -- and pass all the needed parameters via the command line.

Cargo.toml Outdated
Comment on lines 33 to 37

[dependencies.packed_simd]
git = "https://github.com/programingjd/packed_simd.git"
default-features = false
features = ["into_bits"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we put these inline inside the [dependencies] section? Makes it more readable IMO, vs looking at a dedicated section. Also, this will need to be tied to a specific git revision (or at least a tag or a branch).

Suggested change
[dependencies.packed_simd]
git = "https://github.com/programingjd/packed_simd.git"
default-features = false
features = ["into_bits"]
"packed_simd" = { default-features = false, features = ["into_bits"], git = "https://github.com/programingjd/packed_simd.git" }

@@ -132,7 +132,7 @@ impl <ReturnValue:Send+'static,
if local_queue.shutdown{
break;
} else {
let _ = cvar.wait(local_queue); // unlock immediately, unfortunately
let _lock = cvar.wait(local_queue); // unlock immediately, unfortunately
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you need a named var?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because if the variable isn't named, we get this error:

error: non-binding let on a synchronization lock                                                                                                                                                                                                                                                    
   --> src\enc\worker_pool.rs:135:19
    |
135 |               let _ = cvar.wait(local_queue); // unlock immediately, unfortunately
    |                   ^ this lock is not assigned to a binding and is immediately dropped

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Does it conflict with the comment then? Since we don't unlock immediately? I think the comment may need an update/explanation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comment still makes sense since the lock is dropped right after the continue on next line, isn't it?

@nyurik
Copy link
Contributor

nyurik commented Feb 21, 2024

why closing?

@programingjd
Copy link
Contributor Author

Sorry, I rebased and then I didn't know how to update the pull request. I tried to sync my fork and it auto-closed the pull request.
My fork is rebased now. Should I resubmit a pull request or is there a way to update this one?

@nyurik
Copy link
Contributor

nyurik commented Feb 21, 2024

Weird - usually you just do a git push -f into your own branch (after rebase), and that will auto-update the PR

@programingjd
Copy link
Contributor Author

I've opened a new pull request. Sorry about the mess.

@nyurik
Copy link
Contributor

nyurik commented Feb 21, 2024

Continued in #140

@programingjd note that you can also submit a PR against https://github.com/rust-brotli/rust-brotli -- this way it will auto-build with CI

Github allows you to create a PR from the same branch against multiple repos

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants