rust/ripgrep
1
0
Fork 0
mirror of https://github.com/BurntSushi/ripgrep.git synced 2024-12-02 02:56:32 +02:00
Code Issues Releases Activity
ea99421ec8
ripgrep/Cargo.lock

556 lines
13 KiB
Plaintext
Raw Normal View History

cargo: include auto-generated message This is going to be annoying for a while if one switches between the latest nightly compiler and older compilers. Sigh.
2019-01-29 20:04:40 +02:00
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
deps: update to packed_simd_2 0.3.8 It broke on latest nightly. I'm *very* close to just removing the 'simd-accel' feature altogether. Fixes #2230
2022-06-10 15:39:17 +02:00
version = 3
deps: update everything This updates all dependencies to their latest versions. We tolerate a duplicative aho-corasick for now, which we will fix in the next commit.
2019-04-03 19:07:26 +02:00
[[package]]
name = "aho-corasick"
deps: bump everything else
2024-03-25 00:58:28 +02:00
version = "1.1.3"
deps: update everything This updates all dependencies to their latest versions. We tolerate a duplicative aho-corasick for now, which we will fix in the next commit.
2019-04-03 19:07:26 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: bump everything else
2024-03-25 00:58:28 +02:00
checksum = "8e60d3430d3a69478ad0993f19238d2df97c507009a52b3c10addcd7f6bcb916"
deps: update everything This does unfortunately bring in both regex-syntax 0.6 and 0.7, but we'll fix that once regex 1.9 is out.
2023-05-16 19:14:23 +02:00
dependencies = [
"memchr",
]
core: switch to anyhow This commit adds `anyhow` as a dependency and switches over to it from Box<dyn Error>. It actually looks like I've kept all of my errors rather shallow, such that we don't get a huge benefit from anyhow at present. But now that anyhow is in use, I expect to use its "context" feature more going forward.
2023-10-12 18:16:42 +02:00
[[package]]
name = "anyhow"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.82"
core: switch to anyhow This commit adds `anyhow` as a dependency and switches over to it from Box<dyn Error>. It actually looks like I've kept all of my errors rather shallow, such that we don't get a huge benefit from anyhow at present. But now that anyhow is in use, I expect to use its "context" feature more going forward.
2023-10-12 18:16:42 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "f538837af36e6f6a9be0faa67f9a314f8119e4e4b5867c6ab40ed60360142519"
core: switch to anyhow This commit adds `anyhow` as a dependency and switches over to it from Box<dyn Error>. It actually looks like I've kept all of my errors rather shallow, such that we don't get a huge benefit from anyhow at present. But now that anyhow is in use, I expect to use its "context" feature more going forward.
2023-10-12 18:16:42 +02:00
deps: add bstr to Cargo.lock
2019-04-06 04:28:43 +02:00
[[package]]
name = "bstr"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "1.9.1"
deps: add bstr to Cargo.lock
2019-04-06 04:28:43 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "05efc5cfd9110c8416e471df0e96702d58690178e206e61b7173706673c93706"
deps: add bstr to Cargo.lock
2019-04-06 04:28:43 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"memchr",
deps: drop temporary patch and move to bstr 1.6 Now that regex 1.9 is out, we can depend on it from crates.io.
2023-07-05 17:08:13 +02:00
"regex-automata",
deps: upgrade bstr to 1.1
2023-01-05 15:19:33 +02:00
"serde",
deps: add bstr to Cargo.lock
2019-04-06 04:28:43 +02:00
]
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 15:29:52 +02:00
[[package]]
name = "cc"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.95"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "d32a725bc159af97c3e629873bb9f88fb8cf8a4867175f76dc987815ea07c83b"
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
dependencies = [
"jobserver",
deps: update everything
2023-08-15 17:09:46 +02:00
"libc",
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
"once_cell",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
]
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 15:29:52 +02:00
deps: targeted update of some dependencies This updates encoding_rs, crossbeam-utils and crossbeam-channel. This serves two purposes. The encoding_rs update fixes a compilation failure on the latest nightly. The crossbeam updates are good sense and to reduce duplicate dependencies such as cfg-if. (Although, we note that the log crate still pulls in cfg-if 0.1, so ripgrep has a duplicate dependency there for now. But it's very small.) Fixes #1721, Closes #1705
2020-11-02 16:04:39 +02:00
[[package]]
name = "cfg-if"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
[[package]]
name = "crossbeam-channel"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.5.12"
deps: targeted update of some dependencies This updates encoding_rs, crossbeam-utils and crossbeam-channel. This serves two purposes. The encoding_rs update fixes a compilation failure on the latest nightly. The crossbeam updates are good sense and to reduce duplicate dependencies such as cfg-if. (Although, we note that the log crate still pulls in cfg-if 0.1, so ripgrep has a duplicate dependency there for now. But it's very small.) Fixes #1721, Closes #1705
2020-11-02 16:04:39 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "ab3db02a9c5b5121e1e42fbdb1aeb65f5e02624cc58c43f2884c6ccac0b82f95"
ripgrep: move minimum version to Rust stable This also updates some code to make use of our more liberal versioning requirement, including the use of crossbeam-channel instead of the MsQueue from the older an unmaintained crossbeam 0.3. This does regrettably add a sizable number of dependencies, however, compile times seem mostly unaffected. Closes #1019
2018-08-22 01:47:12 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"crossbeam-utils",
ripgrep: move minimum version to Rust stable This also updates some code to make use of our more liberal versioning requirement, including the use of crossbeam-channel instead of the MsQueue from the older an unmaintained crossbeam 0.3. This does regrettably add a sizable number of dependencies, however, compile times seem mostly unaffected. Closes #1019
2018-08-22 01:47:12 +02:00
]
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
[[package]]
name = "crossbeam-deque"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.8.5"
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "613f8cc01fe9cf1a3eb3d7f488fd2fa8388403e97039e2f73692932e291a770d"
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
dependencies = [
"crossbeam-epoch",
"crossbeam-utils",
]
[[package]]
name = "crossbeam-epoch"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.9.18"
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "5b82ac4a3c2ca9c3460964f020e1402edd5753411d7737aa39c3714ad1b5420e"
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
dependencies = [
"crossbeam-utils",
]
ripgrep: move minimum version to Rust stable This also updates some code to make use of our more liberal versioning requirement, including the use of crossbeam-channel instead of the MsQueue from the older an unmaintained crossbeam 0.3. This does regrettably add a sizable number of dependencies, however, compile times seem mostly unaffected. Closes #1019
2018-08-22 01:47:12 +02:00
[[package]]
name = "crossbeam-utils"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.8.19"
Add parallel recursive directory iterator. This adds a new walk type in the `ignore` crate, `WalkParallel`, which provides a way for recursively iterating over a set of paths in parallel while respecting various ignore rules. The API is a bit strange, as a closure producing a closure isn't something one often sees, but it does seem to work well. This also allowed us to simplify much of the worker logic in ripgrep proper, where MultiWorker is now gone.
2016-11-06 03:44:15 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "248e3bacc7dc6baa3b21e405ee045c3047101a49145e7e9eca583ab4c2ca5345"
Add parallel recursive directory iterator. This adds a new walk type in the `ignore` crate, `WalkParallel`, which provides a way for recursively iterating over a set of paths in parallel while respecting various ignore rules. The API is a bit strange, as a closure producing a closure isn't something one often sees, but it does seem to work well. This also allowed us to simplify much of the worker logic in ripgrep proper, where MultiWorker is now gone.
2016-11-06 03:44:15 +02:00
Add support for additional text encodings. This includes, but is not limited to, UTF-16, latin-1, GBK, EUC-JP and Shift_JIS. (Courtesy of the `encoding_rs` crate.) Specifically, this feature enables ripgrep to search files that are encoded in an encoding other than UTF-8. The list of available encodings is tied directly to what the `encoding_rs` crate supports, which is in turn tied to the Encoding Standard. The full list of available encodings can be found here: https://encoding.spec.whatwg.org/#concept-encoding-get This pull request also introduces the notion that text encodings can be automatically detected on a best effort basis. Currently, the only support for this is checking for a UTF-16 bom. In all other cases, a text encoding of `auto` (the default) implies a UTF-8 or ASCII compatible source encoding. When a text encoding is otherwise specified, it is unconditionally used for all files searched. Since ripgrep's regex engine is fundamentally built on top of UTF-8, this feature works by transcoding the files to be searched from their source encoding to UTF-8. This transcoding only happens when: 1. `auto` is specified and a non-UTF-8 encoding is detected. 2. A specific encoding is given by end users (including UTF-8). When transcoding occurs, errors are handled by automatically inserting the Unicode replacement character. In this case, ripgrep's output is guaranteed to be valid UTF-8 (excluding non-UTF-8 file paths, if they are printed). In all other cases, the source text is searched directly, which implies an assumption that it is at least ASCII compatible, but where UTF-8 is most useful. In this scenario, encoding errors are not detected. In this case, ripgrep's output will match the input exactly, byte-for-byte. This design may not be optimal in all cases, but it has some advantages: 1. In the happy path ("UTF-8 everywhere") remains happy. I have not been able to witness any performance regressions. 2. In the non-UTF-8 path, implementation complexity is kept relatively low. The cost here is transcoding itself. A potentially superior implementation might build decoding of any encoding into the regex engine itself. In particular, the fundamental problem with transcoding everything first is that literal optimizations are nearly negated. Future work should entail improving the user experience. For example, we might want to auto-detect more text encodings. A more elaborate UX experience might permit end users to specify multiple text encodings, although this seems hard to pull off in an ergonomic way. Fixes #1
2017-03-09 03:22:48 +02:00
[[package]]
name = "encoding_rs"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "0.8.34"
Add support for additional text encodings. This includes, but is not limited to, UTF-16, latin-1, GBK, EUC-JP and Shift_JIS. (Courtesy of the `encoding_rs` crate.) Specifically, this feature enables ripgrep to search files that are encoded in an encoding other than UTF-8. The list of available encodings is tied directly to what the `encoding_rs` crate supports, which is in turn tied to the Encoding Standard. The full list of available encodings can be found here: https://encoding.spec.whatwg.org/#concept-encoding-get This pull request also introduces the notion that text encodings can be automatically detected on a best effort basis. Currently, the only support for this is checking for a UTF-16 bom. In all other cases, a text encoding of `auto` (the default) implies a UTF-8 or ASCII compatible source encoding. When a text encoding is otherwise specified, it is unconditionally used for all files searched. Since ripgrep's regex engine is fundamentally built on top of UTF-8, this feature works by transcoding the files to be searched from their source encoding to UTF-8. This transcoding only happens when: 1. `auto` is specified and a non-UTF-8 encoding is detected. 2. A specific encoding is given by end users (including UTF-8). When transcoding occurs, errors are handled by automatically inserting the Unicode replacement character. In this case, ripgrep's output is guaranteed to be valid UTF-8 (excluding non-UTF-8 file paths, if they are printed). In all other cases, the source text is searched directly, which implies an assumption that it is at least ASCII compatible, but where UTF-8 is most useful. In this scenario, encoding errors are not detected. In this case, ripgrep's output will match the input exactly, byte-for-byte. This design may not be optimal in all cases, but it has some advantages: 1. In the happy path ("UTF-8 everywhere") remains happy. I have not been able to witness any performance regressions. 2. In the non-UTF-8 path, implementation complexity is kept relatively low. The cost here is transcoding itself. A potentially superior implementation might build decoding of any encoding into the regex engine itself. In particular, the fundamental problem with transcoding everything first is that literal optimizations are nearly negated. Future work should entail improving the user experience. For example, we might want to auto-detect more text encodings. A more elaborate UX experience might permit end users to specify multiple text encodings, although this seems hard to pull off in an ergonomic way. Fixes #1
2017-03-09 03:22:48 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "b45de904aa0b010bce2ab45264d0631681847fa7b6f2eaa7dab7619943bc4f59"
Add support for additional text encodings. This includes, but is not limited to, UTF-16, latin-1, GBK, EUC-JP and Shift_JIS. (Courtesy of the `encoding_rs` crate.) Specifically, this feature enables ripgrep to search files that are encoded in an encoding other than UTF-8. The list of available encodings is tied directly to what the `encoding_rs` crate supports, which is in turn tied to the Encoding Standard. The full list of available encodings can be found here: https://encoding.spec.whatwg.org/#concept-encoding-get This pull request also introduces the notion that text encodings can be automatically detected on a best effort basis. Currently, the only support for this is checking for a UTF-16 bom. In all other cases, a text encoding of `auto` (the default) implies a UTF-8 or ASCII compatible source encoding. When a text encoding is otherwise specified, it is unconditionally used for all files searched. Since ripgrep's regex engine is fundamentally built on top of UTF-8, this feature works by transcoding the files to be searched from their source encoding to UTF-8. This transcoding only happens when: 1. `auto` is specified and a non-UTF-8 encoding is detected. 2. A specific encoding is given by end users (including UTF-8). When transcoding occurs, errors are handled by automatically inserting the Unicode replacement character. In this case, ripgrep's output is guaranteed to be valid UTF-8 (excluding non-UTF-8 file paths, if they are printed). In all other cases, the source text is searched directly, which implies an assumption that it is at least ASCII compatible, but where UTF-8 is most useful. In this scenario, encoding errors are not detected. In this case, ripgrep's output will match the input exactly, byte-for-byte. This design may not be optimal in all cases, but it has some advantages: 1. In the happy path ("UTF-8 everywhere") remains happy. I have not been able to witness any performance regressions. 2. In the non-UTF-8 path, implementation complexity is kept relatively low. The cost here is transcoding itself. A potentially superior implementation might build decoding of any encoding into the regex engine itself. In particular, the fundamental problem with transcoding everything first is that literal optimizations are nearly negated. Future work should entail improving the user experience. For example, we might want to auto-detect more text encodings. A more elaborate UX experience might permit end users to specify multiple text encodings, although this seems hard to pull off in an ergonomic way. Fixes #1
2017-03-09 03:22:48 +02:00
dependencies = [
deps: update everything Surprisingly looks like no new dependencies were added! Yay! And we removed an extra copy of 'cfg-if' due to what appears to be an updated in 'packed_simd_2'. Otherwise, all updates appear to be minor things.
2022-03-21 14:37:18 +02:00
"cfg-if",
Add support for additional text encodings. This includes, but is not limited to, UTF-16, latin-1, GBK, EUC-JP and Shift_JIS. (Courtesy of the `encoding_rs` crate.) Specifically, this feature enables ripgrep to search files that are encoded in an encoding other than UTF-8. The list of available encodings is tied directly to what the `encoding_rs` crate supports, which is in turn tied to the Encoding Standard. The full list of available encodings can be found here: https://encoding.spec.whatwg.org/#concept-encoding-get This pull request also introduces the notion that text encodings can be automatically detected on a best effort basis. Currently, the only support for this is checking for a UTF-16 bom. In all other cases, a text encoding of `auto` (the default) implies a UTF-8 or ASCII compatible source encoding. When a text encoding is otherwise specified, it is unconditionally used for all files searched. Since ripgrep's regex engine is fundamentally built on top of UTF-8, this feature works by transcoding the files to be searched from their source encoding to UTF-8. This transcoding only happens when: 1. `auto` is specified and a non-UTF-8 encoding is detected. 2. A specific encoding is given by end users (including UTF-8). When transcoding occurs, errors are handled by automatically inserting the Unicode replacement character. In this case, ripgrep's output is guaranteed to be valid UTF-8 (excluding non-UTF-8 file paths, if they are printed). In all other cases, the source text is searched directly, which implies an assumption that it is at least ASCII compatible, but where UTF-8 is most useful. In this scenario, encoding errors are not detected. In this case, ripgrep's output will match the input exactly, byte-for-byte. This design may not be optimal in all cases, but it has some advantages: 1. In the happy path ("UTF-8 everywhere") remains happy. I have not been able to witness any performance regressions. 2. In the non-UTF-8 path, implementation complexity is kept relatively low. The cost here is transcoding itself. A potentially superior implementation might build decoding of any encoding into the regex engine itself. In particular, the fundamental problem with transcoding everything first is that literal optimizations are nearly negated. Future work should entail improving the user experience. For example, we might want to auto-detect more text encodings. A more elaborate UX experience might permit end users to specify multiple text encodings, although this seems hard to pull off in an ergonomic way. Fixes #1
2017-03-09 03:22:48 +02:00
]
ripgrep: replace decoder with encoding_rs_io This commit mostly moves the transcoder implementation to its own crate: https://github.com/BurntSushi/encoding_rs_io The new crate adds clear documentation and cleans up the implementation to fully implement the contract of io::Read.
2018-07-22 02:36:32 +02:00
[[package]]
name = "encoding_rs_io"
deps: update everything This adds one new dependency, maybe-uninit, which is brought in by crossbeam-channel[1]. This is to apparently fix some unsound code without bumping the MSRV. Since ripgrep uses the latest stable release of Rust, the maybe-uninit crate should compile down to nothing and just re-export std's `MaybeUninit` type. [1] - https://github.com/crossbeam-rs/crossbeam/pull/458
2020-03-15 14:32:33 +02:00
version = "0.1.7"
ripgrep: replace decoder with encoding_rs_io This commit mostly moves the transcoder implementation to its own crate: https://github.com/BurntSushi/encoding_rs_io The new crate adds clear documentation and cleans up the implementation to fully implement the contract of io::Read.
2018-07-22 02:36:32 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
checksum = "1cc3c5651fb62ab8aa3103998dade57efdd028544bd300516baa31840c252a83"
ripgrep: replace decoder with encoding_rs_io This commit mostly moves the transcoder implementation to its own crate: https://github.com/BurntSushi/encoding_rs_io The new crate adds clear documentation and cleans up the implementation to fully implement the contract of io::Read.
2018-07-22 02:36:32 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"encoding_rs",
ripgrep: replace decoder with encoding_rs_io This commit mostly moves the transcoder implementation to its own crate: https://github.com/BurntSushi/encoding_rs_io The new crate adds clear documentation and cleans up the implementation to fully implement the contract of io::Read.
2018-07-22 02:36:32 +02:00
]
deps: update to latest regex crate The regex update fixes the Rust nightly build failure by in turn updating its simd dependency to 2.x. The regex update also includes a literal optimization that uses Tuned Boyer Moore. Fixes #617
2017-12-30 22:46:55 +02:00
[[package]]
name = "glob"
deps: update everything This does unfortunately bring in both regex-syntax 0.6 and 0.7, but we'll fix that once regex 1.9 is out.
2023-05-16 19:14:23 +02:00
version = "0.3.1"
deps: update to latest regex crate The regex update fixes the Rust nightly build failure by in turn updating its simd dependency to 2.x. The regex update also includes a literal optimization that uses Tuned Boyer Moore. Fixes #617
2017-12-30 22:46:55 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything This does unfortunately bring in both regex-syntax 0.6 and 0.7, but we'll fix that once regex 1.9 is out.
2023-05-16 19:14:23 +02:00
checksum = "d2fabcfbdc87f4758337ca535fb41a6d701b65693ce38287d856d1674551ec9b"
deps: update to latest regex crate The regex update fixes the Rust nightly build failure by in turn updating its simd dependency to 2.x. The regex update also includes a literal optimization that uses Tuned Boyer Moore. Fixes #617
2017-12-30 22:46:55 +02:00
Move glob implementation to new crate. It is isolated and complex enough that it deserves attention all on its own. It's also eminently reusable.
2016-10-01 01:42:41 +02:00
[[package]]
name = "globset"
globset-0.4.14
2023-11-26 21:11:05 +02:00
version = "0.4.14"
Move glob implementation to new crate. It is isolated and complex enough that it deserves attention all on its own. It's also eminently reusable.
2016-10-01 01:42:41 +02:00
dependencies = [
deps: initial migration steps to regex 1.9 This leaves the grep-regex crate in tatters. Pretty much the entire thing needs to be re-worked. The upshot is that it should result in some big simplifications. I hope. The idea here is to drop down and actually use regex-automata 0.3 instead of the regex crate itself.
2023-06-12 03:25:23 +02:00
"aho-corasick",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"bstr",
"glob",
"log",
globset: polishing This brings the code in line with my current style. It also inlines the dozen or so lines of code for FNV hashing instead of bringing in a micro-crate for it. Finally, it drops the dependency on regex in favor of using regex-syntax and regex-automata directly.
2023-09-26 21:01:20 +02:00
"regex-automata",
"regex-syntax",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"serde",
"serde_json",
Move glob implementation to new crate. It is isolated and complex enough that it deserves attention all on its own. It's also eminently reusable.
2016-10-01 01:42:41 +02:00
]
commit Cargo.lock
2016-09-12 01:06:05 +02:00
[[package]]
name = "grep"
grep-0.3.1
2023-11-28 04:36:54 +02:00
version = "0.3.1"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"grep-cli",
"grep-matcher",
"grep-pcre2",
"grep-printer",
"grep-regex",
"grep-searcher",
"termcolor",
"walkdir",
Move all gitignore matching to separate crate. This PR introduces a new sub-crate, `ignore`, which primarily provides a fast recursive directory iterator that respects ignore files like gitignore and other configurable filtering rules based on globs or even file types. This results in a substantial source of complexity moved out of ripgrep's core and into a reusable component that others can now (hopefully) benefit from. While much of the ignore code carried over from ripgrep's core, a substantial portion of it was rewritten with the following goals in mind: 1. Reuse matchers built from gitignore files across directory iteration. 2. Design the matcher data structure to be amenable for parallelizing directory iteration. (Indeed, writing the parallel iterator is the next step.) Fixes #9, #44, #45
2016-10-12 01:57:09 +02:00
]
grep-cli: introduce new grep-cli crate This commit moves a lot of "utility" code from ripgrep core into grep-cli. Any one of these things might not be worth creating a new crate, but combining everything together results in a fair number of a convenience routines that make up a decent sized crate. There is potentially more we could move into the crate, but much of what remains in ripgrep core is almost entirely dealing with the number of flags we support. In the course of doing moving things to the grep-cli crate, we clean up a lot of gunk and improve failure modes in a number of cases. In particular, we've fixed a bug where other processes could deadlock if they write too much to stderr. Fixes #990
2018-08-30 02:53:52 +02:00
[[package]]
name = "grep-cli"
grep-cli-0.1.10
2023-11-26 21:13:03 +02:00
version = "0.1.10"
grep-cli: introduce new grep-cli crate This commit moves a lot of "utility" code from ripgrep core into grep-cli. Any one of these things might not be worth creating a new crate, but combining everything together results in a fair number of a convenience routines that make up a decent sized crate. There is potentially more we could move into the crate, but much of what remains in ripgrep core is almost entirely dealing with the number of flags we support. In the course of doing moving things to the grep-cli crate, we clean up a lot of gunk and improve failure modes in a number of cases. In particular, we've fixed a bug where other processes could deadlock if they write too much to stderr. Fixes #990
2018-08-30 02:53:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"bstr",
"globset",
cli: add new 'hostname' function This will enable us to query for the current system's hostname in both Unix and Windows environments. We could have pulled in the 'gethostname' crate for this, but: 1. I'm not a huge fan of micro-crates. 2. The 'gethostname' crate panics if an error occurs. (Which, to be fair, an error should never occur, but it seems plausible on borked systems? ripgrep runs in a lot of places, so I'd rather not take the chance of a panic bringing down ripgrep for an optional convenience feature.) 3. The 'gethostname' crate uses the 'windows-targets' crate from Microsoft. This is arguably the "right" thing to do, but ripgrep doesn't use them yet and they appear high-churn. So I just added a safe wrapper to do this to winapi-util[1] and then inlined the Unix version here. This brings in no extra dependencies and the routine is fallible so that callers can recover from potentially strange failures. [1]: https://github.com/BurntSushi/winapi-util/pull/14
2023-09-21 19:13:46 +02:00
"libc",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"log",
"termcolor",
"winapi-util",
grep-cli: introduce new grep-cli crate This commit moves a lot of "utility" code from ripgrep core into grep-cli. Any one of these things might not be worth creating a new crate, but combining everything together results in a fair number of a convenience routines that make up a decent sized crate. There is potentially more we could move into the crate, but much of what remains in ripgrep core is almost entirely dealing with the number of flags we support. In the course of doing moving things to the grep-cli crate, we clean up a lot of gunk and improve failure modes in a number of cases. In particular, we've fixed a bug where other processes could deadlock if they write too much to stderr. Fixes #990
2018-08-30 02:53:52 +02:00
]
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 15:29:52 +02:00
[[package]]
name = "grep-matcher"
grep-matcher-0.1.7
2023-11-26 21:13:54 +02:00
version = "0.1.7"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"memchr",
"regex",
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 15:29:52 +02:00
]
[[package]]
name = "grep-pcre2"
grep-pcre2-0.1.7
2023-11-26 21:16:46 +02:00
version = "0.1.7"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"grep-matcher",
regex: push more pattern handling to matcher construction Previously, ripgrep core was responsible for escaping regex patterns and implementing the --line-regexp flag. This commit moves that responsibility down into the matchers such that ripgrep just needs to hand the patterns it gets off to the matcher builder. The builder will then take care of escaping and all that. This was done to make pattern construction completely owned by the matcher builders. With the arrival regex-automata, this means we can move to the HIR very quickly and then never move back to the concrete syntax. We can then build our regex directly from the HIR. This overall can save quite a bit of time, especially when searching for large dictionaries. We still aren't quite as fast as GNU grep when searching something on the scale of /usr/share/dict/words, but we are basically within spitting distance. Prior to this, we were about an order of magnitude slower. This architecture in particular lets us write a pretty simple fast path that avoids AST parsing and HIR translation entirely: the case where one is just searching for a literal. In that case, we can hand construct the HIR directly.
2023-06-20 02:47:07 +02:00
"log",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"pcre2",
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 15:29:52 +02:00
]
[[package]]
name = "grep-printer"
grep-printer-0.2.1
2023-11-28 04:36:02 +02:00
version = "0.2.1"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"bstr",
"grep-matcher",
"grep-regex",
"grep-searcher",
hyperlink: rejigger how hyperlinks work This essentially takes the work done in #2483 and does a bit of a facelift. A brief summary: * We reduce the hyperlink API we expose to just the format, a configuration and an environment. * We move buffer management into a hyperlink-specific interpolator. * We expand the documentation on --hyperlink-format. * We rewrite the hyperlink format parser to be a simple state machine with support for escaping '{{' and '}}'. * We remove the 'gethostname' dependency and instead insist on the caller to provide the hostname. (So grep-printer doesn't get it itself, but the application will.) Similarly for the WSL prefix. * Probably some other things. Overall, the general structure of #2483 was kept. The biggest change is probably requiring the caller to pass in things like a hostname instead of having the crate do it. I did this for a couple reasons: 1. I feel uncomfortable with code deep inside the printing logic reaching out into the environment to assume responsibility for retrieving the hostname. This feels more like an application-level responsibility. Arguably, path canonicalization falls into this same bucket, but it is more difficult to rip that out. (And we can do it in the future in a backwards compatible fashion I think.) 2. I wanted to permit end users to tell ripgrep about their system's hostname in their own way, e.g., by running a custom executable. I want this because I know at least for my own use cases, I sometimes log into systems using an SSH hostname that is distinct from the system's actual hostname (usually because the system is shared in some way or changing its hostname is not allowed/practical). I think that's about it. Closes #665, Closes #2483
2023-09-22 20:57:44 +02:00
"log",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"serde",
"serde_json",
"termcolor",
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 15:29:52 +02:00
]
[[package]]
name = "grep-regex"
grep-regex-0.1.12
2023-11-26 21:15:44 +02:00
version = "0.1.12"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"bstr",
"grep-matcher",
"log",
deps: drop temporary patch and move to bstr 1.6 Now that regex 1.9 is out, we can depend on it from crates.io.
2023-07-05 17:08:13 +02:00
"regex-automata",
deps: initial migration steps to regex 1.9 This leaves the grep-regex crate in tatters. Pretty much the entire thing needs to be re-worked. The upshot is that it should result in some big simplifications. I hope. The idea here is to drop down and actually use regex-automata 0.3 instead of the regex crate itself.
2023-06-12 03:25:23 +02:00
"regex-syntax",
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 15:29:52 +02:00
]
[[package]]
name = "grep-searcher"
grep-searcher-0.1.13
2023-11-28 04:34:58 +02:00
version = "0.1.13"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"bstr",
"encoding_rs",
"encoding_rs_io",
"grep-matcher",
"grep-regex",
"log",
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 18:25:34 +02:00
"memchr",
deps: replace memmap with memmap2 memmap is unmaintained at this point and it is being flagged as a RUSTSEC advisory in ripgrep. This doesn't seem like that big of a deal to me honestly, but memmap2 looks like a fine choice at this point. Fixes #1785, Closes #1786
2021-01-18 01:49:51 +02:00
"memmap2",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"regex",
deps: run cargo update The only new dependency is an unused target specific dependency hermit via the atty crate.
2020-01-10 03:38:00 +02:00
]
Move all gitignore matching to separate crate. This PR introduces a new sub-crate, `ignore`, which primarily provides a fast recursive directory iterator that respects ignore files like gitignore and other configurable filtering rules based on globs or even file types. This results in a substantial source of complexity moved out of ripgrep's core and into a reusable component that others can now (hopefully) benefit from. While much of the ignore code carried over from ripgrep's core, a substantial portion of it was rewritten with the following goals in mind: 1. Reuse matchers built from gitignore files across directory iteration. 2. Design the matcher data structure to be amenable for parallelizing directory iteration. (Indeed, writing the parallel iterator is the next step.) Fixes #9, #44, #45
2016-10-12 01:57:09 +02:00
[[package]]
name = "ignore"
ignore-0.4.22
2024-01-06 21:27:44 +02:00
version = "0.4.22"
Move all gitignore matching to separate crate. This PR introduces a new sub-crate, `ignore`, which primarily provides a fast recursive directory iterator that respects ignore files like gitignore and other configurable filtering rules based on globs or even file types. This results in a substantial source of complexity moved out of ripgrep's core and into a reusable component that others can now (hopefully) benefit from. While much of the ignore code carried over from ripgrep's core, a substantial portion of it was rewritten with the following goals in mind: 1. Reuse matchers built from gitignore files across directory iteration. 2. Design the matcher data structure to be amenable for parallelizing directory iteration. (Indeed, writing the parallel iterator is the next step.) Fixes #9, #44, #45
2016-10-12 01:57:09 +02:00
dependencies = [
ignore: polish Like previous commits, we do a bit of polishing and bring the style up to my current practice.
2023-09-28 20:17:30 +02:00
"bstr",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"crossbeam-channel",
ignore: use work-stealing stack instead of Arc<Mutex<Vec<_>>> This represents yet another iteration on how `ignore` enqueues and distributes work in parallel. The original implementation used a multi-producer/multi-consumer thread safe queue from crossbeam. At some point, I migrated to a simple `Arc<Mutex<Vec<_>>>` and treated it as a stack so that we did depth first traversal. This helped with memory usage in very wide directories. But it turns out that a naive stack-behind-a-mutex can be quite a bit slower than something that's a little smarter, such as a work-stealing stack used in this commit. My hypothesis for why this helps is that without the stealing component, work distribution can get stuck in sub-optimal configurations that depend on which directory entries get assigned to a particular worker. It's likely that this can result in some workers getting "more" work than others, just by chance, and thus remain idle. But the work-stealing approach heads that off. This does re-introduce a dependency on parts of crossbeam which is kind of a bummer, but it's carrying its weight for now. Closes #1823, Closes #2591 Ref https://github.com/sharkdp/fd/issues/28
2023-08-21 19:58:27 +02:00
"crossbeam-deque",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"globset",
"log",
"memchr",
deps: drop thread_local, lazy_static and once_cell This is largely made possible by the addition of std::sync::OnceLock to the standard library, and the memory pool available in regex-automata.
2023-09-28 22:01:59 +02:00
"regex-automata",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"same-file",
"walkdir",
"winapi-util",
commit Cargo.lock
2016-09-12 01:06:05 +02:00
]
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 15:29:52 +02:00
[[package]]
name = "itoa"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.11"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "49f1f14873335454500d59611f1cf4a4b0f786f9ac11f4312a78e4cf2566695b"
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 15:29:52 +02:00
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
[[package]]
name = "jemalloc-sys"
deps: update everything
2023-08-15 17:09:46 +02:00
version = "0.5.4+5.3.0-patched"
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2023-08-15 17:09:46 +02:00
checksum = "ac6c1946e1cea1788cbfde01c993b52a10e2da07f4bac608228d1bed20bfebf2"
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"cc",
"libc",
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
]
[[package]]
name = "jemallocator"
deps: update everything
2023-08-15 17:09:46 +02:00
version = "0.5.4"
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2023-08-15 17:09:46 +02:00
checksum = "a0de374a9f8e63150e6f5e8a60cc14c668226d7a347d8aee1a45766e3c4dd3bc"
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"jemalloc-sys",
"libc",
]
[[package]]
name = "jobserver"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "0.1.31"
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "d2b099aaa34a9751c5bf0878add70444e1ed2dd73f347be99003d4577277de6e"
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
dependencies = [
"libc",
alloc: use jemalloc when building with musl It turns out that musl's allocator is slow enough to cause a fairly noticeable performance regression when ripgrep is built as a static binary with musl. We fix this by using jemalloc when building with musl. We continue to use the default system allocator in all other scenarios. Namely, glibc's allocator doesn't noticeably regress performance compared to jemalloc. But we could add more targets to this logic if other system allocators (macOS, Windows) prove to be slow. This wasn't necessary before because rustc recently stopped using jemalloc by default. Fixes #1268
2019-04-24 23:21:38 +02:00
]
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
[[package]]
name = "lexopt"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "baff4b617f7df3d896f97fe922b64817f6cd9a756bb81d40f8883f2f66dcb401"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
[[package]]
name = "libc"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.2.153"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "9c198f91728a82281a64e1f4f9eeb25d82cb32a5de251c6bd1b5154d63a8e7bd"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
deps: update everything This adds one new dependency, maybe-uninit, which is brought in by crossbeam-channel[1]. This is to apparently fix some unsound code without bumping the MSRV. Since ripgrep uses the latest stable release of Rust, the maybe-uninit crate should compile down to nothing and just re-export std's `MaybeUninit` type. [1] - https://github.com/crossbeam-rs/crossbeam/pull/458
2020-03-15 14:32:33 +02:00
[[package]]
deps: targeted update of some dependencies This updates encoding_rs, crossbeam-utils and crossbeam-channel. This serves two purposes. The encoding_rs update fixes a compilation failure on the latest nightly. The crossbeam updates are good sense and to reduce duplicate dependencies such as cfg-if. (Although, we note that the log crate still pulls in cfg-if 0.1, so ripgrep has a duplicate dependency there for now. But it's very small.) Fixes #1721, Closes #1705
2020-11-02 16:04:39 +02:00
name = "log"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.4.21"
deps: update everything This adds one new dependency, maybe-uninit, which is brought in by crossbeam-channel[1]. This is to apparently fix some unsound code without bumping the MSRV. Since ripgrep uses the latest stable release of Rust, the maybe-uninit crate should compile down to nothing and just re-export std's `MaybeUninit` type. [1] - https://github.com/crossbeam-rs/crossbeam/pull/458
2020-03-15 14:32:33 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "90ed8c1e510134f979dbc4f070f87d4313098b704861a105fe34231c70a3901c"
deps: update everything This adds one new dependency, maybe-uninit, which is brought in by crossbeam-channel[1]. This is to apparently fix some unsound code without bumping the MSRV. Since ripgrep uses the latest stable release of Rust, the maybe-uninit crate should compile down to nothing and just re-export std's `MaybeUninit` type. [1] - https://github.com/crossbeam-rs/crossbeam/pull/458
2020-03-15 14:32:33 +02:00
deps: upgrade to memchr 2
2017-10-22 00:45:39 +02:00
[[package]]
name = "memchr"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "2.7.2"
bump various versions
2016-12-30 22:43:29 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "6c8640c5d730cb13ebd907d8d04b52f55ac9a2eec55b440c8892f40d56c76c1d"
bump various versions
2016-12-30 22:43:29 +02:00
commit Cargo.lock
2016-09-12 01:06:05 +02:00
[[package]]
deps: replace memmap with memmap2 memmap is unmaintained at this point and it is being flagged as a RUSTSEC advisory in ripgrep. This doesn't seem like that big of a deal to me honestly, but memmap2 looks like a fine choice at this point. Fixes #1785, Closes #1786
2021-01-18 01:49:51 +02:00
name = "memmap2"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.9.4"
bump bytecount to 0.2 Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
2017-11-13 20:55:41 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "fe751422e4a8caa417e13c3ea66452215d7d63e19e604f4980461212f3ae1322"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"libc",
commit Cargo.lock
2016-09-12 01:06:05 +02:00
]
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
[[package]]
name = "once_cell"
version = "1.19.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3fdb12b2476b595f9358c5161aa467c2438859caa136dec86c26fdd2efe17b92"
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 15:29:52 +02:00
[[package]]
name = "pcre2"
deps: bump pcre2 and pcre2-sys This moves to PCRE2 10.43.
2024-03-25 00:58:06 +02:00
version = "0.2.7"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: bump pcre2 and pcre2-sys This moves to PCRE2 10.43.
2024-03-25 00:58:06 +02:00
checksum = "5ea92ff5eabd27703ab12cefe01b08b2809ec3dc75fdc69d4e6b75fbce0cbd67"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"libc",
"log",
"pcre2-sys",
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 15:29:52 +02:00
]
[[package]]
name = "pcre2-sys"
deps: bump pcre2 and pcre2-sys This moves to PCRE2 10.43.
2024-03-25 00:58:06 +02:00
version = "0.2.9"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: bump pcre2 and pcre2-sys This moves to PCRE2 10.43.
2024-03-25 00:58:06 +02:00
checksum = "550f5d18fb1b90c20b87e161852c10cde77858c3900c5059b5ad2a1449f11d8a"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"cc",
"libc",
"pkg-config",
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 15:29:52 +02:00
]
[[package]]
name = "pkg-config"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.3.30"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "d231b230927b5e4ad203db57bbcbee2802f6bce620b1e4a9024a07d94e2907ec"
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 15:29:52 +02:00
[[package]]
name = "proc-macro2"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.81"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "3d1597b0c024618f09a9c3b8655b7e430397a36d23fdafec26d6965e9eec3eba"
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 15:29:52 +02:00
dependencies = [
deps: update all dependencies within semver Note that this adds a new dependency, 'unicode-ident', and removes 'unicode-xid'. I looked briefly at 'unicode-ident' and all looks okay. It is also permissively licensed.
2022-12-20 16:23:29 +02:00
"unicode-ident",
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 15:29:52 +02:00
]
[[package]]
name = "quote"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.36"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "0fa76aaf39101c457836aec0ce2316dbdc3ab723cdda1c6bd4e6ad4208acaca7"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"proc-macro2",
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 15:29:52 +02:00
]
commit Cargo.lock
2016-09-12 01:06:05 +02:00
[[package]]
name = "regex"
deps: bump everything else
2024-03-25 00:58:28 +02:00
version = "1.10.4"
cargo: remove dependency patches I'm too lazy to fixup old commits.
2023-10-10 02:14:34 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: bump everything else
2024-03-25 00:58:28 +02:00
checksum = "c117dbdfde9c8308975b6a18d71f3f385c89461f7b3fb054288ecf2a2058ba4c"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
dependencies = [
deps: initial migration steps to regex 1.9 This leaves the grep-regex crate in tatters. Pretty much the entire thing needs to be re-worked. The upshot is that it should result in some big simplifications. I hope. The idea here is to drop down and actually use regex-automata 0.3 instead of the regex crate itself.
2023-06-12 03:25:23 +02:00
"aho-corasick",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"memchr",
deps: drop temporary patch and move to bstr 1.6 Now that regex 1.9 is out, we can depend on it from crates.io.
2023-07-05 17:08:13 +02:00
"regex-automata",
deps: initial migration steps to regex 1.9 This leaves the grep-regex crate in tatters. Pretty much the entire thing needs to be re-worked. The upshot is that it should result in some big simplifications. I hope. The idea here is to drop down and actually use regex-automata 0.3 instead of the regex crate itself.
2023-06-12 03:25:23 +02:00
"regex-syntax",
commit Cargo.lock
2016-09-12 01:06:05 +02:00
]
[[package]]
deps: initial migration steps to regex 1.9 This leaves the grep-regex crate in tatters. Pretty much the entire thing needs to be re-worked. The upshot is that it should result in some big simplifications. I hope. The idea here is to drop down and actually use regex-automata 0.3 instead of the regex crate itself.
2023-06-12 03:25:23 +02:00
name = "regex-automata"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.4.6"
cargo: remove dependency patches I'm too lazy to fixup old commits.
2023-10-10 02:14:34 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "86b83b8b9847f9bf95ef68afb0b8e6cdb80f498442f5179a29fad448fcc1eaea"
deps: initial migration steps to regex 1.9 This leaves the grep-regex crate in tatters. Pretty much the entire thing needs to be re-worked. The upshot is that it should result in some big simplifications. I hope. The idea here is to drop down and actually use regex-automata 0.3 instead of the regex crate itself.
2023-06-12 03:25:23 +02:00
dependencies = [
"aho-corasick",
"memchr",
"regex-syntax",
]
deps: update everything This does unfortunately bring in both regex-syntax 0.6 and 0.7, but we'll fix that once regex 1.9 is out.
2023-05-16 19:14:23 +02:00
[[package]]
name = "regex-syntax"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "0.8.3"
cargo: remove dependency patches I'm too lazy to fixup old commits.
2023-10-10 02:14:34 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "adad44e29e4c806119491a7f06f03de4d1af22c3a680dd47f1e6e179439d1f56"
deps: update regex crate This update brings with it a new feature of the regex crate which will now use SIMD optimizations automatically at runtime with no necessary compile time flags. All that's needed is to enable the `unstable` feature. Other crates, such as bytecount and encoding_rs, are still using the old-style SIMD support, so we leave the simd-accel and avx-accel features. However, the binaries we distribute on Github no longer have those features enabled, which makes them truly portable. Fixes #135
2018-03-10 21:02:06 +02:00
Update to memmap 0.6 `memmap` 0.6.0 introduces major API changes in anticipation of a 1.0 release. See https://github.com/danburkert/memmap-rs/releases/tag/0.6.0 for more information. CC danburkert/memmap-rs#33.
2017-10-29 00:32:43 +02:00
[[package]]
name = "ripgrep"
14.1.0
2024-01-06 21:32:27 +02:00
version = "14.1.0"
Update to memmap 0.6 `memmap` 0.6.0 introduces major API changes in anticipation of a 1.0 release. See https://github.com/danburkert/memmap-rs/releases/tag/0.6.0 for more information. CC danburkert/memmap-rs#33.
2017-10-29 00:32:43 +02:00
dependencies = [
core: switch to anyhow This commit adds `anyhow` as a dependency and switches over to it from Box<dyn Error>. It actually looks like I've kept all of my errors rather shallow, such that we don't get a huge benefit from anyhow at present. But now that anyhow is in use, I expect to use its "context" feature more going forward.
2023-10-12 18:16:42 +02:00
"anyhow",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"bstr",
"grep",
"ignore",
"jemallocator",
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
"lexopt",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"log",
"serde",
"serde_derive",
"serde_json",
"termcolor",
cli: replace clap with lexopt and supporting code ripgrep began it's life with docopt for argument parsing. Then it moved to Clap and stayed there for a number of years. Clap has served ripgrep well, and it probably could continue to serve ripgrep well, but I ended up deciding to move off of it. Why? The first time I had the thought of moving off of Clap was during the 2->3->4 transition. I thought the 3.x and 4.x releases were great, but for me, it ended up moving a little too quickly. Since the release of 4.x was telegraphed around when 3.x came out, I decided to just hold off and wait to migrate to 4.x instead of doing a 3.x migration followed shortly by another 4.x migration. Of course, I just never ended up doing the migration at all. I never got around to it and there just wasn't a compelling reason for me to upgrade. While I never investigated it, I saw an upgrade as a non-trivial amount of work in part because I didn't encapsulate the usage of Clap enough. The above is just what got me started thinking about it. It wasn't enough to get me to move off of it on its own. What ended up pushing me over the edge was a combination of factors: * As mentioned above, I didn't want to run on the migration treadmill. This has proven to not be much of an issue, but at the time of the 2->3->4 releases, I didn't know how long Clap 4.x would be out before a 5.x would come out. * The release of lexopt[1] caught my eye. IMO, that crate demonstrates exactly how something new can arrive on the scene and just thoroughly solve a problem minimalistically. It has the docs, the reasoning, the simple API, the tests and good judgment. It gets all the weird corner cases right that Clap also gets right (and is part of why I was originally attracted to Clap). * I have an overall desire to reduce the size of my dependency tree. In part because a smaller dependency tree tends to correlate with better compile times, but also in part because it reduces my reliance and trust on others. It lets me be the "master" of ripgrep's destiny by reducing the amount of behavior that is the result of someone else's decision (whether good or bad). * I perceived that Clap solves a more general problem than what I actually need solved. Despite the vast number of flags that ripgrep has, its requirements are actually pretty simple. We just need simple switches and flags that support one value. No multi-value flags. No sub-commands. And probably a lot of other functionality that Clap has that makes it so flexible for so many different use cases. (I'm being hand wavy on the last point.) With all that said, perhaps most importantly, the future of ripgrep possibly demands a more flexible CLI argument parser. In today's world, I would really like, for example, flags like `--type` and `--type-not` to be able to accumulate their repeated values into a single sequence while respecting the order they appear on the CLI. For example, prior to this migration, `rg regex-automata -Tlock -ttoml` would not return results in `Cargo.lock` in this repository because the `-Tlock` always took priority even though `-ttoml` appeared after it. But with this migration, `-ttoml` now correctly overrides `-Tlock`. We would like to do similar things for `-g/--glob` and `--iglob` and potentially even now introduce a `-G/--glob-not` flag instead of requiring users to use `!` to negate a glob. (Which I had done originally to work-around this problem.) And some day, I'd like to add some kind of boolean matching to ripgrep perhaps similar to how `git grep` does it. (Although I haven't thought too carefully on a design yet.) In order to do that, I perceive it would be difficult to implement correctly in Clap. I believe that this last point is possible to implement correctly in Clap 2.x, although it is awkward to do so. I have not looked closely enough at the Clap 4.x API to know whether it's still possible there. In any case, these were enough reasons to move off of Clap and own more of the argument parsing process myself. This did require a few things: * I had to write my own logic for how arguments are combined into one single state object. Of course, I wanted this. This was part of the upside. But it's still code I didn't have to write for Clap. * I had to write my own shell completion generator. * I had to write my own `-h/--help` output generator. * I also had to write my own man page generator. Well, I had to do this with Clap 2.x too, although my understanding is that Clap 4.x supports this. With that said, without having tried it, my guess is that I probably wouldn't have liked the output it generated because I ultimately had to write most of the roff by hand myself to get the man page I wanted. (This also had the benefit of dropping the build dependency on asciidoc/asciidoctor.) While this is definitely a fair bit of extra work, it overall only cost me a couple days. IMO, that's a good trade off given that this code is unlikely to change again in any substantial way. And it should also allow for more flexible semantics going forward. Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966 [1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-17 00:05:39 +02:00
"textwrap",
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"walkdir",
Update to memmap 0.6 `memmap` 0.6.0 introduces major API changes in anticipation of a 1.0 release. See https://github.com/danburkert/memmap-rs/releases/tag/0.6.0 for more information. CC danburkert/memmap-rs#33.
2017-10-29 00:32:43 +02:00
]
deps: update other dependencies to latest
2018-08-20 13:39:43 +02:00
[[package]]
name = "ryu"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "1.0.17"
deps: update other dependencies to latest
2018-08-20 13:39:43 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "e86697c916019a8588c99b5fac3cead74ec0b4b819707a682fd4d23fa0ce1ba1"
deps: update other dependencies to latest
2018-08-20 13:39:43 +02:00
Don't search stdout redirected file. When running ripgrep like this: rg foo > output we must be careful not to search `output` since ripgrep is actively writing to it. Searching it can cause massive blowups where the file grows without bound. While this is conceptually easy to fix (check the inode of the redirection and the inode of the file you're about to search), there are a few problems with it. First, inodes are a Unix thing, so we need a Windows specific solution to this as well. To resolve this concern, I created a new crate, `same-file`, which provides a cross platform abstraction. Second, stat'ing every file is costly. This is not avoidable on Windows, but on Unix, we can get the inode number directly from directory traversal. However, this information wasn't exposed, but now it is (through both the ignore and walkdir crates). Fixes #286
2017-01-08 17:27:30 +02:00
[[package]]
name = "same-file"
deps: update everything
2020-01-17 02:47:23 +02:00
version = "1.0.6"
Don't search stdout redirected file. When running ripgrep like this: rg foo > output we must be careful not to search `output` since ripgrep is actively writing to it. Searching it can cause massive blowups where the file grows without bound. While this is conceptually easy to fix (check the inode of the redirection and the inode of the file you're about to search), there are a few problems with it. First, inodes are a Unix thing, so we need a Windows specific solution to this as well. To resolve this concern, I created a new crate, `same-file`, which provides a cross platform abstraction. Second, stat'ing every file is costly. This is not avoidable on Windows, but on Unix, we can get the inode number directly from directory traversal. However, this information wasn't exposed, but now it is (through both the ignore and walkdir crates). Fixes #286
2017-01-08 17:27:30 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
checksum = "93fc1dc3aaa9bfed95e02e6eadabb4baf7e3078b0bd1b4d7b6b0b68378900502"
Don't search stdout redirected file. When running ripgrep like this: rg foo > output we must be careful not to search `output` since ripgrep is actively writing to it. Searching it can cause massive blowups where the file grows without bound. While this is conceptually easy to fix (check the inode of the redirection and the inode of the file you're about to search), there are a few problems with it. First, inodes are a Unix thing, so we need a Windows specific solution to this as well. To resolve this concern, I created a new crate, `same-file`, which provides a cross platform abstraction. Second, stat'ing every file is costly. This is not avoidable on Windows, but on Unix, we can get the inode number directly from directory traversal. However, this information wasn't exposed, but now it is (through both the ignore and walkdir crates). Fixes #286
2017-01-08 17:27:30 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"winapi-util",
Don't search stdout redirected file. When running ripgrep like this: rg foo > output we must be careful not to search `output` since ripgrep is actively writing to it. Searching it can cause massive blowups where the file grows without bound. While this is conceptually easy to fix (check the inode of the redirection and the inode of the file you're about to search), there are a few problems with it. First, inodes are a Unix thing, so we need a Windows specific solution to this as well. To resolve this concern, I created a new crate, `same-file`, which provides a cross platform abstraction. Second, stat'ing every file is costly. This is not avoidable on Windows, but on Unix, we can get the inode number directly from directory traversal. However, this information wasn't exposed, but now it is (through both the ignore and walkdir crates). Fixes #286
2017-01-08 17:27:30 +02:00
]
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 15:29:52 +02:00
[[package]]
name = "serde"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.198"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "9846a40c979031340571da2545a4e5b7c4163bdae79b301d5f86d03979451fcc"
edition: manual changes This is mostly just about removing 'extern crate' everywhere and fixing the fallout.
2021-06-02 02:45:45 +02:00
dependencies = [
"serde_derive",
]
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 15:29:52 +02:00
[[package]]
name = "serde_derive"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.198"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "e88edab869b01783ba905e7d0153f9fc1a6505a96e4ad3018011eedb838566d9"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"proc-macro2",
"quote",
"syn",
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 15:29:52 +02:00
]
[[package]]
name = "serde_json"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "1.0.116"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "3e17db7126d17feb94eb3fad46bf1a96b034e8aacbc2e775fe81505f8b0b2813"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"itoa",
"ryu",
"serde",
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 15:29:52 +02:00
]
[[package]]
name = "syn"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
version = "2.0.60"
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 15:29:52 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "909518bc7b1c9b779f1bbf07f2929d35af9f0f37e47c6e9ef7f9dddc1e1821f3"
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 15:29:52 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"proc-macro2",
"quote",
deps: update all dependencies within semver Note that this adds a new dependency, 'unicode-ident', and removes 'unicode-xid'. I looked briefly at 'unicode-ident' and all looks okay. It is also permissively licensed.
2022-12-20 16:23:29 +02:00
"unicode-ident",
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 15:29:52 +02:00
]
Switch from Docopt to Clap. There were two important reasons for the switch: 1. Performance. Docopt does poorly when the argv becomes large, which is a reasonable common use case for search tools. (e.g., use with xargs) 2. Better failure modes. Clap knows a lot more about how a particular argv might be invalid, and can therefore provide much clearer error messages. While both were important, (1) made it urgent. Note that since Clap requires at least Rust 1.11, this will in turn increase the minimum Rust version supported by ripgrep from Rust 1.9 to Rust 1.11. It is therefore a breaking change, so the soonest release of ripgrep with Clap will have to be 0.3. There is also at least one subtle breaking change in real usage. Previous to this commit, this used to work: rg -e -foo Where this would cause ripgrep to search for the string `-foo`. Clap currently has problems supporting this use case (see: https://github.com/kbknapp/clap-rs/issues/742), but it can be worked around by using this instead: rg -e [-]foo or even rg [-]foo and this still works: rg -- -foo This commit also adds Bash, Fish and PowerShell completion files to the release, fixes a bug that prevented ripgrep from working on file paths containing invalid UTF-8 and shows short descriptions in the output of `-h` but longer descriptions in the output of `--help`. Fixes #136, Fixes #189, Fixes #210, Fixes #230
2016-11-13 04:48:11 +02:00
[[package]]
Completely re-work colored output and tty handling. This commit completely guts all of the color handling code and replaces most of it with two new crates: wincolor and termcolor. wincolor provides a simple API to coloring using the Windows console and termcolor provides a platform independent coloring API tuned for multithreaded command line programs. This required a lot more flexibility than what the `term` crate provided, so it was dropped. We instead switch to writing ANSI escape sequences directly and ignore the TERMINFO database. In addition to fixing several bugs, this commit also permits end users to customize colors to a certain extent. For example, this command will set the match color to magenta and the line number background to yellow: rg --colors 'match:fg:magenta' --colors 'line:bg:yellow' foo For tty handling, we've adopted a hack from `git` to do tty detection in MSYS/mintty terminals. As a result, ripgrep should get both color detection and piping correct on Windows regardless of which terminal you use. Finally, switch to line buffering. Performance doesn't seem to be impacted and it's an otherwise more user friendly option. Fixes #37, Fixes #51, Fixes #94, Fixes #117, Fixes #182, Fixes #231
2016-11-20 18:14:52 +02:00
name = "termcolor"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "1.4.1"
deps: update termcolor to 1.0.0
2018-07-18 00:37:02 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "06794f8f6c5c898b3275aebefa6b8a1cb24cd2c6c79397ab15774837a0bc5755"
Switch from Docopt to Clap. There were two important reasons for the switch: 1. Performance. Docopt does poorly when the argv becomes large, which is a reasonable common use case for search tools. (e.g., use with xargs) 2. Better failure modes. Clap knows a lot more about how a particular argv might be invalid, and can therefore provide much clearer error messages. While both were important, (1) made it urgent. Note that since Clap requires at least Rust 1.11, this will in turn increase the minimum Rust version supported by ripgrep from Rust 1.9 to Rust 1.11. It is therefore a breaking change, so the soonest release of ripgrep with Clap will have to be 0.3. There is also at least one subtle breaking change in real usage. Previous to this commit, this used to work: rg -e -foo Where this would cause ripgrep to search for the string `-foo`. Clap currently has problems supporting this use case (see: https://github.com/kbknapp/clap-rs/issues/742), but it can be worked around by using this instead: rg -e [-]foo or even rg [-]foo and this still works: rg -- -foo This commit also adds Bash, Fish and PowerShell completion files to the release, fixes a bug that prevented ripgrep from working on file paths containing invalid UTF-8 and shows short descriptions in the output of `-h` but longer descriptions in the output of `--help`. Fixes #136, Fixes #189, Fixes #210, Fixes #230
2016-11-13 04:48:11 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"winapi-util",
Switch from Docopt to Clap. There were two important reasons for the switch: 1. Performance. Docopt does poorly when the argv becomes large, which is a reasonable common use case for search tools. (e.g., use with xargs) 2. Better failure modes. Clap knows a lot more about how a particular argv might be invalid, and can therefore provide much clearer error messages. While both were important, (1) made it urgent. Note that since Clap requires at least Rust 1.11, this will in turn increase the minimum Rust version supported by ripgrep from Rust 1.9 to Rust 1.11. It is therefore a breaking change, so the soonest release of ripgrep with Clap will have to be 0.3. There is also at least one subtle breaking change in real usage. Previous to this commit, this used to work: rg -e -foo Where this would cause ripgrep to search for the string `-foo`. Clap currently has problems supporting this use case (see: https://github.com/kbknapp/clap-rs/issues/742), but it can be worked around by using this instead: rg -e [-]foo or even rg [-]foo and this still works: rg -- -foo This commit also adds Bash, Fish and PowerShell completion files to the release, fixes a bug that prevented ripgrep from working on file paths containing invalid UTF-8 and shows short descriptions in the output of `-h` but longer descriptions in the output of `--help`. Fixes #136, Fixes #189, Fixes #210, Fixes #230
2016-11-13 04:48:11 +02:00
]
bump clap to 2.26 Fixes #482
2017-07-31 00:04:49 +02:00
[[package]]
name = "textwrap"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "0.16.1"
bump clap to 2.26 Fixes #482
2017-07-31 00:04:49 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "23d434d3f8967a09480fb04132ebe0a3e088c173e6d0ee7897abbdf4eab0f8b9"
bump clap to 2.26 Fixes #482
2017-07-31 00:04:49 +02:00
Switch from Docopt to Clap. There were two important reasons for the switch: 1. Performance. Docopt does poorly when the argv becomes large, which is a reasonable common use case for search tools. (e.g., use with xargs) 2. Better failure modes. Clap knows a lot more about how a particular argv might be invalid, and can therefore provide much clearer error messages. While both were important, (1) made it urgent. Note that since Clap requires at least Rust 1.11, this will in turn increase the minimum Rust version supported by ripgrep from Rust 1.9 to Rust 1.11. It is therefore a breaking change, so the soonest release of ripgrep with Clap will have to be 0.3. There is also at least one subtle breaking change in real usage. Previous to this commit, this used to work: rg -e -foo Where this would cause ripgrep to search for the string `-foo`. Clap currently has problems supporting this use case (see: https://github.com/kbknapp/clap-rs/issues/742), but it can be worked around by using this instead: rg -e [-]foo or even rg [-]foo and this still works: rg -- -foo This commit also adds Bash, Fish and PowerShell completion files to the release, fixes a bug that prevented ripgrep from working on file paths containing invalid UTF-8 and shows short descriptions in the output of `-h` but longer descriptions in the output of `--help`. Fixes #136, Fixes #189, Fixes #210, Fixes #230
2016-11-13 04:48:11 +02:00
[[package]]
deps: update all dependencies within semver Note that this adds a new dependency, 'unicode-ident', and removes 'unicode-xid'. I looked briefly at 'unicode-ident' and all looks okay. It is also permissively licensed.
2022-12-20 16:23:29 +02:00
name = "unicode-ident"
deps: update everything Notably, this includes termcolor 1.3, which comes with hyperlink support.
2023-09-19 03:42:32 +02:00
version = "1.0.12"
Switch from Docopt to Clap. There were two important reasons for the switch: 1. Performance. Docopt does poorly when the argv becomes large, which is a reasonable common use case for search tools. (e.g., use with xargs) 2. Better failure modes. Clap knows a lot more about how a particular argv might be invalid, and can therefore provide much clearer error messages. While both were important, (1) made it urgent. Note that since Clap requires at least Rust 1.11, this will in turn increase the minimum Rust version supported by ripgrep from Rust 1.9 to Rust 1.11. It is therefore a breaking change, so the soonest release of ripgrep with Clap will have to be 0.3. There is also at least one subtle breaking change in real usage. Previous to this commit, this used to work: rg -e -foo Where this would cause ripgrep to search for the string `-foo`. Clap currently has problems supporting this use case (see: https://github.com/kbknapp/clap-rs/issues/742), but it can be worked around by using this instead: rg -e [-]foo or even rg [-]foo and this still works: rg -- -foo This commit also adds Bash, Fish and PowerShell completion files to the release, fixes a bug that prevented ripgrep from working on file paths containing invalid UTF-8 and shows short descriptions in the output of `-h` but longer descriptions in the output of `--help`. Fixes #136, Fixes #189, Fixes #210, Fixes #230
2016-11-13 04:48:11 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this includes termcolor 1.3, which comes with hyperlink support.
2023-09-19 03:42:32 +02:00
checksum = "3354b9ac3fae1ff6755cb6db53683adb661634f67557942dea4facebec0fee4b"
Switch from Docopt to Clap. There were two important reasons for the switch: 1. Performance. Docopt does poorly when the argv becomes large, which is a reasonable common use case for search tools. (e.g., use with xargs) 2. Better failure modes. Clap knows a lot more about how a particular argv might be invalid, and can therefore provide much clearer error messages. While both were important, (1) made it urgent. Note that since Clap requires at least Rust 1.11, this will in turn increase the minimum Rust version supported by ripgrep from Rust 1.9 to Rust 1.11. It is therefore a breaking change, so the soonest release of ripgrep with Clap will have to be 0.3. There is also at least one subtle breaking change in real usage. Previous to this commit, this used to work: rg -e -foo Where this would cause ripgrep to search for the string `-foo`. Clap currently has problems supporting this use case (see: https://github.com/kbknapp/clap-rs/issues/742), but it can be worked around by using this instead: rg -e [-]foo or even rg [-]foo and this still works: rg -- -foo This commit also adds Bash, Fish and PowerShell completion files to the release, fixes a bug that prevented ripgrep from working on file paths containing invalid UTF-8 and shows short descriptions in the output of `-h` but longer descriptions in the output of `--help`. Fixes #136, Fixes #189, Fixes #210, Fixes #230
2016-11-13 04:48:11 +02:00
commit Cargo.lock
2016-09-12 01:06:05 +02:00
[[package]]
name = "walkdir"
deps: update everything
2024-03-07 16:38:22 +02:00
version = "2.5.0"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything
2024-03-07 16:38:22 +02:00
checksum = "29790946404f91d9c5d06f9874efddea1dc06c5efe94541a7d6863108e3a5e4b"
commit Cargo.lock
2016-09-12 01:06:05 +02:00
dependencies = [
deps: bump pcre2-sys This should bring a compilation time improvement when building static buils of PCRE2 by enabling parallelism for C compilation. Kudos to @JoshTriplett for the tip!
2020-08-20 00:55:16 +02:00
"same-file",
"winapi-util",
commit Cargo.lock
2016-09-12 01:06:05 +02:00
]
deps: update all deps
2017-12-30 22:48:25 +02:00
[[package]]
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
name = "winapi-util"
version = "0.1.7"
deps: update all deps
2017-12-30 22:48:25 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "134306a13c5647ad6453e8deaec55d3a44d6021970129e6188735e74bf546697"
deps: update all deps
2017-12-30 22:48:25 +02:00
dependencies = [
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
"windows-sys",
deps: update all deps
2017-12-30 22:48:25 +02:00
]
[[package]]
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
name = "windows-sys"
version = "0.52.0"
deps: update all deps
2017-12-30 22:48:25 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "282be5f36a8ce781fad8c8ae18fa3f9beff57ec1b52cb3de0789201425d9a33d"
dependencies = [
"windows-targets",
]
deps: update all deps
2017-12-30 22:48:25 +02:00
deps: update various deps This includes a new crate, winapi-util, that is now used in wincolor, walkdir and same-file.
2018-08-25 06:19:40 +02:00
[[package]]
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
name = "windows-targets"
version = "0.52.5"
deps: update various deps This includes a new crate, winapi-util, that is now used in wincolor, walkdir and same-file.
2018-08-25 06:19:40 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "6f0713a46559409d202e70e28227288446bf7841d3211583a4b53e3f6d96e7eb"
deps: update various deps This includes a new crate, winapi-util, that is now used in wincolor, walkdir and same-file.
2018-08-25 06:19:40 +02:00
dependencies = [
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
"windows_aarch64_gnullvm",
"windows_aarch64_msvc",
"windows_i686_gnu",
"windows_i686_gnullvm",
"windows_i686_msvc",
"windows_x86_64_gnu",
"windows_x86_64_gnullvm",
"windows_x86_64_msvc",
deps: update various deps This includes a new crate, winapi-util, that is now used in wincolor, walkdir and same-file.
2018-08-25 06:19:40 +02:00
]
deps: update all deps
2017-12-30 22:48:25 +02:00
[[package]]
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
name = "windows_aarch64_gnullvm"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7088eed71e8b8dda258ecc8bac5fb1153c5cffaf2578fc8ff5d61e23578d3263"
[[package]]
name = "windows_aarch64_msvc"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9985fd1504e250c615ca5f281c3f7a6da76213ebd5ccc9561496568a2752afb6"
[[package]]
name = "windows_i686_gnu"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "88ba073cf16d5372720ec942a8ccbf61626074c6d4dd2e745299726ce8b89670"
[[package]]
name = "windows_i686_gnullvm"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "87f4261229030a858f36b459e748ae97545d6f1ec60e5e0d6a3d32e0dc232ee9"
[[package]]
name = "windows_i686_msvc"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "db3c2bf3d13d5b658be73463284eaf12830ac9a26a90c717b7f771dfe97487bf"
[[package]]
name = "windows_x86_64_gnu"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4e4246f76bdeff09eb48875a0fd3e2af6aada79d409d33011886d3e1581517d9"
[[package]]
name = "windows_x86_64_gnullvm"
version = "0.52.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "852298e482cd67c356ddd9570386e2862b5673c85bd5f88df9ab6802b334c596"
[[package]]
name = "windows_x86_64_msvc"
version = "0.52.5"
deps: update all deps
2017-12-30 22:48:25 +02:00
source = "registry+https://github.com/rust-lang/crates.io-index"
deps: update everything Notably, this removes winapi in favor of windows-sys, as a result of winapi-util switching over to windows-sys[1]. Annoyingly, when PCRE2 is enabled, this brings in a dependency on `once_cell`[2]. I had worked to remove it from my dependencies and now it's back. Gah. I suppose I could disable the `parallel` feature of `cc`, but that doesn't seem like a good trade-off. [1]: https://github.com/BurntSushi/winapi-util/pull/13 [2]: https://github.com/rust-lang/cc-rs/pull/1037
2024-04-23 16:43:25 +02:00
checksum = "bec47e5bfd1bff0eeaf6d8b485cc1074891a197ab4225d504cb7a1ab88b02bf0"
Reference in New Issue Copy Permalink