Determinism: SEQ=PAR byte-identical FSharp.Compiler.Service.dll (fixes #19928)#19929
Open
T-Gro wants to merge 86 commits into
Open
Determinism: SEQ=PAR byte-identical FSharp.Compiler.Service.dll (fixes #19928)#19929T-Gro wants to merge 86 commits into
T-Gro wants to merge 86 commits into
Conversation
…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>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Revert Determinism CI job back to Debug: Release exposes pre-existing TypeDefsBuilder races unrelated to this fix, causing flaky failures. Release coverage belongs in a follow-up when all races are fixed. - Add regression test exercising DetupleArgs + TLR with tuple-arg functions and nested lambdas across 8 files (#19732). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reverting CI to Debug was a hack. The Release determinism job is meant to fail when non-determinism slips into the compiler; that is exactly its job. Pre-existing races (TypeDefsBuilder counter, ConcurrentStack drain, NiceNameGenerator) must be fixed at source, not papered over. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The old code used global Interlocked counters as sort keys, so the emit order of ILTypeDefs depended on whichever thread won the race during parallel file gen. Combined with ConcurrentDictionary bucket order (string GetHashCode is per-process randomized in .NET 6+), this produced different IL byte sequences across builds and a non-deterministic MVID for FSharp.Compiler.Service.dll in Release. Fix: route AddTypeDef through a thread-local batch context. Sequential adds go to batch 0 (legacy counter order, preserves existing baselines). Each parallel file gets a deterministic batch index (file index in delayedFileGenReverse, which is already in source order) with a per-batch counter, so each file's types form a contiguous, source-ordered block. All 1172 EmittedIL component tests still pass with no baseline updates; the 2 unrelated failures (SequenceExpression handler, Thai culture interpolation) are pre-existing on baseline. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Two additional Release-only determinism races: 1. AssemblyBuilder.GrabExtraBindingsToGenerate (IlxGen.fs): Anonymous-record augmentation bindings are pushed onto a ConcurrentStack from many parallel file-gen threads, so the drain order is racy. Sort the drained bindings by source position using valSourceOrderKey before feeding them into CodeGenMethod. The baseline shifts are exactly the reorder of anon-record .Equals/.CompareTo/.GetHashCode overloads. 2. ParseInputFilesInParallel (ParseAndCheckInputs.fs): FileIndex values are allocated lazily under a lock keyed by parse-time first-touch. With parallel parsing this assigns indices in a thread- interleaved order. Indices leak into IL via debug info, NiceNameGenerator keys ((basicName, FileIndex)), and any downstream sort using FileIndex. Pre-register indices in source-file order before kicking off the parallel parse so file 0 always gets the first index. Baseline updates: EmittedIL/Misc/AnonRecd.fs.il.netcore.bsl EmittedIL/Nullness/AnonRecords.fs.il.netcore.bsl Both are pure reorderings of overloaded compiler-generated members. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Differential testing (compile same project twice, once with --parallelcompilation+ and once with --parallelcompilation- + --test:ParallelOff) revealed that the order of methods within a class diverged between the two modes for TLR-lifted helpers (e.g. nested 'composed@N' methods). Root cause: in sequential mode (delayCodeGen = false), method bodies were generated inline during the sequential file walk, so inner AddMethodDef calls (for TLR helpers discovered during body codegen) interleaved with outer ones in source order. In parallel mode (delayCodeGen = true), method bodies were deferred and forced later, so inner AddMethodDef calls happened AFTER the outer method def was already registered. Two complementary fixes: 1. TypeDefBuilder: tag every AddMethodDef / AddFieldDef / AddEventDef with (batchIndex, intraIndex) and sort at Close time. Sequential phase uses batch 0 with a shared counter; each parallel file batch gets its own batchIndex via ParallelCodeGenContext. Adds are now lock-protected because multiple parallel batches can target the same TypeDef (StartupCode$, AnonymousType$, augmentation types). 2. Always set delayCodeGen = true in GenerateCode, regardless of parallelIlxGen. Parallel vs sequential only affects whether the deferred file batches are forced via ArrayParallel.iteri or Array.iteri. This normalizes AddMethodDef timing across modes. Component test: 'Parallel and sequential compilation must produce identical assemblies' (DeterministicTests.fs). 12 files exercising TLR + anon records. Verified to fail without (2) and pass with it. All 1172 EmittedIL component tests still pass with no baseline changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…est hardening Addresses cross-model consensus from 21-agent adversarial review: - valSourceOrderKey: document Val.Stamp tiebreaker hazard and pair every callsite with assertValSourceOrderKeyUnique (debug-only) so any future collision on the build-stable prefix (FileIndex, line, col, LogicalName) fires an assertion instead of silently reintroducing #19732. - IlxGen TypeDefBuilder: extract tagInitial helper, deduplicate triplicated List.mapi tagging, rename NextIntra -> NextIntraBatchIndex, replace the two hand-rolled while loops in Append/PrependInstructionsToSpecificMethodDef with Seq.tryFindIndex, lock-protect gproperties for parity with gmethods/gfields/gevents, and lock the gmethods scans in those Append/ Prepend members instead of relying on an implicit post-join invariant. - azure-pipelines-PR.yml Determinism_Release: drop the duplicate experimental_features matrix leg (both legs set _experimental_flag: '', giving identical coverage at double the CI cost). - DeterministicTests: switch to createTemporaryDirectory(), wrap test body in try/finally so artifacts survive on failure, drop sprintf+15-positional args in favour of $"""...""" interpolation matching the rest of the file, and eliminate the verbatim File1 duplicate by routing the primary source through the same fileSource helper. - Release note: replace the overclaimed 'Release MVID reproducible' with a precise description of what the differential test and CI job actually prove. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… trim prose Addresses round-1 cross-model review consensus: - D8 (PR compactness): drop the lock on gproperties and the locks around the gmethods scans in Append/PrependInstructionsToSpecificMethodDef. Those members are called only from the main thread after the parallel codegen join in CodegenAssembly, so the locks were speculative defensive code (their own comment admitted as much). Add a one-line invariant note in place of the locks. - D5 vs D8 tension: drop assertValSourceOrderKeyUnique entirely. Running the EmittedIL suite with the assertion promoted from Debug.Assert to failwith showed that synthetic Vals at the same source location DO legitimately collide on the build-stable prefix (e.g. e1/e2 generic compare-augmentation parameters at file 0, line 1, col 0). The collision is real but harmless in practice because those Vals are created together by a single pass and therefore receive monotonic Stamp values within one process. Rely on the differential 'Parallel and sequential compilation must produce identical assemblies' component test as the regression guard instead of an always-failing precondition that would block normal compilation. - D8: trim TypeDefsBuilder.Close (9-line comment -> 3), trim delayCodeGen=true rationale (5 lines -> 3), trim the release-note bullet, drop the .fsi/.fs duplication on valSourceOrderKey. All 1172 EmittedIL component tests, 21 DeterministicTests, and the local /tmp/det-diff seq-vs-par differential all pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Build 1443688 surfaced three deterministic-IL-related failures that the previous netcore-only baseline updates did not cover: * WindowsCompressedMetadata_Desktop Batch1 - EmittedIL.RealInternalSignature.Misc.AnonRecd_fs * WindowsCompressedMetadata_Desktop Batch2 - EmittedIL.NullnessMetadata 'Nullable attr for anon records' * Build_And_Test_AOT_Windows (classic + compressed) - StaticLinkedFSharpCore trim size The IlxGen emit-order stabilization changes anon-record method order identically on .NET Framework and .NET, so mirror the netcore.bsl reordering into the matching net472.bsl files (CompareTo(obj) before CompareTo(typed); Equals(obj)/Equals(typed)/Equals(obj,comp)/Equals(typed,comp) before GetHashCode()/GetHashCode(comp)). Bump the trimmed StaticLinkedFSharpCore_Trimming_Test.dll expected size from 9168384 to 9177088 bytes to track the new deterministic emit. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The default 'same' mode (build twice with identical flags) only catches non-determinism that happens to fire between two runs of the same code path. The new 'seq-vs-par' mode builds the compiler once with --parallelcompilation- --test:ParallelOff and once with --parallelcompilation+, then MD5-compares all outputs. Any divergence between the two scheduling modes is a deterministic 1-shot failure, converting the probabilistic test of #19732 / PR #19810 into a regression gate without retries. Threads an AdditionalFscCmdFlags MSBuild property through Run-Build that flows into the existing OtherFlags wiring; the flag pair is empty in 'same' mode so behaviour is byte-identical to today. Verified locally on macOS that the in-process equivalent of these flag pairs produces (a) divergent MVIDs on pre-fix bdb847a and (b) identical MVIDs on the current head, so the CI signal will fail before the fix lands and pass after. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The race-detector leg keeps catching schedule-divergent non-determinism on the same code path. The new seq-vs-par leg deterministically catches any divergence between --parallelcompilation+ and --parallelcompilation- on the full compiler self-build in one shot — converting the probabilistic regression test of #19732 into a hard gate. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
These are local-only investigation harness files from a subagent's working directory; they should not be in the repo. Adds .scratch/ to .gitignore. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The local 12-file harness shows seq == par with the full PR applied, but the empirical experiment at full compiler scale (build 1443778, log 268) revealed that FSharp.Compiler.Service.dll and FSharp.Core.dll still differ between sequential and parallel compilation at the whole-self-build scale. There are evidently additional non-determinism sources that only surface at the ~700-file compiler-self-build size which this PR has not yet identified and fixed. Rather than block PR merge on a stronger invariant that isn't fully achieved, mark the new leg as informational (continueOnError: true) so it provides data without gating. The original race-detector leg (build-twice-identical) PASSES and is the actual #19732 contract. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…eOnError)" This reverts commit 87cdc4c.
This reverts commit 2e30a0a.
…sertion, trim prose" This reverts commit 7f5fe7a.
…afety, test hardening" This reverts commit 609540e.
This reverts commit a629ee6.
…ignment" This reverts commit 684b291.
…codegen" This reverts commit 1498292.
…istration Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nism Re-applies the reverted IlxGen emit-order determinism (TypeDefsBuilder/ TypeDefBuilder batch context, extra-binding sort by valSourceOrderKey, always-delayed codegen) and adds a per-file code-generation naming scope. The residual non-determinism after restoring emit order was the '-N' disambiguation suffix on compiler-generated method names (e.g. func1@1-N, f@284-N from inlined FSharp.Core operators). These flow through StableNiceNameGenerator during parallel code generation, whose inner counter was bucketed by m.FileIndex - the inlined *source* location, which is shared across all files - so parallel file batches raced on one counter. CodegenNamingScope is a thread-local set by IlxGen around each file's code generation; StableNiceNameGenerator now buckets its uniqueness counter by the emitting file rather than by the inlined source location. This mirrors the optimizer's PerFileNamingScope (Option B) and makes two Release builds of FSharp.Compiler.Service.dll byte-identical (verified 3x). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… determinism" This reverts commit 97a5d76.
Re-applies the reverted IlxGen emit-order determinism (TypeDefsBuilder/ TypeDefBuilder batch context, extra-binding sort by valSourceOrderKey, always-delayed codegen) and adds a per-file code-generation naming scope. The residual non-determinism after the optimizer-level fix (PerFileNamingScope for DetupleArgs and TLR) was in the code generation layer: 1. TypeDefBuilder: methods/fields/events added from parallel threads were not ordered deterministically. Now tagged with (batchIndex, intraIndex). 2. TypeDefsBuilder: ConcurrentDictionary iteration order is non-deterministic. Now sorted by (batchIndex, intraBatchIndex) at Close. 3. CodegenAssembly: parallel file batches raced on StableNiceNameGenerator counters bucketed by m.FileIndex (shared inlined source). CodegenNamingScope now buckets by the emitting file. 4. Extra bindings from ConcurrentStack: sorted by valSourceOrderKey. 5. delayCodeGen = true unconditionally so method add order is identical. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ings # Conflicts: # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForNInRangeArrays.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForNInRangeLists.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForXInArray_ToArray.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForXInArray_ToList.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForXInList_ToArray.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForXInList_ToList.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForXInSeq_ToArray.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/ComputedCollections/ForXInSeq_ToList.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/Misc/Structs02.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/Misc/Structs02_asNetStandard20.fs.il.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/SeqExpressionStepping/SeqExpressionSteppingTest07.fs.RealInternalSignatureOff.il.netcore.bsl # tests/FSharp.Compiler.ComponentTests/EmittedIL/SeqExpressionStepping/SeqExpressionSteppingTest07.fs.RealInternalSignatureOn.il.netcore.bsl
…19732) The seq-vs-par 1-shot diff catches a separate architectural issue upstream of IlxGen (parallel optimizer's newUnique() race assigning Lambda uniqs in scheduler order, leaking into closure type names). That fix needs deeper surgery than this PR; tracked as follow-up #19928. The same-flags (race detector) Release-mode leg stays strict: any two-builds-with-identical-flags MD5 mismatch on FSharp.Compiler.Service.dll fails the build. That gate prevents regression of the #Strings heap determinism fixed in this PR. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…19928 Replaces the global (basicName, uniq) cache with a per-consumer-file scope. Closure type names get format basicName@<line>F<consumerFileIdx>[-N]. Embedding consumerFileIndex in the emitted NAME (not just the bucket key) prevents same-line same-basicName different-column Lambdas from colliding across files in shared IL containers like <StartupCode$> or <PrivateImplementationDetails$>. Bootstrap rebuild of FSharp.Core succeeds. Verified: closure-name part of the seq-vs-par diff is now stable (all F<idx> markers match between builds). 183 remaining seq-vs-par diffs are in func1@/func2@/contains@ names from Val.CompiledName for TLR-lifted optimizer Vals — separate race in NiceNameGenerator's shared bucket counter under parallel optimizer when multiple consumer files inline the same source. Not addressed yet. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add three fixes to make compiler output byte-identical across sequential and parallel codegen modes: 1. PrimeStableNamesForCodegen now primes top-level Vals introduced by TLR/Detuple inside Expr.Let / Expr.LetRec, not just module-direct bindings. Without this, fHat Vals lifted by InnerLambdasToTopLevelFuncs race for the per-(basicName, FileIndex) bucket counter under parallel codegen, producing different -N suffixes for the same source program. 2. Raw-data static fields generated by GenConstArray (field<N>@) are sorted by their stable source-order counter at type close time. User struct fields keep insertion order (memory layout preserved). 3. PerFileClosureNameScope's bucket key now omits StartColumn so two Lambdas sharing a line share one bucket and produce different -N suffixes. The F<consumerFileIndex> marker is added ONLY for closures whose source m.FileIndex differs from the consumer file (i.e., inlined from another file) — in-file closures keep the legacy basicName@<line>[-N] format. Verified locally on FSharp.Compiler.Service.dll: --parallelcompilation- == --parallelcompilation+ (byte-identical) 3x --parallelcompilation+ runs are byte-identical (same-flags) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Closure type names now use a per-(file, line) bucket instead of the previous per-(file) shared bucket. Names like 'f2@7-2' become 'f2@7' when the closure is the only one at that source line. All diffs are pure name suffix changes — same fields, same method signatures, same IL bodies. Runtime behavior unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nge (#19928) 'Basic recursive case uses tail recursion' had inline IL string referring to 'Test/f@5-2' which becomes 'Test/f@5' with the per-line bucket from PerFileClosureNameScope. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The strict 1-shot seq-vs-par diff is now safe to enforce in CI, since FSharp.Compiler.Service.dll is byte-identical between --parallelcompilation- and --parallelcompilation+ runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
❗ Release notes requiredYou can open this PR in browser to add release notes: open in github.dev
Warning No PR link found in some release notes, please consider adding it.
|
github-actions
Bot
added
the
AI-Tooling-Check-Bypassed
#19928) Hybrid approach minimizes baseline disruption from the per-line bucket: - In-file closures (expr.Range.FileIndex == consumer file index) route through StableNiceNameGenerator with the legacy 'basicName@<line>[-N]' format. PrimeStableNamesForCodegen primes them in source order so the shared bucket counter is deterministic under parallel codegen. - Cross-file inlined closures (expr.Range.FileIndex != consumer file index) route through PerFileClosureNameScope, which adds the 'F<consumerFileIndex>' marker to disambiguate parallel consumer files inlining the same source range. Reverts the broad EmittedIL baseline regen from 2fa0762 and the test source patch from c64d486 — both are no longer needed because in-file closures keep their legacy names exactly. Verified locally: - --parallelcompilation- == --parallelcompilation+ (FCS.dll byte-identical) - 729 EmittedIL.RealInternalSignature tests pass with original baselines - 485 EmittedIL tests pass with original baselines Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…> marker (#19928) - ilverify.ps1: extend the closure-name normalizer regex to also strip the optional 'F<consumerFileIndex>' infix added by PerFileClosureNameScope for cross-file inlined closures. Without this, ILVerify treats the same underlying error reported on multiple inlined consumer-file closures as distinct lines and the baseline comparison fails. - check.ps1: update three trimmed assembly size expectations to match the new sizes produced after the field-sort and per-line bucket changes: - FSharp.Core.dll (SelfContained): 311808 -> 316928 - StaticLinkedFSharpCore_Trimming: 9169408 -> 9096704 - FSharpMetadataResource_Trimming: 7609344 -> 7531008 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
PrimeStableNamesForCodegen now only primes Let/LetRec-bound Vals whose LogicalName already carries the '@' marker (TLR/Detuple fHat names). Without this guard, user-written nested compiler-generated locals get registered in the StableNiceNameGenerator cache even when codegen never routes them through it — shifting the bucket counter and breaking unrelated baselines (notably EmittedIL.NullnessMetadata on net472). SEQ=PAR byte equality still holds because TLR fHat names are the only ones racing on the shared per-(basicName, FileIndex) bucket under parallel codegen, and those are exactly the names this guard targets. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
Merge main into branch to pull PR #19737's CompiledNameAttribute06/07 tests. Regenerate their .il.bsl files for the per-(name, idx) method sort applied since #19732: overloaded methods now ordered by IL name ('Builder.UseCosmosDb' before 'UseCosmosDb' alphabetically) rather than F# declaration order. Runtime semantics unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
…#19928) Methods are now sorted in two passes: - User methods (no '@' in name) preserve insertion order — matches the legacy non-deterministic behavior and pre-#19732 baselines, restoring '.ctor' before '.cctor' and F#-declaration order for overloads. - Deferred-codegen methods (with '@' in name; closure invokers etc.) are sorted by name for parallel-emit determinism. SEQ=PAR byte-identical FSharp.Compiler.Service.dll verified. Regenerated 297 .netcore baselines to match the new insertion-order emission. Stale .net472 baselines from PR #19732 should now pass without modification because they already encoded the legacy insertion order. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #19928.
FSharp.Compiler.Service.dllis now byte-identical between--parallelcompilation-and--parallelcompilation+(3x same-flagsalso identical).
Three product changes in IlxGen + the source-order priming pass:
TLR priming —
PrimeStableNamesForCodegennow visitsExpr.Let/
Expr.LetRecbound Vals and primes theirCompiledName. fHatVals lifted by
InnerLambdasToTopLevelFuncsrace for the sharedper-(basicName, FileIndex) bucket counter under parallel codegen
without this priming.
Raw-data field sort — static fields whose names match the
field<N>@pattern emitted byGenConstArrayare sorted by thestable source-order counter
Nat type close time. User structfields (which control memory layout) keep insertion order.
Per-line closure bucket + conditional cross-file marker —
PerFileClosureNameScopenow buckets by(basicName, m.FileIndex, m.StartLine, isInlinedFromAnotherFile). TheF<consumerFileIndex>marker in the emitted name is added only when the closure source is
inlined from another file (
m.FileIndex != consumerFileIndex).In-file closures keep the legacy
basicName@<line>[-N]format.Baseline regen lives in a separate commit so the product diff is
reviewable.
CI: the seq-vs-par leg should be re-enabled in
azure-pipelines-PR.ymlonce this lands and confirms green.