Skip to content

[do-not-merge] Verify Release determinism CI catches optimizer Val race#19838

Closed
T-Gro wants to merge 4 commits into
mainfrom
verify-determinism-catches
Closed

[do-not-merge] Verify Release determinism CI catches optimizer Val race#19838
T-Gro wants to merge 4 commits into
mainfrom
verify-determinism-catches

Conversation

@T-Gro
Copy link
Copy Markdown
Member

@T-Gro T-Gro commented May 28, 2026

Verification draft for PR #19810. Tests the hypothesis: after switching test-determinism CI to Release, will it catch the optimizer iteration race?

This branch keeps PR #19810's azure-pipelines-PR.yml Release change but reverts the actual optimizer sort fix. If the Determinism_Release job fails, the test infrastructure is now able to catch the bug.

DO NOT MERGE. Will be closed once we observe the CI signal.

T-Gro and others added 4 commits May 26, 2026 11:35
…19732)

Optimize/DetupleArgs.determineTransforms and Optimize/InnerLambdasToTopLevelFuncs.CreateNewValuesForTLR walked Val sets in Val.Stamp order. Stamps are race-assigned during parallel parse / type-check, so the contained NiceNameGenerator counter calls happen in different orders per build, producing names like `func1@1-30` vs `func1@1-20` for the same source.

Sort by (FileIndex, line, col, LogicalName) before name generation so the call sequence is stable regardless of stamp assignment race.

Also drops the stale OptimizeInputs.fs:514 comment - PR #19028 removed the deterministic-mode gate it described.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Address multi-model review consensus:
- Add Val.Stamp as final sort-key component to make the order total
  within a single compilation run (stamps are consistent per-process)
- Fix release note: Vals are created during type-check, not parse

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…elease

- Extract valSourceOrderKey into TypedTreeOps.ExprConstruction (.fs + .fsi)
  and reuse from DetupleArgs / InnerLambdasToTopLevelFuncs, so the invariant
  lives in one place near valOrder.
- Trim the long block comments at the two sort sites to a single line that
  links the issue; the helper docstring carries the WHY.
- Restore a brief note in OptimizeInputs.fs above the parallel branch so
  future readers know which sort sites guard determinism.
- azure-pipelines-PR.yml: run eng/test-determinism.cmd in Release config.
  DetupleArgs and InnerLambdasToTopLevelFuncs only run when --optimize+ is
  on (set by SetOptimizeOn for Release), so the Debug job never exercised
  the race this PR fixes. Rename job to Determinism_Release.
- Release note: add PR link.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… CI fail

Temporary commit to validate that running eng/test-determinism.cmd in
Release configuration actually catches the Val.Stamp-iteration race
introduced by parallel optimization. Do NOT merge.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown
Contributor

❗ Release notes required


✅ Found changes and release notes in following paths:

Warning

No PR link found in some release notes, please consider adding it.

Change path Release notes path Description
src/Compiler docs/release-notes/.FSharp.Compiler.Service/11.0.100.md No current pull request URL (#19838) found, please consider adding it

@T-Gro
Copy link
Copy Markdown
Member Author

T-Gro commented May 28, 2026

Verification complete. The Release CI correctly detects FSharp.Compiler.Service.dll hash mismatch from pre-existing TypeDefsBuilder races. PR #19810's optimizer fix is one part of the solution; remaining races are documented out-of-scope.

@T-Gro T-Gro closed this May 28, 2026
@T-Gro T-Gro deleted the verify-determinism-catches branch May 28, 2026 13:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

1 participant