Since nightly-2024-02-06 , could not compile with --features 'simd-accel' #2748
Comments
|
This is more a report and a reference than a real bug, and I will be trying to make a pull request but anything simd-related is way above my knowledge. |
|
As documented in the README, I am considering just removing the In any case, I'm not tracking this issue here. There's an issue for it at the source: rust-lang/packed_simd#359 |
BurntSushi
added a commit
that referenced
this issue
Mar 7, 2024
This feature causes nothing but problems and is frequently broken. The only optimization it was enabling were SIMD optimizations for transcoding. In particular, for UTF-16 transcoding. This is performed by the [`encoding_rs`](https://github.com/hsivonen/encoding_rs) crate, which specifically uses unstable portable SIMD APIs instead of the stable non-portable SIMD APIs. SIMD optimizations that apply to search have long been making use of stable APIs, and are automatically enabled when your target supports them. This is, IMO, the correct user experience and one that `encoding_rs` refuses to support. I'm done dealing with it, so transcoding will only use scalar code until the SIMD optimizations in `encoding_rs` work on stable. (This doesn't mean that `encoding_rs` has to change. This could also be fixed by stabilizing `std::simd`.) Fixes #2748
BurntSushi
added a commit
that referenced
this issue
Mar 7, 2024
This feature causes nothing but problems and is frequently broken. The only optimization it was enabling were SIMD optimizations for transcoding. In particular, for UTF-16 transcoding. This is performed by the [`encoding_rs`](https://github.com/hsivonen/encoding_rs) crate, which specifically uses unstable portable SIMD APIs instead of the stable non-portable SIMD APIs. SIMD optimizations that apply to search have long been making use of stable APIs, and are automatically enabled when your target supports them. This is, IMO, the correct user experience and one that `encoding_rs` refuses to support. I'm done dealing with it, so transcoding will only use scalar code until the SIMD optimizations in `encoding_rs` work on stable. (This doesn't mean that `encoding_rs` has to change. This could also be fixed by stabilizing `std::simd`.) Fixes #2748
|
I ended up just removing |
|
Really nice ! Thanks for your time, and for your tools too. |
tmeijn
pushed a commit
to tmeijn/dotfiles
that referenced
this issue
Sep 13, 2024
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep) | patch | `14.1.0` -> `14.1.1` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>BurntSushi/ripgrep (BurntSushi/ripgrep)</summary> ### [`v14.1.1`](https://github.com/BurntSushi/ripgrep/blob/HEAD/CHANGELOG.md#1411-2024-09-08) [Compare Source](BurntSushi/ripgrep@14.1.0...14.1.1) \=================== This is a minor release with a bug fix for a matching bug. In particular, a bug was found that could cause ripgrep to ignore lines that should match. That is, false negatives. It is difficult to characterize the specific set of regexes in which this occurs as it requires multiple different optimization strategies to collide and produce an incorrect result. But as one reported example, in ripgrep, the regex `(?i:e.x|ex)` does not match `e-x` when it should. (This bug is a result of an inner literal optimization performed in the `grep-regex` crate and not in the `regex` crate.) Bug fixes: - [BUG #​2884](BurntSushi/ripgrep#2884): Fix bug where ripgrep could miss some matches that it should report. Miscellaneous: - [MISC #​2748](BurntSushi/ripgrep#2748): Remove ripgrep's `simd-accel` feature because it was frequently broken. </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40NDAuNyIsInVwZGF0ZWRJblZlciI6IjM3LjQ0MC43IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please tick this box to confirm you have reviewed the above.
What version of ripgrep are you using?
6ebebb2 (current master HEAD, few commits after 14.1.0)
How did you install ripgrep?
Trying to compiling it from source
What operating system are you using ripgrep on?
Ubuntu 20.04.6 LTS
Describe your bug.
Cannot compile
What are the steps to reproduce the behavior?
RUSTUP_TOOLCHAIN=nightly-2024-02-06 cargo build --features 'simd-accel' fails
RUSTUP_TOOLCHAIN=nightly-2024-02-05 cargo build --features 'simd-accel' works
Because:
Then in later nightly version :
related: rust-lang/rust@ea37e80
rust-lang/rust#117372
I don't know if this is actually a bug.
What is the actual behavior?
Cannot compile
What is the expected behavior?
Can compile
The text was updated successfully, but these errors were encountered: