perf(engine): use MemoryExtensions.Split for path parsing in MetadataFilterMatcher

[thomhurst]

Summary

Replaces filterString.Split('/') in MetadataFilterMatcher.ExtractFilterHints with a span-based MemoryExtensions.Split into a stackalloc Span<Range> on net8+, as requested in the issue.

• Eliminates the string[] allocation and only materializes (via .ToString()) the literal segments that FilterHints actually retains (segments 1-4).
• Non-literal segments (wildcards/operators) and out-of-range segments still resolve to null, identical to the previous behavior.
• IsNonLiteralSegment gains a ReadOnlySpan<char> overload on net8+ to avoid round-tripping segments back to strings just to scan them.
• netstandard2.0 retains string.Split since MemoryExtensions.Split(Span<Range>, ...) is net8+ only — guarded with #if NET8_0_OR_GREATER.

Verified the 6-range buffer semantics against the docs: the remainder of the path lands in the final range, so segments 1-4 always hold clean individual values.

Build

dotnet build TUnit.Engine succeeds across netstandard2.0, net8.0, net9.0, net10.0 (0 warnings, 0 errors).

Closes #6037

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics -4 complexity

Metric	Results
Complexity	-4

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

Code Review

Overall: The implementation is correct, well-structured, and achieves its goal. All three review angles (line-by-line scan, removed-behavior audit, cross-file caller analysis) came up clean — the span-based path is behaviorally identical to the string.Split path it replaces on NET8+.

What works well

• Buffer size is correct: The 6-slot Span<Range> correctly handles all cases — paths with <5 segments (count < 6, ranges are only partially filled), exactly 5 segments (count = 5, all valid), and 6+ segments (count = 6, ranges[5] absorbs the overflow remainder). Segments 1–4 always receive clean, slash-free slices.
• Guard equivalence: The count < 2 guard in the span path is semantically identical to the old parts.Length < 2 guard. The index >= count check in ExtractSegment is equivalent to the old parts.Length > N guards.
• Empty-segment handling: value.IsEmpty on NET8+ is equivalent to the old string.IsNullOrEmpty for span slices (spans can never be null, and Length == 0 maps directly to IsEmpty).
• IsNonLiteralSegment split: The refactoring into two typed overloads (ReadOnlySpan<char> vs string) is clean and avoids any round-trip allocation.
• Lazy materialization: Only non-null, literal segments call .ToString(), which is the key allocation win.

One design note worth considering

The count returned by MemoryExtensions.Split is capped at the buffer length (6) when there are more actual segments. This means that when count == 6, ranges[5] contains a remainder slice that includes embedded / characters — and / is intentionally absent from _filterOperatorChars. Since ExtractSegment is only ever called with indices 1–4 today, this is not a bug. However, if the method is ever extended to extract a 5th hint (index 5, e.g., a sub-method segment), the index >= count guard would pass (5 < 6) and the overflow slice — potentially "extra/remainder" — would slip through IsNonLiteralSegment as a valid literal.

A simple safeguard would be documenting this constraint on ExtractSegment, or adding an assertion:

// Callers must pass index in [1,4]; ranges[5] is an overflow absorber that may contain '/'
private static string? ExtractSegment(ReadOnlySpan<char> filterSpan, ReadOnlySpan<Range> ranges, int count, int index)

Or alternatively, capping the accessible range at 4 explicitly:

if (index >= count || index >= ranges.Length - 1) // never access the overflow slot
    return null;

This is a minor defensive-programming note, not a blocking issue.

Verdict

The optimization is sound, the behavior is preserved across all targets (net8/net9/net10/netstandard2.0), and the dual #if/#else method-body split compiles correctly. Ready to merge.