ValueTuple<System.__Canon, System.__Canon> returned from funcEval of List<ValueTuple<string, string>>.get_Item(int)

[WardenGnaw]

In VS, creating a dotnet 3.0 console app with:

var list = new List<(string first, string second)>();
list.Add(("first", "second"));

Adding list[0].first in the watch window results in it being null.

This is due to funeval-ing System.Collections.Generic.List'1[T].get_Item with two arguments via ICorDebugEval2.CallParameterizedFunction.
The two arguments are:

[0]: "System.Collections.Generic.List'1[[System.ValueTuple'2[[System.String, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.String, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]"
[1]: "System.Int32"

However, the CorValue of this call results in "System.ValueTuple'2[[System.__Canon, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]"

[hoyosjs]

@tommcdon @dotnet/dotnet-diag

[gafter]

FYI I originally reported this, and it wound its way through three different bug tracking systems to land here.

[tmat]

@dotnet/dotnet-diag We have seen multiple customer reports so far. Please prioritize accordingly.

[sdmaclea]

@fadimounir This looks like it was introduced by the universal shared generics work

[fadimounir]

Adding @noahfalk .

@sdmaclea There aren't any universal shared generics work in dotnet/coreclr currently. The instantiation however does use normal shared generics code, and i suspect that the debugger somewhere needs to interpret the result in the context of the correct instantiation, not the __Canon based one. I don't know much about how the debugger does that today. Maybe @noahfalk could provide more guidance on this one.

[noahfalk]

My experiments show this reproduces on .NET Framework, .Net Core 2.0, 2.1, 2.2 and 3.0 so whatever the issue is it must have existed for a while.

My best guess is that the funceval code is determining the type of the return value by doing some dynamic inspection of the returned object/struct. For a reference type the precise type would be inferable from the 'this' value, but for a struct we can't compute the exact type that way. The only way to get it would be to capture the exact return type of the called method after substituting the generic type arguments provided by the caller. Its possible the runtime debugger code isn't attempting to do that computation at all, or that some more subtle bug has prevented the computation from working in this case. I believe the relevant behavior to investigate is probably occurring here: https://github.com/dotnet/coreclr/blob/ed5dc831b09a0bfed76ddad684008bebc86ab2f0/src/debug/ee/funceval.cpp#L2232-L2265