Invalid metadata emitted for a System.ValueTuple type

[AlekseyTs]

namespace System
{
    public struct ValueTuple<T1, T2>
    {
    }
}

Observed:

.class public sequential ansi sealed beforefieldinit System.ValueTuple`2<T1,T2>
       extends [mscorlib]System.ValueType
{
  .field public !T1 Item1
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 
  .field public !T2 Item2
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 
} // end of class System.ValueTuple`2

Note, declaration of two public fields that appeared from nowhere.

[AlekseyTs]

cc @jcouv

[jcouv]

That one is expected and covered by existing tests. The type is recognized as a tuple and therefore has tuple elements.

[AlekseyTs]

That one is expected

I don't think so. The fields are not declared and shouldn't appear out of thin air.

and covered by existing tests.

Doesn't make the behavior correct.

[AlekseyTs]

That certainly wasn't a behavior prior to #39370 and the Symbol Model change was not supposed to change behavior. Also, the fact that it not By Design can be observed by compiling the following code:

namespace System
{
    public struct ValueTuple<T1, T2>
    {
	
    }
}

class Program
{
    static void Main()
    {
        _ = (1, 2).Item1;
        _ = (1, 2).Item2;
    }
}

Observed:

(13,20): error CS8128: Member 'Item1' was not found on type '(T1, T2)' from assembly '?, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
(14,20): error CS8128: Member 'Item2' was not found on type '(T1, T2)' from assembly '?, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.

As we can see, the fields do not exist, even compiler thinks that. And that is expected and always worked this way.

[jcouv]

I understand it was not the prior behavior, because then ValueTuple was the underlying type of tuples, but not a tuple itself. That has intentionally changed.

[AlekseyTs]

I understand it was not the prior behavior, because then ValueTuple was the underlying type of tuples, but not a tuple itself. That has intentionally changed.

We are talking about undeclared fields not about our view on types themselves. One has nothing to do with another and fields just aren't becoming declared because of that. I agree the behavior is a fall out of the implementation work with intent to change how we represent tuple types, but we didn't want that kind of change in behavior, it is not unavoidable (even with the new view on the types) and this is just an oversight.

I think this is a bad change, obviously inconsistent with overall compiler's behavior around missing declarations in tuples. We are emitting error fields. The symbols are TupleErrorFieldSymbols. They have a use-site error associated with them. They are created for the purpose of reporting the errors. That is the intent behind them and I see no indication of intent to emit them. The current behavior simply doesn't connect with other pieces of the "puzzle". I also do not remember any discussions around that change.
In my opinion, this is an oversight and, if indeed there is an existing test where we can observe the current behavior, this is a double oversight. We should fix this ASAP.