Deserializing inherited class throws exception

[ray440]

Description

Deserializing an inherited F# class throws an exception:

Reproduction Steps

type Animal() = class end

type Foo() = 
	inherit Animal()
	member val Name = "init" with get, set

let js  = """{"Name":"Ed"}"""
let x = System.Text.Json.JsonSerializer.Deserialize<Foo>(js)  // zzz not good

Expected behavior

No exception

Actual behavior

AmbiguousMatchException: Multiple custom attributes of the same type 'Microsoft.FSharp.Core.CompilationMappingAttribute' found. 
   at System.Attribute.GetCustomAttribute(MemberInfo element, Type attributeType, Boolean inherit) 
   at System.Text.Json.Serialization.Metadata.FSharpCoreReflectionProxy.IsFSharpType(Type type) 
   at System.Text.Json.Serialization.Converters.FSharpTypeConverterFactory.CanConvert(Type typeToConvert) 
   at System.Text.Json.Serialization.Metadata.DefaultJsonTypeInfoResolver.GetBuiltInConverter(Type typeToConvert) 
   at System.Text.Json.Serialization.Metadata.DefaultJsonTypeInfoResolver.GetConverterForType(Type typeToConvert, JsonSerializerOptions options, Boolean resolveJsonConverterAttribute) 
   at System.Text.Json.Serialization.Metadata.DefaultJsonTypeInfoResolver.GetTypeInfo(Type type, JsonSerializerOptions options) 
   at System.Text.Json.JsonSerializerOptions.GetTypeInfoNoCaching(Type type) 
   at System.Text.Json.JsonSerializerOptions.CachingContext.CreateCacheEntry(Type type, CachingContext context) 
--- End of stack trace from previous location --- 
   at System.Text.Json.JsonSerializerOptions.GetTypeInfoInternal(Type type, Boolean ensureConfigured, Nullable`1 ensureNotNull, Boolean resolveIfMutable, Boolean fallBackToNearestAncestorType) 
   at System.Text.Json.JsonSerializerOptions.GetTypeInfoForRootType(Type type, Boolean fallBackToNearestAncestorType) 
   at System.Text.Json.JsonSerializer.GetTypeInfo[T](JsonSerializerOptions options) 
   at System.Text.Json.JsonSerializer.Deserialize[TValue](String json, JsonSerializerOptions options) 
:
--- End of stack trace from previous location --- 

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[kasperk81]

not failing on sharplab or local net9

[ray440]

not failing on sharplab or local net9

Right. This worked fine in .net 9.0.2 but failed in 9.0.3.

BTW: sharplab.io is neat!

[kasperk81]

i tested with 9.0.4 https://dotnet.microsoft.com/en-us/download

[eiriktsarpalis]

I can reproduce this starting with 9.0.300-preview, but not earlier versions of the SDK. Superficially, I cannot detect any changes in IL that might have triggered this. @dotnet/fsharp have there been any changes to codegen in recent servicing that may have triggered this?

[T-Gro]

@eiriktsarpalis:

A fairly new reflection-affecting addition is the F#9 support for struct DUs with fields shared across cases, assuming they have the same name and type.

I do not see a mention of FSharp.Core in the stacktrace, is it being called here or no?
If yes, this is likely an Fsharpcore bug and can be converted.

[T-Gro]

This is the closest change I can imagine, but this type isn't supposed to be used from user code in any way.
https://github.com/dotnet/fsharp/pull/18274/files#diff-06bb7bec1ea92205ec6f4e69f53cdf3aa53e3431db58ca15a30c7d426ab6f24bL226

Does S.T.J. use the public members from FSharp.Reflection ?
Can I transfer this bug into some invocations of FSharp.Core APIs?

[eiriktsarpalis]

Does S.T.J. use the public members from FSharp.Reflection ?

It does not, the error seems to stem from this call:

runtime/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/Metadata/FSharpCoreReflectionProxy.cs

Lines 206 to 207 in 46ec9de

	private Attribute? GetFSharpCompilationMappingAttribute(Type type)
	=> type.GetCustomAttribute(_compilationMappingAttributeType, inherit: true);

which tries to look up the compilation mapping attribute. Seems that the use of inherit: true is incorrect here, but I'm not sure why this started failing now -- this code has been around for ages.

[vzarytovskii]

Here's the diff in the codegen itself fwiw:
https://godbolt.org/z/W9Ph3EbE4
So, is it the issue with fslib? Does it reproduce with 9.0.300 + older fslib?

[T-Gro]

I believe it is the combination of the search using inherit:true and the CompilationMappingAttribute (not supposed to be used from user code) newly getting an allowMultiple:true to support struct DUs with overlapped fields.

Reason is, the hierarchy scanning in case of inherit:true does change its logic depending on AllowMultiple setting:

https://github.com/dotnet/runtime/blob/main/src/coreclr/System.Private.CoreLib/src/System/Attribute.CoreCLR.cs#L295

i.e. no changes in codegen, FSharp.Core API was not used in this case, but the mere definition of the CompilationMappingAttribute is what caused this.

In this particular case, removing inherit:true would seem the best choice, but I might be overseeing if it isn't needed for something else.

[T-Gro]

(alternatively, calling GetCustomAttributes (..butes) instead of GetCustomAttribute, and then taking the first)

[eiriktsarpalis]

newly getting an allowMultiple:true to support struct DUs with overlapped fields.

That sounds like the likely culprit. What is the potential impact of this change? Does it mean that using the latest lang version on .NET 8 or framework say will result in regressions here? What do we need to do to avoid breaking customers?

[eiriktsarpalis]

I can update the STJ code so that attribute lookup becomes more forgiving, but I don't think this would necessary meet the bar for .NET 8 or .NET 9 servicing updates.

[T-Gro]

The change is bound to the version of FSharp.Core at runtime.
If not using a pinned down version, it means that whoever builds their product with SDK 9.0.3 or newer will get that new FSharp.Core.

My proposition:

• Update for NET10 and try to service NET9
• For NET8, i.e. situation of updating SDK but staying at lower S.T.J: The workaround to avoid break is to pin down a lower version of FSharp.Core (from Nuget)