Fix Release mode determinism

[majocha]

Description

Fixes#19732

Checklist

• Test cases added

• Performance benchmarks added in case of performance changes

• Release notes entry updated:

  Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

  Release notes files:

  • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
  • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/release-notes/.Language/preview.md
  • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

  Information about the release notes entries format can be found in the documentation.
  Example:

  • More inlines for Result module. (PR #16106)
  • Correctly handle assembly imports with public key token of 0 length. (Issue #16359, PR #16363)
    *while! (Language suggestion #1038, PR #14238)

  If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

[github-actions]

✅ No release notes required

[majocha]

OK, release mode failure is confirmed in CI:

[majocha]

I don't really understand what's going on here. The issue indicated a problem with heaps being reordered internally, but the solution Copilot did does not touch them, instead it adds a additional tie-break sorting of table rows. (?) Yet the determinism now passes, locally and here in CI:

EDIT: nope, not fixed, just randomly passes. I desperately need a small solid repro to work with.

[T-Gro]

Maybe we would need some better tweaks to make it fail more consistently?
e.g. changing parallel/sequential or number of cores available in between runs?

[majocha]

Maybe we would need some better tweaks to make it fail more consistently? e.g. changing parallel/sequential or number of cores available in between runs?

This is a great idea! Comparing parallel/sequential would be great since that's what we're really aiming for.

[T-Gro]

Yeah I will do that. IMO it is more likely to fail compared to 2 parallel runs.