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

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-Groand 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 pathRelease notes pathDescription
src/Compilerdocs/release-notes/.FSharp.Compiler.Service/11.0.100.mdNo current pull request URL (#19838) found, please consider adding it

@T-Gro

Copy link
Copy Markdown
MemberAuthor

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-GroT-Gro closed this May 28, 2026
@T-Gro
T-Gro deleted the verify-determinism-catches branch May 28, 2026 13:40
Sign up for freeto 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

@T-Gro