Roslyn не удалось скомпилировать код

После того, как я перенес свой проект с 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'

Что вызывает эту проблему? Можно ли это исправить настройкой компилятора?

Что вызывает эту проблему?

Мне кажется, это ошибка компилятора. По крайней мере, так оно и было. Хотя decimal.TryParse(v, out a)и decimal.TryParse(v, out b)выражения вычисляются динамически, я ожидал , что компилятор до сих пор понять , что к тому времени он достигает a <= b, как aи bопределенно присвоенной. Даже с учетом странностей, которые могут возникнуть при динамической типизации, я бы ожидал, что когда-либо буду оценивать только a <= bпосле оценки обоих TryParseвызовов.

Тем не менее, оказывается, что через оператор и преобразование сложного, это вполне возможно , чтобы иметь выражение , A && B && Cкоторое приводится Aи , Cно не B- если вы хитрая достаточно. См. Гениальный пример Нила Гафтера в отчете об ошибке Roslyn .

Заставить эту работу работать dynamicеще сложнее - семантику, используемую, когда операнды являются динамическими, сложнее описать, потому что для выполнения разрешения перегрузки вам необходимо оценить операнды, чтобы выяснить, какие типы задействованы, что может быть нелогичным. Однако, опять - таки Нил придумал пример , который показывает , что требуется ошибка компилятора ... Это не ошибка, это ошибка исправления . Большое спасибо Нилу за доказательство этого.

Можно ли исправить через настройки компилятора?

Нет, но есть альтернативы, позволяющие избежать ошибки.

Во-первых, вы можете сделать так, чтобы он не был динамическим - если вы знаете, что будете использовать только строки, вы можете использовать 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.

Это действительно похоже на ошибку или, по крайней мере, регресс в компиляторе Roslyn. Для его отслеживания была зарегистрирована следующая ошибка:

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

А пока у отличного ответа Джона есть пара обходных путей.

Поскольку я так усердно изучал отчет об ошибке, я попытаюсь объяснить это сам.

Представьте, что Tэто некоторый определяемый пользователем тип с неявным приведением к, boolкоторое чередуется между falseи true, начиная с false. Насколько известно компилятору, dynamicпервый аргумент первого &&может оценивать этот тип, поэтому он должен быть пессимистичным.

Если тогда он позволит коду скомпилировать, это может произойти:

• Когда динамическое связующее оценивает первое &&, оно выполняет следующие действия:
  • Оцените первый аргумент
  • Это T- неявно приведено к bool.
  • О, это так false, поэтому нам не нужно оценивать второй аргумент.
  • Сделайте результат &&оценки первым аргументом. (Нет, falseпо какой-то причине.)
• Когда динамическое связующее оценивает второе &&, оно выполняет следующие действия:
  • Оцените первый аргумент.
  • Это T- неявно приведено к bool.
  • Ах да, trueтак что оцените второй аргумент.
  • ... Вот дерьмо, bне назначено.

Короче говоря, существуют специальные правила «определенного присваивания», которые позволяют нам говорить не только о том, является ли переменная «определенно назначенной» или «определенно не назначенной», но также и «определенно назначена после falseоператора» или «определенно назначена». назначается после trueзаявления ".

Они существуют для того, чтобы при работе с &&и ||(и !и ??и ?:) компилятор мог проверить, могут ли быть присвоены переменные в определенных ветвях сложного логического выражения.

Однако они работают, только если типы выражений остаются логическими . Когда часть выражения является dynamic(или не-логическим статическим типом), мы больше не можем достоверно сказать, что выражение является trueили false- в следующий раз, когда мы приведем его, boolчтобы решить, какую ветвь выбрать, оно могло передумать.

Обновление: теперь это решено и задокументировано :

Правила определенного присваивания, реализованные предыдущими компиляторами для динамических выражений, допускали некоторые случаи кода, которые могли привести к чтению переменных, которые не были назначены определенно. См. Https://github.com/dotnet/roslyn/issues/4509 для одного отчета об этом.

...

Из-за этой возможности компилятор не должен разрешать компиляцию этой программы, если val не имеет начального значения. Предыдущие версии компилятора (до VS2015) позволяли компилировать эту программу, даже если val не имеет начального значения. Roslyn теперь диагностирует эту попытку чтения возможно неинициализированной переменной.

Это не ошибка. См. Https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713 для примера того, как динамическое выражение этой формы может оставить такую ​​выходную переменную неназначенной.