rust/ripgrep
1
0
Fork 0
mirror of https://github.com/BurntSushi/ripgrep.git synced 2025-02-14 22:23:24 +02:00
Code Issues Releases Activity
ripgrep/crates/searcher/Cargo.toml

33 lines
1004 B
TOML
Raw Normal View History

libripgrep: initial commit introducing libripgrep libripgrep is not any one library, but rather, a collection of libraries that roughly separate the following key distinct phases in a grep implementation: 1. Pattern matching (e.g., by a regex engine). 2. Searching a file using a pattern matcher. 3. Printing results. Ultimately, both (1) and (3) are defined by de-coupled interfaces, of which there may be multiple implementations. Namely, (1) is satisfied by the `Matcher` trait in the `grep-matcher` crate and (3) is satisfied by the `Sink` trait in the `grep2` crate. The searcher (2) ties everything together and finds results using a matcher and reports those results using a `Sink` implementation. Closes #162
2018-04-29 09:29:52 -04:00
[package]
name = "grep-searcher"
grep-searcher-0.1.13
2023-11-27 21:34:58 -05:00
version = "0.1.13" #:version
libripgrep: initial commit introducing libripgrep libripgrep is not any one library, but rather, a collection of libraries that roughly separate the following key distinct phases in a grep implementation: 1. Pattern matching (e.g., by a regex engine). 2. Searching a file using a pattern matcher. 3. Printing results. Ultimately, both (1) and (3) are defined by de-coupled interfaces, of which there may be multiple implementations. Namely, (1) is satisfied by the `Matcher` trait in the `grep-matcher` crate and (3) is satisfied by the `Sink` trait in the `grep2` crate. The searcher (2) ties everything together and finds results using a matcher and reports those results using a `Sink` implementation. Closes #162
2018-04-29 09:29:52 -04:00
authors = ["Andrew Gallant <jamslam@gmail.com>"]
description = """
Fast line oriented regex searching as a library.
"""
documentation = "https://docs.rs/grep-searcher"
crates: update URLs in Cargo.toml This corrects an oversight when the repo was re-organized to have its crates moved into a 'crates' sub-directory. PR #1505
2020-02-28 17:31:43 -08:00
homepage = "https://github.com/BurntSushi/ripgrep/tree/master/crates/searcher"
repository = "https://github.com/BurntSushi/ripgrep/tree/master/crates/searcher"
libripgrep: initial commit introducing libripgrep libripgrep is not any one library, but rather, a collection of libraries that roughly separate the following key distinct phases in a grep implementation: 1. Pattern matching (e.g., by a regex engine). 2. Searching a file using a pattern matcher. 3. Printing results. Ultimately, both (1) and (3) are defined by de-coupled interfaces, of which there may be multiple implementations. Namely, (1) is satisfied by the `Matcher` trait in the `grep-matcher` crate and (3) is satisfied by the `Sink` trait in the `grep2` crate. The searcher (2) ties everything together and finds results using a matcher and reports those results using a `Sink` implementation. Closes #162
2018-04-29 09:29:52 -04:00
readme = "README.md"
keywords = ["regex", "grep", "egrep", "search", "pattern"]
cargo: use SPDX license format for all crates This was done for the main crate in d11a3b33773620bcc593f82b557757f0c2ec8a05. See also #987. PR #2204
2022-05-09 04:52:11 -07:00
license = "Unlicense OR MIT"
searcher: polish This updates some dependencies and brings code style in line with my current practice.
2023-09-28 12:58:11 -04:00
edition = "2021"
libripgrep: initial commit introducing libripgrep libripgrep is not any one library, but rather, a collection of libraries that roughly separate the following key distinct phases in a grep implementation: 1. Pattern matching (e.g., by a regex engine). 2. Searching a file using a pattern matcher. 3. Printing results. Ultimately, both (1) and (3) are defined by de-coupled interfaces, of which there may be multiple implementations. Namely, (1) is satisfied by the `Matcher` trait in the `grep-matcher` crate and (3) is satisfied by the `Sink` trait in the `grep2` crate. The searcher (2) ties everything together and finds results using a matcher and reports those results using a `Sink` implementation. Closes #162
2018-04-29 09:29:52 -04:00
[dependencies]
searcher: polish This updates some dependencies and brings code style in line with my current practice.
2023-09-28 12:58:11 -04:00
bstr = { version = "1.6.2", default-features = false, features = ["std"] }
encoding_rs = "0.8.33"
encoding_rs_io = "0.1.7"
deps: bump grep-matcher to 0.1.7
2023-11-26 14:15:34 -05:00
grep-matcher = { version = "0.1.7", path = "../matcher" }
searcher: polish This updates some dependencies and brings code style in line with my current practice.
2023-09-28 12:58:11 -04:00
log = "0.4.20"
memchr = "2.6.3"
deps: bump to memmap2 0.9.0
2023-11-26 13:31:31 -05:00
memmap = { package = "memmap2", version = "0.9.0" }
libripgrep: initial commit introducing libripgrep libripgrep is not any one library, but rather, a collection of libraries that roughly separate the following key distinct phases in a grep implementation: 1. Pattern matching (e.g., by a regex engine). 2. Searching a file using a pattern matcher. 3. Printing results. Ultimately, both (1) and (3) are defined by de-coupled interfaces, of which there may be multiple implementations. Namely, (1) is satisfied by the `Matcher` trait in the `grep-matcher` crate and (3) is satisfied by the `Sink` trait in the `grep2` crate. The searcher (2) ties everything together and finds results using a matcher and reports those results using a `Sink` implementation. Closes #162
2018-04-29 09:29:52 -04:00
[dev-dependencies]
deps: bump grep-regex to 0.1.12
2023-11-26 14:16:31 -05:00
grep-regex = { version = "0.1.12", path = "../regex" }
deps: drop bytecount in favor of memchr_iter(..).count() As of the memchr 2.6 release, its Iterator::count method is specialized to only count the number of occurrences instead of finding the offset of each occurrence. This replaces ripgrep's use of the bytecount crate. While micro-benchmarks suggest that memchr's method has better throughput than bytecount, it turned out to be an illusion. Namely, on a ~13GB haystack prior to this change: $ time rg-bytecount 'You killed my friend, my best friend, my lifelong friend!' OpenSubtitles2018.raw.en --line-number 441450441:- You killed my friend, my best friend, my lifelong friend! real 1.473 user 1.186 sys 0.286 maxmem 12512 MB faults 0 And then after: $ time rg 'You killed my friend, my best friend, my lifelong friend!' OpenSubtitles2018.raw.en --line-number 441450441:- You killed my friend, my best friend, my lifelong friend! real 1.532 user 1.280 sys 0.250 maxmem 12512 MB faults 0 But perf is just about in the same ballpark. That's good enough for me at the moment in order to drop the extra dependency. I did this because the marginal cost of adding the Iterator::count() specialization to memchr was extremely small.
2023-09-02 12:25:34 -04:00
regex = "1.9.5"
libripgrep: initial commit introducing libripgrep libripgrep is not any one library, but rather, a collection of libraries that roughly separate the following key distinct phases in a grep implementation: 1. Pattern matching (e.g., by a regex engine). 2. Searching a file using a pattern matcher. 3. Printing results. Ultimately, both (1) and (3) are defined by de-coupled interfaces, of which there may be multiple implementations. Namely, (1) is satisfied by the `Matcher` trait in the `grep-matcher` crate and (3) is satisfied by the `Sink` trait in the `grep2` crate. The searcher (2) ties everything together and finds results using a matcher and reports those results using a `Sink` implementation. Closes #162
2018-04-29 09:29:52 -04:00
[features]
cargo: nuke 'simd-accel' from orbit 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
2024-03-07 09:31:22 -05:00
# These features are DEPRECATED. Runtime dispatch is used for SIMD now.
simd-accel = []
deps: update to bytecount 0.5 bytecount now uses runtime dispatch for enabling SIMD, which means we can no longer need the avx-accel features. We remove it from ripgrep since the next release will be a minor version bump, but leave them as no-ops for the crates that previously used it.
2019-01-19 09:52:10 -05:00
avx-accel = []
Reference in New Issue Copy Permalink