Restore Stringy fast paths and remove mutation-only regressions

[Copilot]

• Inspect the latest failing CI run and capture the escaped Infection mutants
• Review the affected Stringy methods and current mutation guard tests
• Install local dependencies and reproduce the current validation state
• Add focused mutation guards for encode(), indexOfLast*(), split(..., null), and titleize()
• Run targeted PHPUnit, PHPStan, and Infection locally
• Re-check CI results and summarize remaining issues

---

This change is 

[coveralls]

coverage: 97.959% (+0.07%) from 97.891% — copilot/increase-mincoveredmsi-100 into master

[voku]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors several methods in the Stringy class to achieve a 100% mutation score (MSI), primarily by removing redundant checks and simplifying logic. Key changes include refactoring format, encode, and at, as well as adding extensive mutation guard tests. Feedback indicates a significant logic flaw in the format method's offset calculation, which introduces an ordering dependency and potential type coercion bugs. Additionally, the removal of the exact match fast path in the is method is identified as a performance regression that should be reconsidered.

I am having trouble creating individual review comments. Click here to see my feedback.

src/Stringy.php (1406-1410)

The logic for calculating the $offset when replacing named parameters is fragile and introduces potential bugs:

1. Ordering Dependency: Since $offset is shared across all keys in the $arg array and only increases, placeholders must be provided in the array in the exact order they appear in the string. If they are out of order (e.g., ['b' => 2, 'a' => 1] for string %:a %:b), the search for subsequent keys will start after the position of the previous match, failing to find placeholders that appear earlier in the string.
2. Type Coercion Issue: If strpos returns false (line 1411) for a key, the $offset variable is set to false. In the next iteration of the loop (for the next key), line 1409 performs false + $replacementLength. While PHP coerces this to an integer, it is logically incorrect as it continues the search from an arbitrary position instead of resetting or maintaining the last valid cursor.

Consider using a single-pass replacement strategy like preg_replace_callback which avoids these ordering and recursion issues entirely.

src/Stringy.php (1962-1964)

Removing the exact match fast path is a performance regression. Although the subsequent regex logic covers this case, a direct string comparison is significantly more efficient. If this change was made solely to achieve 100% mutation score (MSI) by removing 'redundant' branches, it is often better to keep the optimization and use mutation testing annotations to preserve performance without sacrificing the quality score.

[voku]

@copilot feedback from another llm, so maybe totally shit or not, you need to check it yourself : src/Stringy.php (1406-1410)
high

The logic for calculating the $offset when replacing named parameters is fragile and introduces potential bugs:

Ordering Dependency: Since $offset is shared across all keys in the $arg array and only increases, placeholders must be provided in the array in the exact order they appear in the string. If they are out of order (e.g., ['b' => 2, 'a' => 1] for string %:a %:b), the search for subsequent keys will start after the position of the previous match, failing to find placeholders that appear earlier in the string.
Type Coercion Issue: If strpos returns false (line 1411) for a key, the $offset variable is set to false. In the next iteration of the loop (for the next key), line 1409 performs false + $replacementLength. While PHP coerces this to an integer, it is logically incorrect as it continues the search from an arbitrary position instead of resetting or maintaining the last valid cursor.
Consider using a single-pass replacement strategy like preg_replace_callback which avoids these ordering and recursion issues entirely.

src/Stringy.php (1962-1964)
medium

Removing the exact match fast path is a performance regression. Although the subsequent regex logic covers this case, a direct string comparison is significantly more efficient. If this change was made solely to achieve 100% mutation score (MSI) by removing 'redundant' branches, it is often better to keep the optimization and use mutation testing annotations to preserve performance without sacrificing the quality score.

[Copilot]

@copilot feedback from another llm, so maybe totally shit or not, you need to check it yourself : src/Stringy.php (1406-1410)
high

...

I fixed the confirmed format() issue by making named placeholders resolve in string order instead of array-key order, while still avoiding recursive %: expansion, and I added regression coverage in both test suites. I also re-checked isSimilar() and this PR does not currently change that path, so I left it unchanged. Commit: cee8ce7.

[voku]

@copilot Double check of we need to restore things like if ($search === '' && $replacement === '') { return static::create($this->str, $this->encoding); } for old php versions like 7.3 or something like that, that we can't simply test in the CI because phpunit + composer etc. are not willing to support those old php versions anymore,but we do and I don't want to introduce breaking changes just to become 100% test coverage for nothing 😋

[Copilot]

@copilot Double check of we need to restore things like if ($search === '' && $replacement === '') { return static::create($this->str, $this->encoding); } for old ...

I double-checked the legacy-sensitive paths and restored the replace('', '') no-op guard, restored the exact-match fast path in is(), and scoped the replace('', 'x') mutation assertion to PHP 8+ because that behavior is version-sensitive. Local PHPUnit, PHPStan, and Infection all pass with commit e6c2254.