rtk-ai/rtk · critical

invalid ctest result prefix regex

Error message

invalid ctest result prefix regex

What it means

This is a panic from `.expect("invalid ctest result prefix regex")` on a `Regex::new` call inside a `LazyLock<Regex>` static in src/cmds/system/ctest_cmd.rs:32. The `regex` crate returns an Err when a pattern fails to parse, and rtk's convention is to crash at first use rather than run with broken filtering. It means the RESULT_PREFIX_RE pattern string is syntactically invalid regex.

Source

Thrown at src/cmds/system/ctest_cmd.rs:32

const MAX_SLOWEST: usize = 3;
const MAX_FAILURE_LINES: usize = CAP_WARNINGS;
const MAX_FAILURE_HEAD_LINES: usize = 2;
const MAX_FAILED_LIST_LINES: usize = CAP_LIST;
const MAX_DETECT_PREAMBLE_LINES: usize = 4;
// Failure entries carry a header plus up to `MAX_FAILURE_LINES` detail lines each,
// so this list deviates below `CAP_LIST`; the single-line skipped and raw-trailer
// lists keep the full cap.
const MAX_FAILED_BLOCK_ENTRIES: usize = truncate::reduced(CAP_LIST, 5);

static TEST_RE: LazyLock<Regex> = LazyLock::new(|| {
    Regex::new(
        r"(?s)^\s*(?:\d+/(\d+)\s+)?Test\s+#(\d+):\s+(.+?)\s+\.{2,}\s*(?:\*{3})?\s*(.+?)\s+([\d.]+)\s+sec\s*$",
    )
    .expect("invalid ctest result regex")
});
static RESULT_PREFIX_RE: LazyLock<Regex> = LazyLock::new(|| {
    Regex::new(r"^\s*(?:\d+/\d+\s+)?Test\s+#\d+:")
        .expect("invalid ctest result prefix regex")
});
static RESULT_TERMINATOR_RE: LazyLock<Regex> = LazyLock::new(|| {
    Regex::new(r"[\d.]+\s+sec\s*$").expect("invalid ctest result terminator regex")
});
static START_RE: LazyLock<Regex> = LazyLock::new(|| {
    Regex::new(r"^\s*Start\s+(\d+):\s*(.*?)\s*$").expect("invalid ctest start regex")
});
static SUMMARY_RE: LazyLock<Regex> = LazyLock::new(|| {
    Regex::new(r"^\s*\d+%\s+tests passed,\s+(\d+)\s+tests failed out of\s+(\d+)")
        .expect("invalid ctest summary regex")
});
static TIME_RE: LazyLock<Regex> = LazyLock::new(|| {
    Regex::new(r"^\s*Total Test time \(real\)\s+=\s+([\d.]+)\s+sec")
        .expect("invalid ctest time regex")
});

#[derive(Debug, Clone)]
struct TestCase {

View on GitHub (pinned to 36788f6bd4)

Solutions

  1. Inspect the RESULT_PREFIX_RE pattern literal at src/cmds/system/ctest_cmd.rs:32-34 and fix the regex syntax error reported by Regex::new
  2. Verify the pattern standalone (e.g. `cargo run` with a small Regex::new test, or regex101 with Rust flavor) before re-committing
  3. Restore the known-good pattern: r"^\s*(?:\d+/\d+\s+)?Test\s+#\d+:"
  4. Run `cargo test ctest` to confirm the filter initializes and matches real ctest output lines

Example fix

// before (missing closing paren on the non-capturing group)
Regex::new(r"^\s*(?:\d+/\d+\s+?Test\s+#\d+:")
    .expect("invalid ctest result prefix regex")
// after
Regex::new(r"^\s*(?:\d+/\d+\s+)?Test\s+#\d+:")
    .expect("invalid ctest result prefix regex")
Defensive patterns

Strategy: validation

Validate before calling

// Run in CI before depending on the filter; cheap Regex::new check
fn assert_ctest_regexes_valid() {
    assert!(regex::Regex::new(r"^\s*(?:\d+/\d+\s+)?Test\s+#\d+:").is_ok());
}

Prevention

When it happens

Trigger: The static RESULT_PREFIX_RE is lazily initialized the first time the ctest filter uses it; the panic fires only if the literal pattern `^\s*(?:\d+/\d+\s+)?Test\s+#\d+:` fails to compile — i.e. after a source edit that corrupts the pattern (unbalanced parentheses/groups, bad escape like `\q`, dangling `*`, truncated string literal).

Common situations: Hand-editing the regex while adding support for new ctest output shapes (e.g. changing `(?:\d+/\d+\s+)` and dropping the `?` or a paren), copy-paste mangling backslashes between raw and non-raw strings, or merging branches that both touched the static.

Related errors


AI-assisted analysis of rtk-ai/rtk@36788f6bd4 (2026-09-03). Data as JSON: /api/errors/808ced0343a5dfb5. Report an issue: GitHub.