Repository navigation
Description
Problem
#288 and #287 need two things at once: a public type that implements an interface a framework keys a heuristic off (RangeSet<TRange, T> : IReadOnlyList<TRange>), and a member name the framework matches by name alone (Contains). EF Core's collection-Contains normalization took RangeSet.Contains(T) for ICollection<T>.Contains (dotnet/efcore#39329). Nothing in the repository lists where its public types meet such heuristics, so nobody knew which tests to rerun when EF Core changed one. The value-set rule "never implement IEnumerable<T>" is this check done by hand for one heuristic.
Change
- An inventory of the name- and interface-based heuristics of the frameworks the packages meet, kept like
postgres-surface.json: EF Core (collectionContainsnormalization, primitive-collection discovery overIEnumerable<T>,Count/Lengthmember rewrites, …), System.Text.Json (collection and dictionary contracts), MVC and minimal-API binding (collection binders,TryParse/BindAsyncdiscovery), OpenAPI schema generation. Each entry quotes the upstream code that matches and names the upstream version it was read from. - A reflection sweep in the conventions project: every public type of every
src/package against every heuristic it triggers, each pair held by a named test or waived with a reason. Discovered, so a new type or a new interface on an existing type fails until it is classified. - The pair
RangeSet × EF Core collection-Contains normalizationis the first row, held by the translation tests of the 10.x:RangeSet.ContainsthrowsArgumentExceptionon the EF Core 10 patch that carries dotnet/efcore#37081 #288 fix.
Done when
The sweep runs in CI, lists every type × heuristic pair, and fails on an unclassified one, with a seed under test/oracles/seeds/ showing it catches a type that newly implements IReadOnlyCollection<T> with a non-element Contains overload.
Activity