Roslyn 编译代码失败

Question

在我将项目从 VS2013 迁移到 VS2015 后，项目不再构建。以下 LINQ 语句出现编译错误：

static void Main(string[] args)
{
    decimal a, b;
    IEnumerable<dynamic> array = new string[] { "10", "20", "30" };
    var result = (from v in array
                  where decimal.TryParse(v, out a) && decimal.TryParse("15", out b) && a <= b // Error here
                  orderby decimal.Parse(v)
                  select v).ToArray();
}

编译器返回错误：

错误 CS0165 使用未分配的局部变量“b”

是什么导致了这个问题？是否可以通过编译器设置来修复它？

Answer 1

是什么导致了这个问题？

对我来说看起来像是一个编译器错误。至少，它做到了。尽管decimal.TryParse(v, out a) 和decimal.TryParse(v, out b) 表达式是动态评估的，但我预计编译器仍然可以理解，当它到达a <= b 时，a 和b 都已确定分配。即使您可以在动态类型中提出一些奇怪的问题，我也希望在评估两个 TryParse 调用之后才评估 a <= b。

然而，事实证明，通过操作符和转换技巧，有一个表达式 A && B && C 计算 A 和 C 而不是 B 是完全可行的 - 如果你足够狡猾的话。请参阅 Roslyn bug report 了解 Neal Gafter 的巧妙示例。

使用dynamic 更难——当操作数是动态时所涉及的语义更难描述，因为为了执行重载决议，您需要评估操作数以找出所涉及的类型，这可以违反直觉。然而，Neal 再次提出了一个示例，表明编译器错误是必需的……这不是错误，而是错误修复。非常感谢 Neal 的证明。

是否可以通过编译器设置来修复它？

不，但有替代方法可以避免错误。

首先，你可以阻止它是动态的——如果你知道你只会使用字符串，那么你可以使用IEnumerable<string> 或给范围变量v一个类型string（即from string v in array）。那将是我的首选。

如果您真的需要保持动态，只需给b 一个值即可：

decimal a, b = 0m;

这不会造成任何伤害 - 我们知道实际上您的动态评估不会做任何疯狂的事情，因此您最终仍会在使用之前为 b 分配一个值，使初始值无关紧要。

此外，添加括号似乎也可以：

where decimal.TryParse(v, out a) && (decimal.TryParse("15", out b) && a <= b)

这改变了触发各种重载决议的点，并且恰好使编译器高兴。

一个问题仍然存在 - 需要澄清规范中关于使用 && 运算符进行明确分配的规则，以说明它们仅适用于在其中使用 && 运算符时带有两个 bool 操作数的“常规”实现。我会尽量确保这对于下一个 ECMA 标准是固定的。

Answer 2

这似乎是 Roslyn 编译器中的一个错误，或者至少是一个回归。已提交以下错误以对其进行跟踪：

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

与此同时，Jon 的excellent answer 有几个变通办法。

Answer 3

由于我在错误报告中受到如此严格的教育，因此我将尝试自己解释这一点。

---

假设T 是某个用户定义的类型，隐式转换为bool，在false 和true 之间交替，以false 开头。据编译器所知，第一个 && 的第一个参数 dynamic 可能评估为该类型，因此它必须是悲观的。

如果它让代码编译，这可能会发生：

• 当动态绑定器评估第一个 && 时，它会执行以下操作：
  • 计算第一个参数
  • 这是一个 T - 隐式转换为 bool。
  • 哦，是false，所以我们不需要评估第二个参数。
  • 将&& 的结果作为第一个参数进行评估。 （不，不是false，出于某种原因。）
• 当动态绑定器评估第二个&& 时，它会执行以下操作：
  • 评估第一个参数。
  • 这是一个 T - 隐式将其转换为 bool。
  • 哦，是true，所以计算第二个参数。
  • ...哦，废话，b 未分配。

---

简而言之，有一些特殊的“确定赋值”规则，让我们不仅可以判断一个变量是“确定赋值”还是“未确定赋值”，还可以判断它是否“在@987654342 之后确定赋值” @语句”或“肯定在true语句之后赋值”。

这些存在以便在处理&& 和||（以及! 和?? 和?:）时，编译器可以检查是否可以在复杂布尔表达式的特定分支中分配变量。

但是，这些仅在表达式的类型保持布尔值时起作用。当表达式的一部分是dynamic（或非布尔静态类型）时，我们不能再可靠地说表达式是true 或false - 下次我们将它转​​换为bool 来决定哪个分支采取，它可能已经改变了主意。

---

更新：现在是resolved 和documented：

以前的编译器为动态表达式实现的明确分配规则允许某些代码情况可能导致读取的变量未明确分配。请参阅https://github.com/dotnet/roslyn/issues/4509 获取一份报告。

...

由于这种可能性，如果 val 没有初始值，编译器不得允许编译该程序。以前版本的编译器（VS2015 之前）允许该程序编译，即使 val 没有初始值。 Roslyn 现在诊断出这种读取可能未初始化变量的尝试。

Answer 4

这不是错误。请参阅 https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713 以了解有关此形式的动态表达式如何使此类 out 变量未赋值的示例。