[xperiandri]

Fixes #11131
Fixes #15648
Fixes #11332

Stacked on #20894

A record or anonymous record with fields out of declaration order, a tupled lambda parameter, x.Created.HasValue on a class property and a let that names a member or is read once no longer reach LINQ providers as Expression.Block, which none of them translates.

Details

• Inside a lambda that goes to a provider, the value of a let takes the place of the variable where that computes the same: the value only reads (a constant, the lambda's parameter or a member of it, or what a member or method of a string, number or date makes of those), or the variable is read once, as the first thing the rest of the lambda evaluates.
• Every other let keeps its block and is evaluated once where it is written: a call read twice, by a nested lambda or after something else has run, an object that is created, a struct of your own or a boxed value, a mutable variable, and every let of a lambda that assigns or runs a statement.
• The lets the compiler adds for record fields written out of order are treated like any other: a field whose value only reads is evaluated where it is used, and one that does more keeps its block, so the fields are evaluated in the order they are written.
• A value that a call makes anew, such as p.Name.ToUpper(), keeps its block when it is used more than once and a use can tell one object from another, as obj.ReferenceEquals(upper, upper) does.
• A join whose key one side builds as a tuple and the other side has ready-made no longer fails with "Type mismatch when building 'ty'".
• EvaluateQuotation and QuotationToExpression outside such a lambda still produce a block.

🤖 Generated with Claude Code

[github-actions]

✅ Release notes checked

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`src/FSharp.Core`	docs/release-notes/.FSharp.Core/11.0.200.md

[xperiandri]

Covered cases

EF Core SQLite translates 122 of 145 scenarios, 92 without this change. Now translated: records and anonymous records with fields out of order in select, in join, groupJoin and leftOuterJoin keys and in groupBy keys, in a query and in Select; struct anonymous records, CLIMutable records, an anonymous record inside an anonymous record, method calls in out-of-order fields; Select on a nullable property; a let in where, select and exists; a string method or a count in a let used twice; nested lets; a Where over a query built earlier with a let.

Cosmos translates 26 scenarios, up from 17.

linq2db returned wrong rows for OrderBy and GroupBy with a tupled lambda parameter, and returns the right ones now.

Not changed: a call that is not a member of a string, number or date keeps its block when a let binds it and it is read twice, as in let orders = c.Orders.Count() in orders + orders.

[Copilot]

🟡 Changes recommended

Critical substitution issues can reorder explicit-let evaluation, mutate struct fields instead of local copies, and duplicate side effects through provider callbacks or custom nullable structs.

4 open issues

• Restrict the exception to compiler-generated hoists · New
• Treat nullable types as plain only when their contents are · New
• Require plain types for substituted arguments · New
• Preserve copies of non-plain value types · New

What changed in this PR

This PR improves FSharp.Core’s LINQ-provider compatibility by replacing eligible let bindings with their values instead of emitting Expression.Block. It builds on #20894’s struct-tuple support and query-shape tests to address record-field ordering, tupled parameters, and nullable-property access.

Changes:

• Substitute eligible bindings inside provider expression lambdas while retaining blocks for guarded cases.
• Add query-shape and evaluation-semantics regression coverage.
• Document expression-tree changes and their evaluation-order impact.

File	Description
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryStructureScenarios.fs	Covers loops, subqueries, and left joins.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryShapeTests.fs	Runs the query scenario suites.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryScenarioDomain.fs	Supplies shared query data and types.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryScenario.fs	Checks results, provider retention, and tree shape.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryProviderShape.fs	Captures queries and detects unsupported tree patterns.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryProjectionScenarios.fs	Covers tuple and record projections.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryOperatorScenarios.fs	Covers filtering, ordering, and aggregates.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryMethodSyntaxScenarios.fs	Covers direct LINQ method calls.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryKeyScenarios.fs	Covers composite join and grouping keys.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​ExpressionLambdaConversionTests.fs	Tests substitution, evaluation order, and identity.
tests/​FSharp.Core.UnitTests/​FSharp.Core.UnitTests.fsproj	Registers the new test files.
src/​FSharp.Core/​QueryExtensions.fs	Adapts struct tuples to query representations.
src/​FSharp.Core/​Query.fs	Integrates provider-specific conversion and record-field inlining.
src/​FSharp.Core/​Linq.fsi	Declares internal conversion helpers.
src/​FSharp.Core/​Linq.fs	Implements binding substitution and struct-tuple access.
docs/​release-notes/​PENDING_BREAKING_CHANGES.md	Documents tree-shape and evaluation-order changes.
docs/​release-notes/​.FSharp.Core/​11.0.200.md	Adds LINQ compatibility release notes.

_{Review effort: Balanced}

[pcshrosbree]

At the current head, the #11332 predicate gives the same result as plain F#, and its expression tree contains no blocks. Please expand PENDING_BREAKING_CHANGES and add tests for the remaining changes in when and how often expressions run. I ran the expression trees through AsQueryable() and compared the results with main and plain F#.

In the record-field cases I checked, user-written let bindings to Counter.Next() now keep their block unless the bound variable has the same name as the field that uses it. The example below shows that exception: the call bound to B still runs after the call for A.

let B = Counter.Next() in { A = Counter.Next(); B = B }
// This PR:  { A = 1; B = 2 }
// Plain F#: { A = 2; B = 1 }

The note could mention this remaining reordering.

PENDING_BREAKING_CHANGES:

• A member read substituted into a nested Func lambda can run once per inner element. With names a List<string>, custs.Select(fun c -> let n = c.Name in names.Count(fun s -> s = n)) reads Name 8 times for 2 customers and 4 names; main reads it twice. This also affects arithmetic expressions bound by let, such as let a = x.Age + 1, when a nested lambda uses the bound value. In that probe, Age was read 4 times, compared with once on main.
• The note says EvaluateQuotation and QuotationToExpression are unaffected. But QuotationToLambdaExpression changes for every caller, and EvaluateQuotation <@ ppl.Select(fun x -> let n = x.Name in n + n).ToArray() @> reads Name twice where main reads it once.
• A let binding that would throw can now be skipped when a conditional takes a branch that does not use the bound value. let s = x.Name.Substring(5) in if x.Name.Length > 5 then s else "" returns "" for "ab", where F# throws ArgumentOutOfRangeException.

Tests. Please add tests that count reads of a getter on the lambda's parameter, including a case where a nested lambda uses the getter's bound value. "Member of an object read before a call keeps the value it had" passes because items is a captured constant. If items is replaced with the lambda's parameter, the result is 1 on main and 2 on this PR.

The join-key fallback in Query.fs also fixes join p in ps on ((k.KA, k.KB) = p.Pair), which throws Type mismatch when building 'ty' on main; it could have a release-note line and a test.

[T-Gro]

🤖🕵️ AI review — verify independently.

[T-Gro]

🤖🕵️ [P2] Lost string identity after duplicating a call, even without getters or side effects.

open System
open Microsoft.FSharp.Linq.RuntimeHelpers
let f = LeafExpressionConverter.QuotationToLambdaExpression
            <@ Func<string, bool>(fun s ->
                let upper = s.ToUpperInvariant()
                obj.ReferenceEquals(upper, upper)) @>
f.Compile().Invoke "ab" // base: true; this head: false

[xperiandri]

Fixed in 4360ae3. A let whose value a call makes anew is no longer replaced at each of several uses when one of them can tell one object from another: the visitor ObjectIdentityUses looks at what the rest of the lambda does with the variable, so obj.ReferenceEquals(upper, upper) keeps its block and is true. Uses that only look at the string, like upper.StartsWith("A") && upper.EndsWith("B"), still take the value in. The tests are String made by a call is one string where a use can tell one from another and String made by a call is made at each use that only looks at it.

[T-Gro]

🤖🕵️ Still loses string identity at 9e58c229 through an identity-preserving call or a single captured use in a nested lambda.

open System
open System.Linq
open Microsoft.FSharp.Linq.RuntimeHelpers

let f = LeafExpressionConverter.QuotationToLambdaExpression
            <@ Func<string, bool>(fun s ->
                let upper = s.ToUpperInvariant()
                obj.ReferenceEquals(upper.Substring(0), upper.Substring(0))) @>
f.Compile().Invoke "ab" // base: true; 9e58c229: false

let g = LeafExpressionConverter.QuotationToLambdaExpression
            <@ Func<string, Collections.Generic.IEnumerable<string>>(fun s ->
                let upper = s.ToUpperInvariant()
                Enumerable.Select([| 1; 2 |], Func<int, string>(fun _ -> upper))) @>
let items = g.Compile().Invoke("ab").ToArray()
obj.ReferenceEquals(items.[0], items.[1]) // base: true; 9e58c229: false

[xperiandri]

Thanks @pcshrosbree. Changes since 31c93a1:

• Record fields. The let the compiler adds for a field it moves is no longer told apart from one written by hand: either is replaced only when its value is a read, and otherwise keeps its block. { A = Counter.Next(); B = B } after let B = Counter.Next() gives { A = 2; B = 1 } as F# does, and so does a field that is not named like its variable. Tests: Let written by hand is evaluated before the fields that follow it, Let named like the record field it feeds is evaluated before the fields that follow it, and their AsQueryable() variants.
• Nested lambdas. PENDING_BREAKING_CHANGES.md says that a read taken into a nested lambda runs for each inner element, arithmetic included, with your names.Count(fun s -> s = n) example. Member of the parameter that a nested lambda uses is read for each element of the nested lambda counts the reads of a getter on the lambda's parameter.
• EvaluateQuotation. The claim that it is unaffected is gone. A let inside a lambda that goes to a provider is replaced however the quotation is converted, and EvaluateQuotation replaces a let inside a lambda that goes to a provider pins your n + n example at two reads.
• Skipped branch. The Substring example is in the notes, and Let whose value would throw is not evaluated on a path that does not use it pins it. A division by a parameter keeps its block, so its failure is not skipped.
• items. Member of the parameter that a let names is read after a call that changes it uses the lambda's parameter and gives 2, with the 1 of main in the notes.
• Join key. join p in ps on ((k.KA, k.KB) = p.Pair) has a line in the release note and the test Join of a key built on one side with a tuple property on the other. The record case of Query builder with EF core can't return fsharp tuples (and sometimes new objects) using async methods #3782 is credited to this PR.
• A record with a type of its own for Equals and fields written out of order is converted like one with its fields in order, which distinct shows; see 9e58c22 and the notes.