shepmaster / jetscii Goto Github PK

View Code? Open in Web Editor NEW

106.0 11.0 19.0 160 KB

A tiny library to efficiently search strings for sets of ASCII characters and byte slices for sets of bytes.

License: Apache License 2.0

Rust 100.00%

jetscii's Introduction

Jetscii

A tiny library to efficiently search strings for sets of ASCII characters or byte slices for sets of bytes.

Examples

Searching for a set of ASCII characters

#[macro_use]
extern crate jetscii;

fn main() {
    let part_number = "86-J52:rev1";
    let first = ascii_chars!('-', ':').find(part_number);
    assert_eq!(first, Some(2));
}

Searching for a set of bytes

#[macro_use]
extern crate jetscii;

fn main() {
    let raw_data = [0x00, 0x01, 0x10, 0xFF, 0x42];
    let first = bytes!(0x01, 0x10).find(&raw_data);
    assert_eq!(first, Some(1));
}

Check out the documentation for information about feature flags and benchmarks.

Contributing

Fork it (https://github.com/shepmaster/jetscii/fork)
Create your feature branch (git checkout -b my-new-feature)
Add a failing test.
Add code to pass the test.
Commit your changes (git commit -am 'Add some feature')
Ensure tests pass.
Push to the branch (git push origin my-new-feature)
Create a new Pull Request

jetscii's People

Contributors

Stargazers

Watchers

Forkers

borman chris-morgan bluss veedrac sahwar rreverser acidburn0zzz ignatenkobrain global-localhost global19 global19-atlassian-net lqd martony38 tsnoam christoph-ak cstkingkey saethlin icodein dr-emann

jetscii's Issues

Relicense under dual MIT/Apache-2.0

This issue was automatically generated. Feel free to close without ceremony if
you do not agree with re-licensing or if it is not possible for other reasons.
Respond to @cmr with any questions or concerns, or pop over to
#rust-offtopic on IRC to discuss.

You're receiving this because someone (perhaps the project maintainer)
published a crates.io package with the license as "MIT" xor "Apache-2.0" and
the repository field pointing here.

TL;DR the Rust ecosystem is largely Apache-2.0. Being available under that
license is good for interoperation. The MIT license as an add-on can be nice
for GPLv2 projects to use your code.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback. However, this is not the
primary motivation for me creating these issues. The Apache license also has
protections from patent trolls and an explicit contribution licensing clause.
However, the Apache license is incompatible with GPLv2. This is why Rust is
dual-licensed as MIT/Apache (the "primary" license being Apache, MIT only for
GPLv2 compat), and doing so would be wise for this project. This also makes
this crate suitable for inclusion and unrestricted sharing in the Rust
standard distribution and other projects using dual MIT/Apache, such as my
personal ulterior motive, the Robigalia project.

Some ask, "Does this really apply to binary redistributions? Does MIT really
require reproducing the whole thing?" I'm not a lawyer, and I can't give legal
advice, but some Google Android apps include open source attributions using
this interpretation. Others also agree with
it.
But, again, the copyright notice redistribution is not the primary motivation
for the dual-licensing. It's stronger protections to licensees and better
interoperation with the wider Rust ecosystem.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright, due to not being a "creative
work", e.g. a typo fix) and then add the following to your README:

## License

Licensed under either of

 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, if you have them, use the following boilerplate
(based on that used in Rust):

// Copyright 2016 jetscii developers
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

It's commonly asked whether license headers are required. I'm not comfortable
making an official recommendation either way, but the Apache license
recommends it in their appendix on how to use the license.

Be sure to add the relevant LICENSE-{MIT,APACHE} files. You can copy these
from the Rust repo for a plain-text
version.

And don't forget to update the license metadata in your Cargo.toml to:

license = "MIT/Apache-2.0"

I'll be going through projects which agree to be relicensed and have approval
by the necessary contributors and doing this changes, so feel free to leave
the heavy lifting to me!

Contributor checkoff

To agree to relicensing, comment with :

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Or, if you're a contributor, you can check the box in this repo next to your
name. My scripts will pick this exact phrase up and check your checkbox, but
I'll come through and manually review this issue later as well.

potential segfault when using find

I have a program that generate a word document from a json payload (cannot share/private repo).
That program segfaults about ~1-2% of the time.

I have traced the segfault to the find method from jetscii::Bytes in 1 of the dependency https://github.com/PoiScript/strong-xml/blob/db2306cdb62b1ea5d020575ed9d7ee0318e09e17/strong-xml/src/xml_escape.rs#L12.

Here are 2 example values I was able to print of the raw variable before the segfault happened:

"Claims Liability"
"Total Net Claims"

environment

MacOS 10.15.7
rustc 1.55.0 (c8dfcfe04 2021-09-06)

Consider a hybrid SIMD+table lookup

I'm sorry this is such a half-baked idea, but in comrak there is a search of many sigils that seems perfect for jetscii; and in a comrak-downstream project I'm working on (that isn't presently open) I have an even more perfect case for jetscii.

In both cases though we've found that in practice jetscii does not beat a fairly naive table lookup - that is, a 256-byte array containing bools for the bytes being searched, coupled with a loop over the search bytes. (You can see this in the comrak link, though the logic is a bit obscured by other domain-specific stuff).

This was a surprise in both cases, and I really wanted jetscii to win this contest.

I have some idea that the problem may be in the SIMD setup overhead compared to the length of the input buffers, as both of our cases are often searching rather small buffers (I don't have a firm number, but a few bytes to a few hundred).

On that assumption I have it in the back of my mind to write a hybrid table+jetscii search that knows how long a buffer must be to make the jetscii machine code "prologue" worth the expense.

Ah, sorry for the rambling - I was just commenting on another jetscii bug and it reminded me of this idea.

Love your work @shepmaster <3 <3 cc @kivikakk

Tests don't compile on Windows

Trying to run tests on Windows fails with following compilation errors:

error[E0425]: cannot find value `MAP_ANONYMOUS` in module `libc`
   --> src\simd.rs:668:48
    |
668 |     const MAP_ANONYMOUS: libc::int32_t = libc::MAP_ANONYMOUS;
    |                                                ^^^^^^^^^^^^^ not found in `libc`
help: possible candidate is found in another module, you can import it into scope
    |
298 |     use simd::test::MAP_ANONYMOUS;
    |

error[E0425]: cannot find value `PROT_READ` in module `libc`
   --> src\simd.rs:684:30
    |
684 |             let prot = libc::PROT_READ | libc::PROT_WRITE;
    |                              ^^^^^^^^^ not found in `libc`

error[E0425]: cannot find value `PROT_WRITE` in module `libc`
   --> src\simd.rs:684:48
    |
684 |             let prot = libc::PROT_READ | libc::PROT_WRITE;
    |                                                ^^^^^^^^^^ not found in `libc`

error[E0425]: cannot find value `MAP_PRIVATE` in module `libc`
   --> src\simd.rs:685:31
    |
685 |             let flags = libc::MAP_PRIVATE | MAP_ANONYMOUS;
    |                               ^^^^^^^^^^^ not found in `libc`

error[E0425]: cannot find function `mmap` in module `libc`
   --> src\simd.rs:689:36
    |
689 |             let first_page = libc::mmap(addr, length, prot, flags, fd, offset);
    |                                    ^^^^ not found in `libc`

error[E0425]: cannot find value `PROT_NONE` in module `libc`
   --> src\simd.rs:699:34
    |
699 |                 let prot = libc::PROT_NONE;
    |                                  ^^^^^^^^^ not found in `libc`

error[E0425]: cannot find function `mprotect` in module `libc`
   --> src\simd.rs:701:45
    |
701 |                 let mprotect_retval = libc::mprotect(addr, length, prot);
    |                                             ^^^^^^^^ not found in `libc`

error: aborting due to 7 previous errors

For more information about this error, try `rustc --explain E0425`.
error: Could not compile `jetscii`.

To learn more, run the command again with --verbose.

It would be better to use platform-independent crate like https://crates.io/crates/region.

Build fails on i686

BUILDSTDERR: error[E0432]: unresolved import `std::arch::x86_64`
BUILDSTDERR:  --> src/simd.rs:6:11
BUILDSTDERR:   |
BUILDSTDERR: 6 |     arch::x86_64::{
BUILDSTDERR:   |           ^^^^^^ could not find `x86_64` in `arch`

Investigate substring search

@bluss mentioned starting some work, so I figured we might as well create a little issue to track things.

Off the top of my head, I was thinking that we could use the same instruction, but set the "IMM8 Control Register" to Equal ordered (substring search) mode (binary 11). Then we could load the first 16 bytes of the needle into the search register, and iterate through memory just like the existing code. Needs to handle the strange alignment gyrations.

If the needle is < (or <= ?) 16 bytes, a match would be a success. If it's longer, we'd have to fall back to a slower memcmp type check.

Potentially could use any of the advanced substring logic as well (Boyer Moore?).

Let me know if I can help shed any light on the assembly bits!

jetscii returns incorrect result in mysterious circumstances

I've reduced this as much as I can, but it disappears if I reduce it any further.

The code is here: https://github.com/brson/searchtest/blob/jetsciibug/src/lib.rs#L16

On the jetsciibug branch of my searchtest repo. The bug shows up in a benchmark, where jetscii returns the wrong result. This happens on both beta and nightly, the versions of which are printed below. This is using RUSTC_BOOTSTRAP to test benchmarking on beta.

This happens with target-cpu=x86_64 but not with target-cpu=skylake. I haven't tested any other targets.

brian@DESKTOP-UCV672I:~/searchtest⟫ RUSTC_BOOTSTRAP=1 RUSTFLAGS="-C target-cpu=x86-64" cargo +beta bench -- --nocapture
    Finished release [optimized] target(s) in 0.03s
     Running target/release/deps/searchtest-ae1a210660c35b0a

running 1 test
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Some(64)`,
 right: `Some(419)`', src/lib.rs:20:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
test find_from_set_jetscii_bytes_lipsum_emph ... FAILED

failures:

failures:
    find_from_set_jetscii_bytes_lipsum_emph

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: bench failed
101 brian@DESKTOP-UCV672I:~/searchtest⟫ rustc +beta --version
rustc 1.27.0-beta.5 (84b5a46f8 2018-05-15)
brian@DESKTOP-UCV672I:~/searchtest⟫ RUSTC_BOOTSTRAP=1 RUSTFLAGS="-C target-cpu=x86-64" cargo +nightly bench -- --nocapture
   Compiling searchtest v0.1.0 (file:///home/brian/searchtest)
    Finished release [optimized] target(s) in 1.75s
     Running target/release/deps/searchtest-191788c2bec2b787

running 1 test
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Some(64)`,
 right: `Some(419)`', src/lib.rs:20:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
test find_from_set_jetscii_bytes_lipsum_emph ... FAILED

failures:

failures:
    find_from_set_jetscii_bytes_lipsum_emph

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: bench failed
101 brian@DESKTOP-UCV672I:~/searchtest⟫ rustc +nightly --version
rustc 1.27.0-nightly (f0fdaba04 2018-05-15)

Improve substring search performance for corner cases

I've subjected jetscii 0.3.1 to a benchmark suite of just a few pathological examples for substring search.

_jetscii benches very well_, there's just evidence of pathlogical cases

Result (may be noisy, i.e. individual benchmarks may be flukes)

find - str::find with &str pattern
rfind - str::rfind with &str pattern
jetscii_find str::find with Substring pattern
pcmp_find experimental function twsearch::pcmp::find, an incomplete, incorrect two-way search
regex_find using regex

test bad_naive::find                                      ... bench:         274 ns/iter (+/- 19) = 270 MB/s
test bad_naive::jetscii_find                              ... bench:         504 ns/iter (+/- 118) = 146 MB/s
test bad_naive::pcmp_find                                 ... bench:          96 ns/iter (+/- 1) = 770 MB/s
test bad_naive::regex_find                                ... bench:       1,077 ns/iter (+/- 89) = 68 MB/s
test bad_naive::rfind                                     ... bench:         231 ns/iter (+/- 16) = 320 MB/s
test bad_naive_reversed::find                             ... bench:         175 ns/iter (+/- 9) = 422 MB/s
test bad_naive_reversed::jetscii_find                     ... bench:          54 ns/iter (+/- 4) = 1370 MB/s
test bad_naive_reversed::pcmp_find                        ... bench:          43 ns/iter (+/- 4) = 1720 MB/s
test bad_naive_reversed::regex_find                       ... bench:          36 ns/iter (+/- 3) = 2055 MB/s
test bad_naive_reversed::rfind                            ... bench:         367 ns/iter (+/- 54) = 201 MB/s
test pathological_aa_100k::find                           ... bench:       3,084 ns/iter (+/- 149) = 32425 MB/s
test pathological_aa_100k::jetscii_find                   ... bench:      24,116 ns/iter (+/- 1,041) = 4146 MB/s
test pathological_aa_100k::pcmp_find                      ... bench:      27,241 ns/iter (+/- 2,031) = 3670 MB/s
test pathological_aa_100k::regex_find                     ... bench:       4,453 ns/iter (+/- 262) = 22456 MB/s
test pathological_aa_100k::rfind                          ... bench:       2,824 ns/iter (+/- 207) = 35410 MB/s
test pathological_aab_100k::find                          ... bench:     889,518 ns/iter (+/- 55,787) = 337 MB/s
test pathological_aab_100k::jetscii_find                  ... bench:     265,300 ns/iter (+/- 15,265) = 1130 MB/s
test pathological_aab_100k::pcmp_find                     ... bench:     183,135 ns/iter (+/- 11,808) = 1638 MB/s
test pathological_aab_100k::regex_find                    ... bench:   3,750,744 ns/iter (+/- 392,444) = 79 MB/s
test pathological_aab_100k::rfind                         ... bench:     859,327 ns/iter (+/- 104,678) = 348 MB/s
test pathological_two_way_10k::find                       ... bench:     107,896 ns/iter (+/- 48,497) = 278 MB/s
test pathological_two_way_10k::jetscii_find               ... bench:       7,406 ns/iter (+/- 1,072) = 4050 MB/s
test pathological_two_way_10k::pcmp_find                  ... bench:      19,444 ns/iter (+/- 22,302) = 1542 MB/s
test pathological_two_way_10k::regex_find                 ... bench:       1,329 ns/iter (+/- 2,413) = 22573 MB/s
test pathological_two_way_10k::rfind                      ... bench:       2,463 ns/iter (+/- 4,146) = 12180 MB/s
test pathological_two_way_20k::find                       ... bench:     305,465 ns/iter (+/- 505,176) = 327 MB/s
test pathological_two_way_20k::jetscii_find               ... bench:      25,179 ns/iter (+/- 39,142) = 3971 MB/s
test pathological_two_way_20k::pcmp_find                  ... bench:      64,983 ns/iter (+/- 113,250) = 1538 MB/s
test pathological_two_way_20k::regex_find                 ... bench:       6,175 ns/iter (+/- 12,215) = 16194 MB/s
test pathological_two_way_20k::rfind                      ... bench:       3,673 ns/iter (+/- 6,390) = 27225 MB/s
test pathological_two_way_20k_reversed::find              ... bench:       2,492 ns/iter (+/- 4,523) = 24077 MB/s
test pathological_two_way_20k_reversed::jetscii_find      ... bench:      45,084 ns/iter (+/- 80,989) = 1330 MB/s
test pathological_two_way_20k_reversed::pcmp_find         ... bench:      39,623 ns/iter (+/- 65,178) = 1514 MB/s
test pathological_two_way_20k_reversed::regex_find        ... bench:     406,637 ns/iter (+/- 730,079) = 147 MB/s
test pathological_two_way_20k_reversed::rfind             ... bench:     155,639 ns/iter (+/- 284,944) = 385 MB/s
test short_long::find                                     ... bench:       3,924 ns/iter (+/- 4,175) = 650 MB/s
test short_long::jetscii_find                             ... bench:         676 ns/iter (+/- 1,291) = 3773 MB/s
test short_long::pcmp_find                                ... bench:         810 ns/iter (+/- 1,531) = 3149 MB/s
test short_long::regex_find                               ... bench:       2,821 ns/iter (+/- 748) = 904 MB/s
test short_long::rfind                                    ... bench:       2,253 ns/iter (+/- 3,445) = 1132 MB/s
test short_short::find                                    ... bench:          68 ns/iter (+/- 119) = 823 MB/s
test short_short::jetscii_find                            ... bench:         109 ns/iter (+/- 127) = 513 MB/s
test short_short::pcmp_find                               ... bench:          43 ns/iter (+/- 69) = 1302 MB/s
test short_short::regex_find                              ... bench:          54 ns/iter (+/- 122) = 1037 MB/s
test short_short::rfind                                   ... bench:         125 ns/iter (+/- 160) = 448 MB/s

Conclusions:

jetscii 0.3.1 has algorithmic trouble, probably O(n²) problematics, see testcase bad_naive
Both jetscii and pcmp are losing to the byteset optimization in libstd's StrSearcher, see testcase pathological_aa_100k

Benchmark source, very messy crate

Leftover Travis CI badge in Readme

Travis CI was removed in #46 but there's still a badge in the Readme.

expose more primitive operations

As I understand it, the public API currently requires that haystacks be &str and that all needles be ASCII. Might you consider exposing a way to run a search on a &[u8]? And possibly also exposing a way to use arbitrary bytes instead of limiting it to ASCII? (I feel less strongly about the latter point than the former point.)

The specific reason why I'd want this is for use in regex. In particular, the internal matching engines can work on either &str or &[u8], so the prefix literal scanning operates on &[u8] so that it can be used with any of the matching engines. Since all inputs originate with &str (currently), I could unsafely transmute to &[u8] before calling out to jetscii, but I don't think that assumption will always hold in the future and the use of unsafe there seems a little unfortunate.

Other ideas? Thoughts?

Add benchmarks to source code

The documentation shares some benchmarks, which is great. But for transparency, and also to make it easier for users to run said benchmarks on their machine and determine what works best for their hardware, it would also be useful to have the benchmarks available in this repo.

Additionally it would be great to test against crates such as memchr.

Another user had posted some code previously, but it is no longer availble #11

Publishing the new version to crates.io

The version currently on crates.io (0.4.4) is broken with the new version of rust that recently came out (1.54).

Version 0.5.0 that you already created does work with the new version of rust.

Could you please publish the new version to crates.io?

Use cpuid

I think we should use cpuid to check for presence of sse4_2

Versions 0.4.1 to 0.4.4 fail to compile

This problem first got reported here: PoiScript/docx-rs#51

A StackOverflow post made this problem resurface: https://stackoverflow.com/questions/73722833/cannot-perform-const-operation-using-t

It seems that on some machines, version 0.4.1 through 0.4.4 fail to compile.

How to reproduce

cargo new test_project
cd test_project
Add jetscii = "=0.4.4" to your Cargo.toml
cargo build

Outputs:

jetscii = "=0.4.0":

> cargo build
   Compiling jetscii v0.4.0
   Compiling test_project v0.1.0 (/home/finomnis/work/test_project)
    Finished dev [unoptimized + debuginfo] target(s) in 2.86s

jetscii = "=0.4.1":

> cargo build
   Compiling jetscii v0.4.1
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:111:13
    |
111 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:118:13
    |
118 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:151:13
    |
151 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.1/src/simd.rs:158:13
    |
158 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 4 previous errors

jetscii = "=0.4.2":

> cargo build
   Compiling jetscii v0.4.2
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:111:13
    |
111 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:118:13
    |
118 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:158:13
    |
158 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.2/src/simd.rs:165:13
    |
165 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 4 previous errors

jetscii = "=0.4.3":

> cargo build
   Compiling jetscii v0.4.3
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.3/src/simd.rs:109:13
    |
109 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.3/src/simd.rs:148:13
    |
148 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 2 previous errors

jetscii = "=0.4.4":

> cargo build
   Compiling jetscii v0.4.4
error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:109:13
    |
109 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: generic parameters may not be used in const operations
   --> /home/finomnis/.cargo/registry/src/github.com-1ecc6299db9ec823/jetscii-0.4.4/src/simd.rs:148:13
    |
148 |             T::CONTROL_BYTE,
    |             ^^^^^^^^^^^^^^^ cannot perform const operation using `T`
    |
    = note: type parameters may not be used in const expressions

error: could not compile `jetscii` due to 2 previous errors

jetscii = "=0.5.0":

> cargo build
   Compiling jetscii v0.5.0
   Compiling test_project v0.1.0 (/home/finomnis/work/test_project)
    Finished dev [unoptimized + debuginfo] target(s) in 2.08s

Solution

Sadly, this will probably involving yanking versions 0.4.1, 0.4.2, 0.4.3 and 0.4.4. :/

My System

I'm running a Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz on WSL2 on Windows 11.

cat /etc/lsb-release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.5 LTS"

rustup show:

Default host: x86_64-unknown-linux-gnu
rustup home:  /home/finomnis/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-2022-08-03-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

thumbv6m-none-eabi
wasm32-wasi
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.63.0 (4b91a6ea7 2022-08-08)

cat /proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 61
model name      : Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz
stepping        : 4
microcode       : 0xffffffff
cpu MHz         : 2194.918
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 20
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap xsaveopt flush_l1d arch_capabilities
vmx flags       : vnmi invvpid ept_x_only ept_ad ept_1gb tsc_offset vtpr ept vpid unrestricted_guest
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit srbds
bogomips        : 4389.83
clflush size    : 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management: