[CaffeinatedCoder]

Closes #464

Problem

#385 and #452 keep a Compare(x, y) over ranges or sets out of SQL, because EF Core reads any int Compare(T, T) as the natural order (dotnet/efcore#39402). The rewrite replaced the call with RangeComparerCall.RunInMemory, and that called IComparer<T>.Compare instead of the method the code called. An outside pre-tag review of release/10.x found the first case below; the reproduction found the other two. On PostgreSQL 16, with p = [2026-03-01,2026-03-09]:

Call	Before	Memory
split.Compare(r.Period, p) in a Select: public Compare and explicit IComparer<T>.Compare differ	0, from the explicit implementation	1
helper.Compare(r.Period, p) on a class that implements no IComparer	runs in SQL: CASE WHEN r."Period" = @p THEN 0 …, in Select and in Where	its own answer
static LowerBound.Compare(r.Period, p)	the same as the row above	its own answer

No error in any of them. The docs promise that a comparer's Compare over ranges runs in memory only.

Change

• RangeComparerCall: RunInMemory<TComparer, T>(comparer, x, y, int call) and RunInMemory<T>(x, y, int call) run a compiled delegate of the call as written. The delegate sits in a registry, one per method and receiver type, and the query holds only its int id. EF Core rejects a delegate constant in a client projection because the cached query would capture it, but it accepts a constant of a type it maps. A filter or an ordering still fails translation, and the message still names RangeComparerCall.RunInMemory.
• RangeComparerRewriter: rewrites any int Compare(T, T) with a range, range set or value set operand, static or instance, whatever type declares it. That is exactly the set of calls EF Core's ComparisonTranslator takes. The IComparer/IComparer<T> lookup and the non-generic overload are gone.
• docs/efcore.md (What runs where), docs/migration.md, claim E31 and the changelog rows (root and EF Core) cover the static Compare, a Compare on a class that isn't a comparer, and the method that runs.

Tests

• ClientSideOnlyTranslationTests: Where and OrderBy rows for a Compare on a class that isn't a comparer, and for a static Compare.
• LowerBoundComparerQueryTests (live): the projection test agrees with memory for all three cases (the split comparer's explicit implementation compares in the range order), and the filter/ordering test expects RunInMemory translation failures for them.
• Reverted (the old RangeComparerCall and rewriter back, the new tests kept): 4 translation rows fail; the live filter query returns rows instead of throwing; the live projection gets server 0,1,-1,1,-1 against memory 0,0,0,1,-1 for the split comparer.
• EF unit tests (366), NodaTime EF tests (103) and conventions (417) pass on the .NET 11 SDK RC2. Live, LowerBoundComparerQueryTests, ClientSideOnlyProjectionTests, TranslationSupportProbeTests and CapturedCollectionProbeTests pass on PostgreSQL 16. The seed lower-bound-comparer-runs-as-sql.patch still applies.

🤖 Generated with Claude Code