[xperiandri]

Stacked on #20894

A query ending in select (c.Id, c.Name) now gives the provider one Select(c => new Tuple(c.Id, c.Name)), as C# does, instead of a Select of an internal AnonymousObject followed by a second Select converting it.

Details

• A query that ends in another operator keeps the separate conversion.
• The lets of a record with fields written out of order (Replace lets by their values in lambdas handed to a LINQ provider #20895) stay in front of the construction, so each is evaluated once.
• A nested query over a sequence that ends in a sort can now be selected inside a tuple; it failed on a type mismatch.
• EF Core already translated the two-Select form. The gain is for providers that reject AnonymousObject: Cosmos translates these queries once Name the members of tuples and records built in expression trees #20897 is in as well.

🤖 Generated with Claude Code

[github-actions]

✅ No release notes required

[xperiandri]

Covered cases

EF Core SQLite translates 100 of 137 scenarios, 99 without this change; it handled the two-Select form already. New: a sorted nested query of records selected in a tuple.

With #20897 in as well, Cosmos translates a tuple or struct tuple selected after where, a record after sortBy, a nested tuple, a tuple of nine, and a tuple before distinct.

[Copilot]

🟡 Changes recommended

The shape checks miss unnamed-projection member reads in nested queries, two-argument SelectMany, and inner Join inputs, allowing invalid query trees to pass validation.

3 open issues

• Misses unnamed projections in Join inner inputs · New
• Loses unnamed projection provenance in two-argument SelectMany · New
• Misses unnamed-member reads in nested Contains queries · New

What changed in this PR

This PR simplifies FSharp.Core query translation so a final tuple or record projection reaches the LINQ provider in one Select. It builds on #20894’s struct-tuple support and provider-shape tests; Cosmos translation also depends on #20897.

Changes:

• Construct final tuples and records directly, while preserving separate conversion when another operator follows.
• Correct type coercion for sorted sequence queries nested inside projections.
• Add query-result and expression-shape coverage, and document the behavior changes.

File	Description
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryStructureScenarios.fs	Covers query composition and final projection shapes.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryShapeTests.fs	Runs scenario groups as parameterized tests.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryScenarioDomain.fs	Supplies shared query entities and sample data.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryScenario.fs	Compares results, provider retention, and expression shapes.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryProviderShape.fs	Captures query trees and detects translation obstacles.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryProjectionScenarios.fs	Covers scalar, tuple, record, and object projections.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryOperatorScenarios.fs	Covers filtering, sorting, joins, and aggregate operators.
tests/​FSharp.Core.UnitTests/​FSharp.Core/​Microsoft.FSharp.Linq/​QueryMethodSyntaxScenarios.fs	Covers direct LINQ calls and composed projections.
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	Registers the query scenario infrastructure and tests.
src/​FSharp.Core/​QueryExtensions.fs	Simplifies anonymous-object reads and supports struct-tuple conversion.
src/​FSharp.Core/​Query.fs	Combines final projection conversion and coerces nested sequence types.
src/​FSharp.Core/​Linq.fs	Reads struct-tuple elements through fields.
docs/​release-notes/​PENDING_BREAKING_CHANGES.md	Documents the changed provider-visible projection shape.
docs/​release-notes/​.FSharp.Core/​11.0.200.md	Records struct-tuple fixes and single-Select projections.

_{Review effort: Balanced}

[pcshrosbree]

At the current head, results and evaluation counts match #20894 for the query shapes that ran on both #20894 and this PR, and EF Core 10.0.14 returns the same rows after groupBy. Please document the nested-sort crash this also fixes and add tests for the new IEnumerable coercion.

• This also fixes a crash that the release note doesn't list. Over an IQueryable, query { for x in xs do select (x, query { for y in [20; 10] do sortBy y }) } throws Type mismatch when building 'args' on main and works here.
• The added nested-sort scenario does not exercise the new IEnumerable coercion in TransInnerNoCheck. With the coercion disabled, a probe with the shape of the PR's test still passes, because the merged Select already handles that shape. With the coercion still disabled, select (x, query { for y in ys do sortBy y }) throws InvalidCastException. Adding take 2 after the outer select changes the error to Type mismatch when building 'args'. Those two would make good scenarios.

A possible follow-up: nested queries still build an AnonymousObject and convert it in a separate Select, and join still adds a Select that copies one AnonymousObject into another before the final Select.

[T-Gro]

🤖 🕵️ LGTM

Dismissed: scalar nested-sort regression coverage, release-note work, and the workflow gate remain unresolved.

[xperiandri]

Thanks @pcshrosbree. Changes since f4f49c9:

• The nested sort crash, Type mismatch when building 'args' for select (x, query { for y in [20; 10] do sortBy y }), has a line in the release note.
• a049dc5 adds the two scenarios you suggested, sorted nested query over a sequence selected in a tuple and the same with take. Both fail without the IEnumerable coercion in TransInnerNoCheck: the first with InvalidCastException, the second with Type mismatch when building 'args'.
• c1cff07 keeps the lets of a record with fields written out of order in front of the construction when the final Select is fused. It does nothing on this branch alone. With Replace lets by their values in lambdas handed to a LINQ provider #20895 merged, the tests of record fields out of order fail without it, since the fused conversion read the body once for each field and evaluated each let that often.

The nested queries that still build an AnonymousObject, and the Select that join adds to copy it, stay as a follow-up.

[T-Gro]

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

[github-actions]

Build Failure Analysis

Summary - Both Windows NativeAOT variants fail during restore because the installed .NET 11 RC2 SDK implicitly selects vulnerable Microsoft.DotNet.ILCompiler 10.0.13 for the net10.0 test project.

Root cause: SDK-supplied NativeAOT pack triggers NU1903

All 14 supplied binlogs were queried. The classic-metadata and compressed-metadata restore legs fail identically; the other 12 builds succeed. The SDK's Microsoft.NETCoreSdk.BundledVersions.props pins ILCompilerPackVersion="10.0.13" for net10.0, and NativeAOT_Test.fsproj enables PublishAot and treats warnings as errors. This dependency is implicit and none of the PR's changed files controls its version.

Affected errors

• tests/AheadOfTime/NativeAOT/NativeAOT_Test.fsproj - NU1903: Package 'Microsoft.DotNet.ILCompiler' 10.0.13 has a known high severity vulnerability (GHSA-p3jp-9v83-76w9) in 1_0 ... classic_metadata.
• tests/AheadOfTime/NativeAOT/NativeAOT_Test.fsproj - the same NU1903 in 2_0 ... compressed_metadata.

Fix attempt - blocked

Delivery - none

No code was published. Silencing NuGet audit or warning-as-error would weaken security policy, while overriding an SDK-bundled NativeAOT pack without an established compatible fixed version is not a safe change. The appropriate resolution is to consume an SDK servicing build that bundles a non-vulnerable net10 ILCompiler pack, then rerun the AOT legs.

Checks - binlog_errors and binlog_overview completed for all 14 binlogs: 12 succeeded and 2 failed only at restore with NU1903. dotnet --version && dotnet restore tests/AheadOfTime/NativeAOT/NativeAOT_Test.fsproj --runtime win-x64 -p:TreatWarningsAsErrors=true --no-cache --force-evaluate exited 155 before restore because the required repository SDK is unavailable on this runner, so no replacement could be validated. No after-change command was run because no source change was made.

Build evidence

Variant	Result	Failed target/task	Evidence
classic metadata	Failed	Restore / RestoreTask	Microsoft.DotNet.ILCompiler 10.0.13, NU1903
compressed metadata	Failed	Restore / RestoreTask	Microsoft.DotNet.ILCompiler 10.0.13, NU1903
Remaining 12 binlogs	Succeeded	None	0 errors each

The failing binlogs identify SDK 11.0.100-rc.2.26504.105; its bundled versions file selects ILCompiler 10.0.13 for net10.0. Analysis run: https://github.com/dotnet/fsharp/actions/runs/41916542875

Structured data:

{
  "artifact_kind": "analysis",
  "fix_delivery": "none",
  "fix_status": "blocked",
  "workflow_artifact": "build-failure-analysis"
}

Automated content by GitHub Copilot. Generated by the Build Failure Analysis workflow. · copilot · gpt56 · 121.3 AIC · ⌖ 12.1 AIC · ⊞ 23K | [History]( · ◷)

[pcshrosbree]

I merged this PR's head (c9fe40c) with #20895's (a49f7d9) locally and built FSharp.Core. On the merged tree, a record whose fields are written in a different order from their declaration has its fields evaluated twice when it is an item of a selected tuple:

type R = { First: int; Second: int }
// c.Next() counts its calls and returns the count so far
query { for x in [ 1; 2 ].AsQueryable() do select (x, { Second = c.Next(); First = c.Next() }) } |> Seq.toList
// merged:                     [(1, { First = 2; Second = 3 }); (2, { First = 6; Second = 7 })], 8 calls
// each PR alone, and the base: [(1, { First = 2; Second = 1 }); (2, { First = 4; Second = 3 })], 4 calls

At the top level, select { Second = c.Next(); First = c.Next() } produces the expected values and call count on the merged tree.

From reading the code, convertUnderLets moves the conversion under the lets only at the top of the select body. When a tuple item is a Let expression, it reaches the RecordConv case of ConvMutableToImmutable. That case reads each field with AnonymousObjectGet (mutExpr, i) on the whole Let, so the lets run once per field. Keeping a leading Let around the recursive conversion in ConvMutableToImmutable should address this nesting; I have not tested that change. Moving the lets to the top would change the evaluation order: they would run before the tuple's earlier items.