feat: introduce @list.sort_v2 to improve sort stack safety

[Erchiusx]

Previous @list.sort would yield a stack overflow at a data scale of 100_00
introduced @list.sort_v2 which uses @array.FixedArray::sort to help sorting the list

[peter-jerry-ye-code-review]

Stack overflow fix by avoiding recursive implementation

Category
Performance
Code Snippet
Previous:

smaller.sort().concat(More(x, tail=greater.sort()))

New:

let arr = self.to_array()
arr.sort()
from_array(arr)

Recommendation
The new implementation is correct. Consider adding a comment explaining why array-based sorting is preferred over recursive list sorting.
Reasoning
The original recursive implementation would create O(n) stack frames for large lists, causing stack overflow. The array-based approach is both more space-efficient and faster.

Test case could be more comprehensive

Category
Maintainability
Code Snippet

test "sort-stack-safety" {
  let arr = FixedArray::makei(100_000, fn { x => x })
  arr.rev_inplace()
  let ls = @list.of(arr)
  ls.sort() |> ignore
}

Recommendation
Add assertions to verify the sorting result is correct, not just that it completes without stack overflow
Reasoning
Current test only verifies the function doesn't crash but doesn't validate correctness. Adding result verification would make the test more robust.

Documentation needs updating

Category
Maintainability
Code Snippet

/// assert_eq(ls, @list.from_array([-76, -6, 0, 1, 3, 6, 52, 123]))

Recommendation
Add a note about the performance characteristics of the new implementation in the function documentation
Reasoning
Documentation should reflect significant implementation details that affect performance characteristics, especially when they differ from typical list operations

[coveralls]

Pull Request Test Coverage Report for Build 6927

Details

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.002%) to 92.452%

---

Totals
Change from base Build 6925:	-0.002%
Covered Lines:	8684
Relevant Lines:	9393

---

💛 - Coveralls

[peter-jerry-ye]

I think you can either:

• replace the existing implementation altogether
• try to find a boundary where the original is more efficient (which might not even exist) and keep both

[Erchiusx]

I think you can either:

* replace the existing implementation altogether

* try to find a boundary where the original is more efficient (which might not even exist) and keep both

The original implementation has a 3-constant factor, I think replacing it would count

[Lampese]

LGTM

[FlyCloudC]

The test seems a bit oversized, which may slow down the standard library's test suite. If it's for correctness, 100,000 might be overkill, and if it's only for speed measurements, maybe we can delete it after?

[bobzhang]

The test seems a bit oversized, which may slow down the standard library's test suite. If it's for correctness, 100,000 might be overkill, and if it's only for speed measurements, maybe we can delete it after?

sorting 100_000 elements should be fine, we may add some attributes to allow test filtering mechanism in the future

@Erchiusx can you do a rebase to keep the history clean

[Erchiusx]

100_000 is not a must, 100_00 is enough to show the difference

perhaps I should change it to 100_00?

[Erchiusx]

The rebase is done, but seems still squashable

[Lampese]

Later on, I will establish a core-extra-test repo with interns from @plct-lab to conduct some stress tests on the core. The testing in the core can be relatively reduced. cc @CAIMEOX