可能是 Visual Studio 2015 中的 C# 编译器错误

Question

我认为这是一个编译器错误。

以下控制台应用程序在使用 VS 2015 编译时可以完美地编译和执行：

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            var x = MyStruct.Empty;
        }

        public struct MyStruct
        {
            public static readonly MyStruct Empty = new MyStruct();
        }
    }
}

但现在变得很奇怪：这段代码可以编译，但在执行时会抛出 TypeLoadException。

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            var x = MyStruct.Empty;
        }

        public struct MyStruct
        {
            public static readonly MyStruct? Empty = null;
        }
    }
}

您是否遇到过同样的问题？如果是这样，我将向 Microsoft 提出问题。

代码看起来毫无意义，但我用它来提高可读性和消除歧义。

我有不同重载的方法，比如

void DoSomething(MyStruct? arg1, string arg2)

void DoSomething(string arg1, string arg2)

以这种方式调用方法...

myInstance.DoSomething(null, "Hello world!")

... 无法编译。

打电话

myInstance.DoSomething(default(MyStruct?), "Hello world!")

或

myInstance.DoSomething((MyStruct?)null, "Hello world!")

有效，但看起来很难看。我更喜欢这种方式：

myInstance.DoSomething(MyStruct.Empty, "Hello world!")

如果我将Empty 变量放入另一个类，一切正常：

public static class MyUtility
{
    public static readonly MyStruct? Empty = null;
}

奇怪的行为，不是吗？

---

2016 年 3 月 29 日更新

我在这里开票：http://github.com/dotnet/roslyn/issues/10126

---

2016 年 4 月 6 日更新

此处已开新票：https://github.com/dotnet/coreclr/issues/4049

Answer 1

首先，重要的是在分析这些问题时制作一个最小的复制器，这样我们就可以缩小问题所在。在原始代码中有三个红鲱鱼：readonly、static 和Nullable<T>。没有必要重现这个问题。这是一个最小的复制：

struct N<T> {}
struct M { public N<M> E; }
class P { static void Main() { var x = default(M); } }

这在当前版本的VS中编译，但运行时抛出类型加载异常。

• 使用E 不会触发异常。它由任何访问类型M 的尝试触发。 （正如人们在类型加载异常的情况下所期望的那样。）
• 异常重现字段是静态还是实例，只读与否；这与该领域的性质无关。 （但是它必须是一个字段！如果它是一个方法，那么这个问题就不会重现。）
• 异常与“调用”无关；最小复制中没有“调用”任何内容。
• 该异常与成员访问运算符“.”无关。它不会出现在最小复制中。
• 异常与可空值无关；在最小复制中没有任何内容可以为空。

现在让我们做更多的实验。如果我们创建N 和M 类怎么办？我会告诉你结果：

• 只有当两者都是结构时，该行为才会重现。

我们可以继续讨论问题是否仅在 M 在某种意义上“直接”提及自身时才会重现，或者“间接”循环是否也会重现错误。 （后者是正确的。）正如 Corey 在他的回答中指出的那样，我们也可以问“类型必须是通用的吗？”不;有一个比没有泛型的复制器更小的复制器。

但是我认为我们已经足够完成对复制器的讨论并继续讨论手头的问题，即“这是一个错误，如果是，在什么地方？”

显然这里出了点问题，我今天没有时间理清应该归咎于哪里。以下是一些想法：

• 禁止包含自身成员的结构的规则显然不适用于此处。 （请参阅 C# 5 规范的第 11.3.1 节，这是我手头的那个。我注意到，在考虑泛型的情况下仔细重写本节可能会受益；这里的一些语言有点不精确。）如果E 是静态的，则该部分不适用；如果它不是静态的，那么N<M> 和M 的布局都可以计算出来。

• 我知道 C# 语言中没有其他规则会禁止这种类型排列。

• 可能CLR 规范禁止这种类型的排列，CLR 在这里抛出异常是正确的。

所以现在让我们总结一下可能性：

• CLR 存在错误。这种类型的拓扑应该是合法的，CLR扔在这里是不对的。

• CLR 行为正确。这种类型的拓扑是非法的，CLR扔在这里是正确的。 （在这种情况下，可能是 CLR 存在规范错误，因为规范中可能没有充分解释这一事实。我今天没有时间进行 CLR 规范潜水。）

  李>

让我们假设第二个是真的。我们现在可以对 C# 说些什么？一些可能性：

• C# 语言规范禁止该程序，但实现允许它。该实现有一个错误。 （我认为这种情况是错误的。）

• C# 语言规范并未禁止此程序，但可以以合理的实施成本来禁止此程序。在这种情况下，C# 规范有问题，应该修复它，并且应该修复实现以匹配。

• C# 语言规范并未禁止该程序，但无法以合理的成本在编译时检测问题。几乎所有运行时崩溃都是这种情况。您的程序在运行时崩溃了，因为编译器无法阻止您编写有缺陷的程序。这只是一个错误的程序；不幸的是，你没有理由知道它有问题。

