v0.15.0 release gate: regex match operator returns false on Linux

[ehartford]

During the v0.15.0 Linux release gate on origin/main at 878ccb8c, with build and with build :fixpoint passed, but with build :test failed in regex behavior tests.

Host/worktree:

• Host: Linux x86_64 (lazarus@192.168.0.115)
• Worktree: /home/lazarus/with-release-v0.15.0
• Commit: 878ccb8c
• Version: v0.15.0
• SDK: .deps/llvm-22.1.6-linux-x86_64

Failing tests:

• test/behavior/behav_regex_language_semantics.w
• test/behavior/behav_regex_capture_fstring.w

Observed:

• Both fail at run stage with exit code 134.
• LLDB/direct run shows assertion failure, not segfault.
• behav_regex_language_semantics.w fails at line 20: assert(count == 2) after while text =~ /([a-z])(\d)/g, meaning the global match loop did not match twice.
• behav_regex_capture_fstring.w fails at line 10: assert(got == "ERROR code=42").

Minimal probe built with the release compiler:

fn main:
    let text = "a1 b2"
    if text =~ /a1/:
        with_write("basic yes\n")
    else:
        with_write("basic no\n")
    if text =~ /([a-z])(\d)/:
        with_write("cap yes " ++ $0 ++ " " ++ $1 ++ " " ++ $2 ++ "\n")
    else:
        with_write("cap no\n")

Output:

basic no
cap no

Classification:

• Release blocker because with build :test is a release gate in docs/with-release-runbook.md.
• Not a stack issue.
• Not the earlier value-locals failure; that moved forward after 5c7cc011.
• Not the mutual-tailrec compile segfault; that moved forward after 878ccb8c.

[ehartford]

Root cause confirmed: this was a runtime FFI string-representation bug, fixed by 2d8bfe01.

At the failing commit 878ccb8c, rt/regex_runtime.w passed the PCRE2 subject as text as *const u8. That cast is wrong for a With str: the value is an aggregate containing the data pointer and length, so the cast gives PCRE2 the address of the str value/stack slot, not the subject bytes. PCRE2 therefore matched against {data_ptr, len, ...} metadata bytes and returned no match, which explains the probe output:

basic no
cap no

2d8bfe01 added regex_str_data(s: str) -> *const u8 and uses it for the PCRE2 match/substitute subject pointer. Current source no longer has text as *const u8 in rt/regex_runtime.w.

Five whys:

1. =~ returned false because pcre2_match_8 returned no match.
2. PCRE2 returned no match because it did not receive the subject bytes.
3. It did not receive the subject bytes because rt/regex_runtime.w passed text as *const u8.
4. That cast was wrong because With str is a value aggregate; the byte pointer must be extracted from the aggregate.
5. Build/fixpoint did not catch it because those gates prove compiler self-consistency, not PCRE2 runtime behavior. The Linux :test gate was the first gate in this path that exercised the bridge.

This was observed on Linux, but the bug was not semantically Linux-only. Any platform using that same broken runtime bridge could pass the wrong subject pointer. Linux exposed it first because this release gate ran the behavior tests at the broken commit.

Closing as fixed by 2d8bfe01.