agent: Add more Rust code examples, update TODO check (#28737)

Release Notes:

- N/A
This commit is contained in:
Thomas Mickley-Doyle 2025-04-15 11:52:08 -05:00 committed by GitHub
parent d0f806456c
commit b1e4e6048a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
38 changed files with 142 additions and 2 deletions

View file

@ -0,0 +1,3 @@
url = "https://github.com/GyulyVGC/sniffnet.git"
revision = "cfb5b6519bd7838f279e5be9d360445aaffaa647"
language_extension = "rs"

View file

@ -0,0 +1,16 @@
1. **Protocol Enumeration:** Ensure the `Protocol` enum includes the `ARP` variant and is integrated in `Protocol::ALL`.
2. **Packet Analysis Logic:**
- Properly detect ARP packets within `analyze_headers` and `analyze_network_header`.
- Appropriately extract ARP sender/target IPs based on the protocol (IPv4 or IPv6).
- Track and store ARP operations (Request, Reply) using the `ArpType` enum.
3. **Display & User Interface:**
- Accurately represent ARP packet types in the UI (`connection_details_page.rs`) alongside ICMP types.
- Skip displaying service information for ARP packets in line with ICMP behavior.
4. **Data Struct Enhancements:**
- Update `InfoAddressPortPair` to store and count ARP operation types.
- Ensure filtering and presentation logic uses ARP data correctly.
5. **Default Behaviors:**
- Set default `protocol` in `PacketFiltersFields` to `ARP` for consistency.
6. **Testing:**
- Update unit tests for `Protocol::ALL` and `get_service` to account for ARP behavior.
- Confirm that ARP protocol toggling works properly in the GUI protocol filter handling.

View file

@ -0,0 +1 @@
Add full support for the Address Resolution Protocol (ARP) in the packet sniffer. This includes recognizing ARP packets during packet analysis, displaying ARP operation types in the UI, and updating data structures to track ARP-specific metadata. Integrate ARP into the protocol filtering system, update all relevant UI logic to ensure it handles ARP packets similarly to ICMP, and ensure proper test coverage for all new functionality. Update `Protocol::ALL` to include ARP and skip service detection for ARP packets, as they dont use ports. Finally, ensure the `connection_details_page` displays the ARP operation types with counts, using a `pretty_print_types` method similar to ICMP types.

View file

@ -0,0 +1,3 @@
url = "https://github.com/swc-project/swc.git"
revision = "787d5fabf410fafe6595ec00c197181b27578cb1"
language_extension = "rs"

View file

@ -0,0 +1,6 @@
1. The `parse` and `parse_sync` functions must support both `Buffer` and `String` inputs for the `src` parameter, using the `Either` type from `napi` to avoid breaking existing string-based usage while adding buffer support.
2. A helper function `stringify` must handle conversion of `Either<Buffer, String>` to a unified `String` representation internally, ensuring consistent UTF-8 decoding for buffers and direct string passthrough.
3. The TypeScript binding declarations (`binding.d.ts`) must reflect the updated parameter types for `parse` and `parse_sync` to accept `Buffer | string`, ensuring compatibility with JavaScript/TypeScript callers.
4. Unit tests must validate both buffer and string input paths for asynchronous (`parse`) and synchronous (`parse_sync`) APIs, ensuring parity in functionality and output correctness.
5. The `filename` parameter must remain optional but use `FileName::Real` when provided and fall back to `FileName::Anon` if omitted, preserving existing file resolution logic.
6. No regressions in error handling, abort signal support, or serialization/deserialization of `ParseOptions` during the refactor.

View file

@ -0,0 +1 @@
I need to extend the SWC parsing APIs to support both `Buffer` and `string` inputs for the source code. Please update the `parse` and `parse_sync` functions to accept `Either<Buffer, String>` instead of just `String`. Add a helper function to convert the `Either` type into a UTF-8 string, using `String::from_utf8_lossy` for buffers to handle invalid characters gracefully. Ensure the TypeScript definitions in `binding.d.ts` reflect the new parameter types. Include unit tests for both buffer and string inputs in `api_test.js`, verifying that asynchronous and synchronous parsing produce identical results regardless of input type. Maintain backward compatibility with existing string-based calls and ensure the `filename` fallback logic remains unchanged. Simplify the `src` handling to avoid code duplication between async/sync paths.

View file

@ -0,0 +1,3 @@
url = "https://github.com/dani-garcia/vaultwarden.git"
revision = "3a1f1bae002bebf26ce3a38b879c1ba26529af1e"
language_extension = "rs"

View file

@ -0,0 +1,6 @@
1. Refactors the `register_verification_email` logic to generate the JWT verification token earlier in the control flow, reducing duplication and improving readability.
2. Improves conditional logic for sending verification emails by only querying the database when mail should be sent, reducing unnecessary operations.
3. Refines the user existence check to specifically filter for users that have a `private_key`, adding stricter criteria before skipping email sending.
4. Preserves existing timing attack mitigation by retaining randomized sleep behavior when user exists but an email is not sent.
5. Ensures the email is sent only if appropriate, preserving previous behavior while streamlining logic and improving maintainability.
6. Removes redundant code paths and unnecessary reassignments, improving clarity without affecting functionality.

View file

@ -0,0 +1 @@
I want to refactor the `register_verification_email` function to streamline how verification emails are handled. Currently, the code checks if a user exists and then sends an email or returns early. Id like to move the JWT token generation to the top of the function to avoid duplication. Then, if mail sending is enabled, the code should check for the user, but only send the verification email if the user exists and has a `private_key` (otherwise it should send the email). Keep the random sleep logic for timing mitigation in the branch where no email is sent. Remove the old duplicated token generation logic and any redundant conditionals, while ensuring the core behavior and response flow stays the same.

View file

@ -0,0 +1,3 @@
url = "https://github.com/qarmin/czkawka.git"
revision = "db164d3698198dd46653b1c3bb0384f8a9e38fab"
language_extension = "rs"

View file

@ -0,0 +1,7 @@
1. **EXIF-based Rotation Handling**: Introduces image orientation correction using EXIF metadata by parsing orientation tags and applying corresponding image transformations (e.g., flip, rotate). This improves accuracy for displaying and analyzing images with embedded rotation data.
2. **New Dependencies and Parsing Logic**: Adds `nom-exif`, `iso6709parse`, and related dependencies for reading EXIF metadata, and implements robust parsing logic using `MediaParser`, `ExifIter`, and orientation matching for clean integration.
3. **Expanded `common_image.rs` Logic**: Refactors image loading in `get_dynamic_image_from_path` to automatically apply EXIF-based orientation corrections, adding new helper methods (`get_rotation_from_exif`) and an `ExifOrientation` enum to encapsulate the rotation logic clearly and maintainably.
4. **Versioning and Compatibility Updates**: Updates minimum Rust version to 1.80.0 across all packages and workflows, ensuring compatibility with newly introduced crates and language features.
5. **Internal Versioning Sync**: Increments `CACHE_IMAGE_VERSION` to ensure cache invalidation reflects new image processing logic, preventing mismatches due to transformed image data.
6. **Dependency Management and Cargo.toml Additions**: Adds new crate dependencies to `Cargo.toml` files where necessary (`czkawka_core`, `Cargo.lock`) and aligns versions to reflect new EXIF parsing functionality.
7. **GUI State Initialization Adjustment**: Modifies GUI default tab state from `SimilarImages` to `DuplicateFiles`—likely for improved UX or alignment with application focus.

View file

@ -0,0 +1 @@
I'd like to implement support for automatic image orientation correction based on EXIF metadata in our Rust project. Specifically, I want to use the `nom-exif` crate to read EXIF orientation tags and adjust the image accordingly (e.g., flip horizontally, rotate 90° CW, etc.) when loading it in `get_dynamic_image_from_path`. Please integrate the EXIF parsing flow using `MediaParser`, `ExifIter`, and match the orientation codes 18 to a custom `ExifOrientation` enum. Ensure that these transformations are applied directly to the `DynamicImage` output when applicable. Also, bump the `CACHE_IMAGE_VERSION` to invalidate any outdated cached formats and update the Rust version across the codebase to `1.80.0` to support the latest dependencies. Make any required changes to Cargo.toml and lockfiles, and default the GUI to open the Duplicate Files tab instead of Similar Images for consistency.

View file

@ -0,0 +1,3 @@
url = "https://github.com/clockworklabs/SpacetimeDB.git"
revision = "68d23d4c25548fd74f1bde28a57d8858022b9671"
language_extension = "rs"

View file

@ -0,0 +1,6 @@
1. A `JOIN` query with conditions on both sides (LHS and RHS) correctly triggers subscription updates when only the LHS table is updated.
2. Callback functions (`on_insert`, `on_update`) are invoked exactly once and in the expected order.
3. Queries with logically equivalent WHERE conditions (e.g., `x > 0 and x < 5` vs. `0 < x and x < 5`) yield consistent subscription behavior.
4. Complex disjoint queries that restrict the RHS via additional constraints (e.g., `u.n != 1`) still properly identify matching LHS updates.
5. Type inference and expression normalization correctly handle literals on the left-hand side of binary operations in WHERE clauses.
6. Physical execution plans normalize expressions like `3 < l.x` into `l.x > 3` with appropriate operator inversion (`Lt ↔ Gt`, `Lte ↔ Gte`), maintaining logical correctness.

View file

@ -0,0 +1,12 @@
Add a new test case to validate join subscription updates when the **LHS table is updated**, and ensure correct invocation of reducer callbacks. The test should:
- Subscribe to a join query with a filter involving fields from both tables (e.g., `SELECT p.* FROM pk_u32 p JOIN unique_u32 u ON p.n = u.n WHERE u.data > 0 AND u.data < 5`).
- Insert rows into both LHS (`pk_u32`) and RHS (`unique_u32`) that satisfy the join condition.
- Verify the initial subscription callback is triggered via `on_insert`.
- Update the LHS (`pk_u32`) such that the row remains part of the join result.
- Validate that:
- `on_update` is invoked correctly.
- An immediate follow-up update back to the original value also triggers `on_update`.
- Repeat the above with disjoint filters (e.g., `u.n != 1`) and confirm behavior remains correct.
Also, ensure that literal-first SQL expressions like `3 < x` are correctly interpreted and inverted in the physical execution plan (converted to `x > 3`) and behave identically during query evaluation and execution.

View file

@ -0,0 +1,3 @@
url = "https://github.com/Rust-GPU/Rust-CUDA.git"
revision = "728013419b6c4c80e099a42413574c36a9aff9c7"
language_extension = "rs"

View file

@ -0,0 +1,4 @@
1. **Reexports `LIBDEVICE_BITCODE` for cleaner dependency usage:** The `LIBDEVICE_BITCODE` symbol from the `cust_raw::nvvm_sys` crate is now reexported via the `nvvm` crate. This allows consuming crates to access the symbol directly from `nvvm`, abstracting away the internal structure and reducing tight coupling to `cust_raw`.
2. **Simplifies dependency graph and usage of NVVM internals:** By removing the direct dependency on `cust_raw` from `rustc_codegen_nvvm`, the changes streamline the crate's external interface, reducing maintenance overhead and improving modularity. Consumers now only need to rely on the higher-level `nvvm` crate.
3. **Improves code readability and encapsulation:** The change makes the source cleaner by reducing low-level, verbose paths like `nvvm_sys::LIBDEVICE_BITCODE` to a concise `LIBDEVICE_BITCODE`, enhancing readability and reinforcing a layered architecture.
4. **Maintains existing functionality:** The code logic remains unchanged in behavior—`LIBDEVICE_BITCODE` is still used in the same way, ensuring that the refactor is safe, non-breaking, and purely organizational.

View file

@ -0,0 +1 @@
I'd like to improve the modularity and encapsulation of the NVVM codegen setup. Please refactor the code to reexport `LIBDEVICE_BITCODE` from the `nvvm` crate instead of accessing it directly from `cust_raw::nvvm_sys`. This involves updating the `nvvm` crate to publicly reexport the symbol, and then modifying `rustc_codegen_nvvm` to use the reexported path. Additionally, remove the direct dependency on `cust_raw` from `rustc_codegen_nvvm/Cargo.toml` and clean up any redundant `use` statements that reference `cust_raw` directly. The goal is to simplify usage of `nvvm_sys` internals by encapsulating them within `nvvm`, making the codebase more maintainable without changing its behavior.

View file

@ -1,3 +1,3 @@
url = "https://github.com/SAP-samples/abap-cheat-sheets.git"
revision = "262c0472eeb03e05ff8235767356a328d97850e6"
require_lsp = false
language_extension = "rs"

View file

@ -0,0 +1,3 @@
url = "https://github.com/clockworklabs/SpacetimeDB.git"
revision = "13dfb031351c3adf308c74b2a085ca15aa797db1"
language_extension = "rs"

View file

@ -0,0 +1,6 @@
1. The function `report_data_size` has been refactored to have a more accessible visibility by changing from `pub(super)` to `pub` in the `CommittedState` struct, making it usable outside of its previous scope.
2. The `record_tx_metrics` function has been modified to remove the previously commented-out code that invoked `report_data_size` from `committed_state`. The intention to possibly inline this functionality or refactor the metrics updates is noted.
3. A new function `update_data_size_metrics` has been introduced in the `RelationalDB` struct to simplify calling the `report_data_size` method, enhancing clarity and direct usage within the database context.
4. The `storage_monitor` function has been renamed and refactored to `metric_reporter`, which is tasked with collecting disk usage statistics and invoking `update_data_size_metrics` for database state updates.
5. Various asynchronous operations involving time intervals for disk usage measurement and reporting have been restructured for improved metric collection, reducing unnecessary operations and improving clarity.
6. Comments and TODOs are placed where further improvements, such as adding heap usage metrics, are possible, guiding future enhancements.

View file

@ -0,0 +1 @@
I'd like to refactor and improve the metric collection system in the database layer. Specifically, please refactor the `report_data_size` function to make it publicly accessible by changing its visibility from `pub(super)` to `pub`. Then, remove the commented-out `report_data_size` invocation from `record_tx_metrics` in the `datastore.rs` file and ensure that metric collection is more streamlined. Add a new function in the `RelationalDB` struct named `update_data_size_metrics` to simplify invoking `report_data_size` and enhance its usage across the code. Finally, refactor the `storage_monitor` function by renaming it to `metric_reporter`, and ensure that it periodically collects disk usage statistics and updates data size metrics. Additionally, leave a TODO in the code for adding heap usage metrics in the future. Please ensure that these changes maintain the core functionality while improving the overall organization and clarity of the code.

View file

@ -0,0 +1,3 @@
url = "https://github.com/bevyengine/bevy.git"
revision = "ac52cca033b351cc966cd3d40eb99ffbefbdb104"
language_extension = "rs"

View file

@ -0,0 +1,5 @@
1. Introduces a stable-Rust-compatible workaround for the unstable `!` (never) type by implementing a custom `Never` alias based on a trait (`FnRet`) and function signature (`fn() -> !`), mimicking the behavior of the `never_say_never` crate without an external dependency.
2. Adds trait impls that enable Bevy systems and commands to accept `Never` as an output type, ensuring compatibility with panicking closures or intentionally non-returning functions like `todo!()` or `panic!()`.
3. Updates internal wrappers (`InfallibleSystemWrapper`, `InfallibleObserverWrapper`) and trait bounds across observer and schedule systems to support this workaround by allowing `Never` as a valid output type while maintaining existing fallible/infallible behavior.
4. Adds robust regression test coverage to ensure these `Never`-based trait implementations compile and function as expected, specifically targeting closures and functions that use `todo!()` or diverge without returning.
5. Ensures this workaround does not compromise stability guarantees by isolating `Never` usage to internal APIs and clearly documenting the risks and rationale in the new `never.rs` module.

View file

@ -0,0 +1 @@
I'd like to add stable Rust support for handling the `!` (never) type in Bevy's ECS systems, in light of changes introduced in the Rust 2024 edition around never type fallback inference. Please create a new internal module (e.g., `never.rs`) that provides a type alias `Never` using a workaround based on a trait and `fn() -> !` to simulate the behavior of the unstable `!` type. Update the necessary traits and system wrappers (such as `HandleError`, `IntoScheduleConfigs`, and `IntoObserverSystem`) to accept `Never` as a valid output type, ensuring that closures or systems using `todo!()` or panics can still compile and behave correctly. Add a set of regression tests that exercise this compatibility by queuing and scheduling systems and commands with `todo!()` as their body, ensuring trait impls are resolved properly. Make sure to document this hack in the new module with a clear explanation of why it's being used and the risks involved.

View file

@ -0,0 +1,3 @@
url = "https://github.com/alacritty/alacritty.git"
revision = "c9c41e637ac49f3cd67cf0362c596ae9d947f896"
language_extension = "rs"

View file

@ -0,0 +1,6 @@
1. **Field Renaming and Semantic Clarification**: The `hold` field in `Options`, `TerminalOptions`, and `PtyOptions` has been renamed to `drain_on_exit` across the codebase. This improves semantic clarity by distinguishing between two distinct behaviors: draining output before exit versus holding the terminal open after exit.
2. **Behavioral Shift in Exit Logic**: The logic previously controlled by `hold` now uses `drain_on_exit`, ensuring the child processs output is drained upon termination, but the window may still close unless explicitly held open via external means. Exit handling in `event_loop.rs` has been updated to reflect this behavioral distinction.
3. **Config and Struct Updates**: All related structs (`UiConfig`, `Window`, `WindowContext`, `EventLoop`) have been updated to reflect the new `drain_on_exit` naming. This ensures consistent naming and avoids legacy confusion.
4. **UI Window Behavior**: A new `hold` field has been added to the `Window` struct to manage whether the terminal window should remain open on exit, separating UI behavior from terminal process behavior.
5. **Exit Control Improvements**: When a user closes a window manually (`CloseRequested` event), `hold` is explicitly set to `false` to allow proper shutdown, ensuring manual control supersedes configuration-based persistence.
6. **Documentation and Changelog Updates**: The CHANGELOG entry for version `0.25.0-dev` documents the replacement of `hold` with `drain_on_exit`, providing visibility into this breaking change and its rationale (terminal holding should now be handled externally).

View file

@ -0,0 +1 @@
I'd like to rename and refactor the `hold` behavior in the Alacritty terminal codebase to better reflect its actual use and separate terminal process handling from window behavior. Please rename the `hold` field in all relevant config structs (`Options`, `TerminalOptions`, `PtyOptions`) to `drain_on_exit` to make it clear that the terminal should drain its output before exiting, not necessarily hold the window open. Update all associated logic and struct initializations accordingly. Additionally, add a new `hold` field specifically to the `Window` struct to control whether the terminal window should remain open after the terminal process exits. Ensure that when a user explicitly closes the window (e.g., via `WindowEvent::CloseRequested`), this `hold` flag is set to false to allow normal shutdown. Update any logic that previously depended on `hold` to use the appropriate new field, and include a changelog entry explaining this semantic split and why the change was made.

View file

@ -0,0 +1,3 @@
url = "https://github.com/lancedb/lancedb.git"
revision = "698f329598bcfa8a5bf0feedfdd4344a4cdc7e4d"
language_extension = "rs"

View file

@ -0,0 +1,6 @@
1. The `restore` method is updated across Python and Rust components of LanceDB to accept an optional `version` argument, enabling more flexible restoration of historical table versions.
2. Python async bindings in `_lancedb.pyi` and `table.py` are updated to reflect the new method signature `restore(version: Optional[int] = None)`, aligning type hints and implementations.
3. The remote table interface in `remote/table.py` includes a corresponding `restore` method, bridging the sync API to the async backend with version support.
4. The Rust FFI layer (`table.rs`) is modified to accept the optional `version` argument, with logic that performs a `checkout(version)` if specified, before proceeding to `restore()`, improving control over the restore flow.
5. The `RemoteTable` implementation in `remote/table.rs` now constructs and sends a versioned restore request via HTTP, enabling client-side version-specific restoration even in cloud deployments.
6. Docstrings and comments are added or expanded to explain the behavior of the `restore` function, particularly the no-op case when restoring the latest version, enhancing code maintainability and developer understanding.

View file

@ -0,0 +1 @@
I'd like to update the `restore` method in LanceDB to support restoring to a specific historical version of a table. Please modify all relevant files to add an optional `version` parameter to `restore`, defaulting to `None`. When `version` is provided, the implementation should perform a checkout to that version before executing the restore. If `version` is not specified, it should restore the currently checked-out version. Update the Python async bindings (`_lancedb.pyi`, `table.py`, and `remote/table.py`) to reflect the new method signature and behavior. In the Rust FFI layer (`python/src/table.rs`), modify the `restore` function to accept and correctly handle the optional version argument. For the cloud-backed `RemoteTable` in Rust (`rust/lancedb/src/remote/table.rs`), ensure that the version is included in the HTTP request body during a restore operation. Add or update docstrings and comments as needed to clarify how restore behaves with and without the `version` argument.

View file

@ -0,0 +1,3 @@
url = "https://github.com/tikv/tikv.git"
revision = "be74cadcdd6608e5788d0c2a6784c456b4ce84e6"
language_extension = "rs"

View file

@ -0,0 +1,5 @@
1. **Function Modification**: The `write_time_detail` function has been refactored into `merge_time_detail` to modify the behavior of merging time details instead of overwriting them. The `merge_time_detail` function now adds new values to the existing ones, preserving the data and allowing for cumulative updates, which ensures more accurate tracking of time metrics.
2. **Usage of New Function**: All instances where `write_time_detail` was called have been updated to use `merge_time_detail`, including in the `src/coprocessor/endpoint.rs`, `src/server/service/kv.rs`, `src/storage/txn/tracker.rs`, and test files. The modification ensures consistency across the codebase by merging time details rather than replacing them.
3. **Test Coverage**: A new test, `test_select_time_details`, has been added in `tests/integrations/coprocessor/test_select.rs` to validate the proper functioning of time detail merging. The test checks that the `process_wall_time_ns` field is not zero, ensuring the correct time metrics are being tracked and merged.
4. **Backward Compatibility**: The changes do not affect any external functionality or break compatibility. The merging of time details is backward-compatible, as it preserves existing values and adds new ones, which makes the system more flexible for future extensions.
5. **Code Consistency**: The naming convention and function signature have been aligned with existing code practices, making the codebase more consistent and easier to maintain.

View file

@ -0,0 +1 @@
I want to refactor the existing time detail handling in the codebase. Specifically, I'd like to replace the `write_time_detail` function with a new `merge_time_detail` function, which will add new time details to the existing ones rather than overwriting them. This change should be applied across the codebase wherever `write_time_detail` is used, including in `src/coprocessor/endpoint.rs`, `src/server/service/kv.rs`, `src/storage/txn/tracker.rs`, and any related test cases. Please ensure that all occurrences of the old function are updated to use the new one. Additionally, add a test to validate that the `process_wall_time_ns` is correctly merged and is not zero, which will ensure the merging is functioning as intended. Make sure these changes preserve backward compatibility and do not introduce any regressions in functionality.

View file

@ -0,0 +1,3 @@
url = "https://github.com/firecracker-microvm/firecracker.git"
revision = "5eaa6e08e350cd38c8102848913a096312e59097"
language_extension = "rs"

View file

@ -0,0 +1,5 @@
1. The changes remove unnecessary generic type parameters from the `FileEngine`, `AsyncFileEngine`, and related structures by directly using the `PendingRequest` type, simplifying type signatures and improving code clarity.
2. Error handling is unified through the replacement of `UserDataError` with `RequestError` that specifically carries `PendingRequest` information, ensuring consistent error propagation with request context.
3. The `WrappedUserData` struct is renamed to `WrappedRequest` and directly embeds `PendingRequest`, aligning terminology with the virtio block devices request lifecycle and improving traceability.
4. Test code is updated to use `PendingRequest::default()` instead of placeholder `()` types, ensuring type consistency and proper request initialization in all scenarios.
5. Code organization is improved by consolidating imports (e.g., merging `IO_URING_NUM_ENTRIES` and `PendingRequest` imports) and removing redundant type parameters across async/sync I/O implementations.

View file

@ -0,0 +1 @@
Refactor the virtio block devices I/O handling to eliminate generic type parameters from file engine structures, replacing them with the concrete `PendingRequest` type. Update the `AsyncFileEngine` and `FileEngine` implementations to directly handle `PendingRequest` in all operations, ensuring error types like `RequestError` propagate this request context. Rename `UserDataError`/`UserDataOk` to `RequestError`/`RequestOk` and adjust their internals to store `PendingRequest` instead of a generic `user_data`. Simplify imports (e.g., consolidate `io_uring` imports) and modify test code to initialize `PendingRequest` properly with default values where needed. Maintain all existing async/sync I/O functionality, including dirty memory tracking and request completion logic.

View file

@ -4,7 +4,10 @@ set -euo pipefail
# Brackets are used around characters so these don't show up in normal search.
pattern='tod[o]!|FIXM[E]'
result=$(git grep --no-color --ignore-case --line-number --extended-regexp -e $pattern -- ':(exclude).github/workflows/ci.yml' || true)
result=$(git grep --no-color --ignore-case --line-number --extended-regexp -e $pattern -- \
':(exclude).github/workflows/ci.yml' \
':(exclude)*criteria.md' \
':(exclude)*prompt.md' || true)
echo "${result}"
if [[ -n "${result}" ]]; then
exit 1