总结一下，我们的可能性是：

• CLR 有一个错误
• C# 规范有一个错误
• C# 实现存在错误
• 程序有错误

这四个中的一个必须为真。我不知道它是哪个。如果让我猜，我会选第一个；我看不出为什么 CLR 类型加载器应该拒绝这个。但也许有一个我不知道的充分理由；希望 CLR 类型加载语义方面的专家能够参与进来。

---

更新：

在此处跟踪此问题：

https://github.com/dotnet/roslyn/issues/10126

总结 C# 团队在该问题中的结论：

• 根据 CLI 和 C# 规范，该程序是合法的。
• C# 6 编译器允许该程序，但 CLI 的一些 实现会引发类型加载异常。这是这些实现中的一个错误。
• CLR 团队意识到了这个错误，显然很难修复有错误的实现。
• C# 团队考虑让合法代码产生警告，因为它会在运行时在某些（但不是所有）CLI 版本上失败。

C# 和 CLR 团队正在处理这个问题；跟进他们。如果您对此问题有任何疑问，请发布到跟踪问题，而不是此处。

Answer 2

这不是 2015 年的错误，但可能是 C# 语言错误。下面的讨论涉及为什么 instance members 不能引入循环，以及为什么 Nullable<T> 会导致此错误，但不应应用于静态成员。

我会将其作为语言错误而不是编译器错误提交。

---

在 VS2013 中编译这段代码会出现以下编译错误：

“System.Nullable”类型的结构成员“ConsoleApplication1.Program.MyStruct.Empty”导致结构布局中出现循环

快速搜索出现this answer，其中指出：

拥有一个包含自身作为成员的结构是不合法的。

不幸的是，用于值类型的可为空实例的System.Nullable<T> 类型也是值类型，因此必须具有固定大小。很容易将MyStruct? 视为引用类型，但实际上并非如此。 MyStruct? 的大小是基于MyStruct 的大小...显然在编译器中引入了一个循环。

举个例子：

public struct Struct1
{
    public int a;
    public int b;
    public int c;
}

public struct Struct2
{
    public Struct1? s;
}

使用System.Runtime.InteropServices.Marshal.SizeOf()，您会发现Struct2 的长度为16 个字节，这表明Struct1? 不是一个引用，而是一个比Struct1 长4 个字节（标准填充大小）的结构。

---

这里没有发生了什么

响应 Julius Depulla 的回答和 cmets，当您访问 static Nullable<T> 字段时，实际上会发生什么。从此代码：

public struct foo
{
    public static int? Empty = null;
}

public void Main()
{
    Console.WriteLine(foo.Empty == null);
}

这是从 LINQPad 生成的 IL：

IL_0000:  ldsflda     UserQuery+foo.Empty
IL_0005:  call        System.Nullable<System.Int32>.get_HasValue
IL_000A:  ldc.i4.0    
IL_000B:  ceq         
IL_000D:  call        System.Console.WriteLine
IL_0012:  ret         

第一条指令获取静态字段foo.Empty 的地址并将其压入堆栈。此地址保证为非空，因为Nullable<Int32> 是一个结构而不是引用类型。

接下来调用Nullable<Int32>隐藏成员函数get_HasValue来检索HasValue属性值。这不会导致空引用，因为如前所述，值类型字段的地址必须是非空的，无论地址中包含的值如何。

剩下的只是将结果与 0 进行比较并将结果发送到控制台。

无论这意味着什么，在此过程中都无法“在类型上调用 null”。值类型没有空地址，因此对值类型的方法调用不能直接导致空对象引用错误。这就是我们不称它们为引用类型的原因。

Answer 3

既然我们已经就什么和原因进行了长时间的讨论，这里有一种解决问题的方法，而无需等待各个 .NET 团队来追踪问题并确定是否会采取任何措施.

问题似乎仅限于作为值类型的字段类型，这些值类型以某种方式引用回此类型，无论是作为泛型参数还是静态成员。例如：

public struct A { public static B b; }
public struct B { public static A a; }

呃，我现在觉得很脏。糟糕的 OOP，但它表明问题存在而无需以任何方式调用泛型。

因此，因为它们是值类型，所以类型加载器确定存在循环性，由于 static 关键字，应该忽略该循环性。 C# 编译器足够聪明，可以弄清楚。它是否应该取决于规格，我对此没有评论。

但是，通过将 A 或 B 更改为 class，问题就消失了：

public struct A { public static B b; }
public class B { public static A a; }

所以可以通过使用引用类型来存储实际值并将字段转换为属性来避免该问题：

public struct MyStruct
{
    private static class _internal { public static MyStruct? empty = null; }
    public static MyStruct? Empty => _internal.empty;
}

这有点慢，因为它是一个属性而不是一个字段，对它的调用将调用 get 方法，所以我不会将它用于性能关键代码，但作为一种解决方法，它至少可以让你完成这项工作，直到找到合适的解决方案。

如果事实证明这个问题没有得到解决，至少我们有一个可以用来绕过它的组合。