Stable sort for Array#sort.

Now that V8 has patched their Array#sort to be stable (see here) it appears that Chakra may be one of the last (or the last) of the browser JS engines (JS Core, SpiderMonkey, V8, etc.) to perform a non-stable sort (see demo).

https://github.com/Microsoft/ChakraCore/blob/0f40413d2e29863edf5f82de14fac41843deb79f/lib/Runtime/Library/JavascriptArray.cpp#L6640-L6675

While not a spec violation, if all engines perform a stable sort we can work towards standardizing it in the TC39.

[Penguinwizzard]

@dilijev idk, if we don’t have a situation in which we really want to use the native fallback behavior, it’s probably cleaner to just remove it now, imo - it’ll be in our git history if we need it, and historically off-by-default features tend to rot quickly in our codebase for various reasons. Getting a mergesort implementation in and unifying our supported platforms’ behavior would be good. In any case, if the spec were to eventually become even stricter in terms of what behavior is required of the standard array sort, then I imagine that it’d likely standardize on a merge sort - it’s significantly easier to reason about and work with consistently between engines. @rhuanjl, if you’d like to make a PR for a merge sort, I’m sure we’d be interested in looking at it.

[sigatrev]

If the user provides a simple callback for the comparison function, that should get inlined into the sort impl regardless due to normal inlining heuristics.

This is not necessarily the case. Callback inlining would require we inline sort into the function that called it. In test cases calling sort with a single sort functions you should see regular inlining kick in, but in the general case, if sort is called with numerous different sort functions you wouldn’t get inlining unless sort is fully inlined into it’s caller.

@rhuanjl When you open a PR I’ll be happy to look at the perf and see what’s going wrong.