Fix JsonSchemaExporter dropping nullability for nullable floating-point composition schemas

[Copilot]

JsonSchemaExporter omitted null-acceptance for CLR-nullable types (double?, float?, Half?) whose schema is emitted as an anyOf composition — which happens for IEEE floating-point types under JsonNumberHandling.AllowNamedFloatingPointLiterals. The same property exports correctly as {"type":["number","null"]} under default number handling, so a double? was advertised to downstream JSON-Schema/OpenAPI consumers as a non-nullable number.

Description

• Root cause — JsonSchema.MakeNullable only adds JsonSchemaType.Null when the schema carries a concrete type keyword. Composition schemas (anyOf) have Type == Any, so nullable wrappers over floating-point anyOf schemas could lose nullability.
• Fix — Introduced a new internal virtual bool IsIeeeFloatingPointConverter property on JsonConverter, overridden to true in DoubleConverter, SingleConverter, and HalfConverter. Updated the nullable-value-type path in JsonSchemaExporter.MapJsonSchemaCore to check both this property and the presence of AllowNamedFloatingPointLiterals in the effective number handling. When both conditions are met, null is folded into the numeric branch's type keyword ("type": ["number","null"]). Added Debug.Assert statements to validate the expected anyOf schema shape for IEEE floating-point types with AllowNamedFloatingPointLiterals.
• Tests — Added regression coverage for double?, float?, Half?, and a POCO with nullable floating-point properties under global AllowNamedFloatingPointLiterals, across reflection and source-gen test contexts.

Resulting export for a nullable property:

// double? under AllowNamedFloatingPointLiterals
{"anyOf":[{"type":["number","null"]},{"enum":["NaN","Infinity","-Infinity"]}]}

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json
See info in area-owners.md if you want to be subscribed.

[eiriktsarpalis]

@copilot This doesn't look right.

[Copilot]

@copilot This doesn't look right.

Agreed — the original approach was wrong. I've reworked it in 3279084a: instead of appending a standalone { "type": "null" } branch to the anyOf, MakeNullable now folds null into the first branch that carries a concrete type. So a double? under AllowNamedFloatingPointLiterals now exports as:

{"anyOf":[{"type":["number","null"]},{"enum":["NaN","Infinity","-Infinity"]}]}

This also handles the empty/type-less anyOf edge case (no spurious null branch) and skips branches that already permit null. The test expectations were corrected accordingly. (Note: my two earlier thread replies referenced an incorrect short hash; the correct commit is 3279084a.)