[xperiandri]

Fixes #15522

Selecting a struct tuple in a query no longer fails with "unreachable", and taking one apart in a lambda passed as Expression<Func<..>> no longer fails with "Struct tuples store their elements in fields, not properties".

Details

• Query tests ran over AsQueryable() and compared rows, so any tree LINQ to Objects can run passed, including trees no SQL provider translates. The scenario tests added here also check the tree the provider receives against what a C# expression lambda can contain: the query stays on its provider, and there is no block, no unbound parameter, no call into FSharp.Core, no join nested in a collection selector, and no member read from a tuple built without naming its members.
• The struct tuple lines in Linq.fs do what Convert struct tuple patterns in LeafExpressionConverter #20886 does, and go from this PR when that one merges.
• Each scenario lists the problems its tree has today and fails when one of them disappears or another appears, so each follow-up PR removes exactly the entries it makes untrue.

🤖 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

Checked against EF Core SQLite (SQL executed, rows compared) and the Cosmos LINQ provider (SQL text), with the scenario files of this PR.

EF Core SQLite translates 91 of 128 scenarios, 87 with main's FSharp.Core. Now translated: a struct tuple of two, of nine, inside a tuple, and a tuple inside a struct tuple.

[Copilot]

🟡 Changes recommended

Validation gaps miss nested or captured query violations and client-side terminal execution, while incorrect Join selector-to-input mapping causes false positives and missed violations.

3 open issues

• Misses unnamed tuple reads in nested and captured query chains · New
• Join selector analysis uses incorrect input sequences · New
• Client-side Count is accepted without requiring provider execution · New

What changed in this PR

This PR addresses #15522 by supporting struct tuples in FSharp.Core query translation and LINQ expression lambdas. It also adds scenario tests that check expression-tree structure alongside query results.

Changes:

• Preserve struct tuple types through query conversion and read their fields when translating tuple access.
• Add query scenarios covering projections, operators, keys, nested queries, joins, and method syntax, with explicit expected violations.
• Document the struct tuple fixes in the release notes.

File	Description
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryStructureScenarios.fs	Adds loop, nested-query, and left-join scenarios.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryShapeTests.fs	Registers scenario groups as parameterized tests.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryScenarioDomain.fs	Defines shared entities and query data.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryScenario.fs	Compares results, tree violations, and operator chains.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryProviderShape.fs	Captures provider expressions and checks tree structure.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryProjectionScenarios.fs	Covers tuple, record, and other projections.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryOperatorScenarios.fs	Covers sequence and scalar query operators.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryMethodSyntaxScenarios.fs	Covers direct LINQ calls and tuple destructuring.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryKeyScenarios.fs	Covers join and grouping key shapes.
tests/​FSharp.Core.UnitTests/​FSharp.Core.UnitTests.fsproj	Includes the new test files in compilation order.
src/​FSharp.Core/​QueryExtensions.fs	Supports struct tuples in anonymous-object conversion.
src/​FSharp.Core/​Query.fs	Restores struct tuples when reconstructing query results.
src/​FSharp.Core/​Linq.fs	Translates struct tuple access through fields and nested Rest values.
docs/​release-notes/​.FSharp.Core/​11.0.200.md	Documents the struct tuple query and expression-tree fixes.

_{Review effort: Balanced}

[pcshrosbree]

At 526db26 the struct tuple cases work, reference tuples and records are unchanged, and the validator now catches the nested, captured and Join cases Copilot raised. Please address the remaining validator and release-note gaps.

• Violations are compared as sets of kinds, so a tree with one block and a tree with two compare equal. The comparison catches a violation kind disappearing, but not a drop in its count.
• No scenario exercises UnboundParameter or LambdaInvocation: with either check removed, all scenarios still pass. LeftProvider is now covered by one of the new validator tests, but by no scenario.
• The release note says struct tuples failed with a tuple index out of range. On main the error is ArgumentException: Struct tuples store their elements in fields, not properties.

The Linq.fs change implements the same logic as my #20886, which fixes #20884. My tests there also cover EvaluateQuotation, 16-element tuples with two levels of Rest, and let struct on a named parameter. I can move those tests here, or keep them in #20886 and remove the overlapping code from that PR, whichever you prefer.

[T-Gro]

🤖 🕵️ AI review — verify independently.

[T-Gro]

🤖 🕵️ [P1] Queryable returns [22] instead of native/Enumerable [21] — Bump mutates the tuple field rather than a defensive copy.

open System.Linq

[<Struct>]
type Counter =
    val mutable Value: int
    new(v) = { Value = v }
    member x.Bump() =
        x.Value <- x.Value + 1
        x.Value

[<ReflectedDefinition>]
let project (struct (counter: Counter, marker: int)) =
    counter.Bump() + counter.Value + marker

let rows = [struct (Counter(5), 10)]
rows |> List.map project // [21]
query { for row in rows do select (project row) } |> Seq.toList // [21]
query { for row in rows.AsQueryable() do select (project row) } |> Seq.toList // [22]

[pcshrosbree]

The missing defensive copy is a bug on main already, without struct tuples, so I'll open a separate issue for it. I checked on main and on my #20886, which has the same struct-tuple arm. On main, Queryable gives [12] for a struct bound by let, where F# gives [11]:

[<ReflectedDefinition>]
let projectLet (n: int) =
    let counter = Counter(n)
    counter.Bump() + counter.Value

	F# and Enumerable	Queryable on main	Queryable on #20886 and this PR
your example	[21]	ArgumentException	[22]
projectLet 5	[11]	[12]	[12]

F# calls Bump on a copy of the immutable counter, while the converted tree calls it on the variable itself. On main your example threw before reaching that point, so the struct-tuple arm exposes the missing copy rather than causing it.

Update: I've opened #20908 for the missing defensive copy, with a fix in #20909. I tested #20886 with that fix applied, and your example gives [21].

[xperiandri]

Agreed with @pcshrosbree: this is not about struct tuples. On main a struct bound by let gives [12] where F# gives [11], because the converted tree calls the method on the variable and not on a copy. The struct tuple arm only reaches that code now, so I leave the copy to the separate issue that @pcshrosbree is opening.

[xperiandri]

Thanks @pcshrosbree. Changes since 526db26:

• Violations are compared with every occurrence (521e830): a tree that loses one of two blocks no longer passes. The scenarios that have several of a kind are pinned with their number.
• UnboundParameter and LambdaInvocation have facts with hand-built trees, and LeftProvider has scenarios for both client counts.
• b418d09 closes two gaps the review bot found in the same validator: a result selector that gives an unnamed element back, and the element parameter of Aggregate. Scenarios now compare an entity by every plain property and not by its key alone.
• The release note names the error of main, ArgumentException: Struct tuples store their elements in fields, not properties.

#20886 stays yours. The struct tuple lines in Linq.fs go from this PR when it merges, and I rebase on it then.

[T-Gro]

🤖 🕵️ Re-reviewed all recent changes as of b418d09; LGTM