Fix SORT_REGULAR with new transitive comparison functions

[jmarble]

Summary

Fixes #20262 by implementing transitive comparison for SORT_REGULAR. This ensures deterministic sort results when arrays contain mixed types, which previously could produce non-deterministic output due to non-transitive comparisons.

Highlights

• Add transitive comparison functions (php_array_compare_transitive(), php_array_smart_strcmp_transitive(), etc.) with deterministic ordering:
  • Numeric types and numeric strings compare numerically
  • Non-numeric strings sort after numeric types and numeric strings
  • NaN sorts after all other numeric values (IEEE 754 totalOrder)
  • Arrays recurse through transitive comparison
  • Objects (same class) recurse through transitive property comparison
  • Enums sort by object handle (stable grouping for array_unique)
• Wire php_array_key_compare_unstable_i and php_array_data_compare_unstable_i to use the transitive comparator. All functions using SORT_REGULAR now use the transitive path.
• Add regression tests for array_unique() (scalars, objects, nested arrays), sort()/ksort() numeric-string edge cases, and enum ordering stability.

Performance Impact

Status: Unoptimized Implementation

This initial implementation prioritizes correctness and transitivity to fix the underlying stability issues. It is not yet optimized.

Overall, across 142 benchmarked operations, the changes result in an average ~1.5% performance improvement, with 92 operations faster and 50 slower. No regressions in standard comparison operations or sorts with other flags (e.g., SORT_NUMERIC).

However, there are known regressions in specific sort operations due to the overhead of the new dispatch logic:

• Standard Key Sorts (ksort/krsort) on non-mixed keys: ~3–11% slower.

Even in this unoptimized state, the new architecture yields significant wins in common scenarios:

• Integer Sorts: ~5–20% faster (higher gains in reverse sorts like rsort/arsort).
• Associative Arrays (Mixed Alphanumeric Keys): >30% faster (up to ~50% in key sorts).

Roadmap:
Once the transitive comparison logic is approved, I will submit a follow-up PR with finely tuned optimizations. These changes are expected to eliminate the current regressions and dramatically improve performance across all remaining operations.

[Girgias]

Various comments and questions and this needs a rebase as I refactored the sorting code to remove a bunch of duplication.

[jmarble]

@Girgias thank you for taking the time to provide the careful review! Looks like I was able to capture your sorting code refactor when I created this new branch. I'll push a fresh commit what I addressed in your code comments. Thanks again for the help!

[Girgias]

Please only do the fix for the transitivity.

Optimizations can be decided later, but currently it just pollutes the PR and makes it harder to review and merge.

[jmarble]

@Girgias yes, I clearly got a bit carried away haha. I decided to reimplement and force push a clean commit. Sorry for the mess I made of this PR.

I have a bag full of optimizations we can save for a follow-up PR. One worth calling out would be to split zendi_smart_strcmp() so the transitive comparator doesn’t need to re-run the non-transitive fast paths. I also found an opportunity to add a single-bucket fast path in zend_compare_symbol_tables() which showed close to 1.25x speedup on array comparison.

[Girgias]

What I think might make more sense is to create a zend_std_compare_objects_ex() function that takes a function pointer for the prop table comparison if this is identical.

As hopefully the compiler will inline the behaviour properly in zend_std_compare_objects() so that it should be equivalent. As for quite a bit I was trying to understand what the point of this is.

[jmarble]

I just gave it a try, and benchmarked it. I saw a small, almost negligable, regression. I see Time-Weighted ΔMedian% increased ~0.9% (from -1.20% to -0.31%).

[jmarble]

I tried a different idea. I created a zend_object_compare_kind enum in zend_object_handlers.h and added zend_std_compare_objects_ex(), so the standard object comparator can flip between zend_compare() and a transitive variant (zend_compare_transitive() without going through a function-pointer callback.

To make that transitive mode reusable everywhere, I moved the SORT_REGULAR compare logic into Zend itself (zend_compare_transitive(), plus zend_compare_symbol_tables_transitive() and the enum-aware helpers).

This design showed a negligible difference (within measurement noise) in my benchmarks compared to the current implementation.

I'm happy to push another commit with this change if you'd like to see.

[Girgias]

I would prefer that you use the function pointer approach. Because duplicating a lot of code when only the continuation changes is not something I'm a fan of.