Вот эта бага

Автор: IT
Дата: 02.12.13

всё ещё актуальна в VS 2015. Приведу ещё раз код здесь:

using System;
using System.Linq.Expressions;

namespace VS2013Compatibility
{
    class Program
    {
        static void Main(string[] args)
        {
            Expression<Func<string>> f1 = () => 0.ToString();
            Expression<Func<string>> f2 = () => 0l.ToString();

            var mi1 = ((MethodCallExpression)f1.Body).Method;
            var mi2 = ((MethodCallExpression)f2.Body).Method;
            var mi3 = typeof(int).GetMethod("ToString", new Type[0]);

            Console.WriteLine(mi1 == mi2);
            Console.WriteLine(mi1.DeclaringType);
            Console.WriteLine(mi2.DeclaringType);
            Console.WriteLine(mi3.DeclaringType);
        }
    }
}

Проблема в том, что для примитивных типов в ExpressionTree генерируется вызов метода object.ToString, а не int.ToString/long.ToString. В обычном коде всё работает как надо.

Куда положено эту багу уже сабмитили не раз. Кто у нас поближе к телу, можете прояснить ситуацию?

Здравствуйте, IT, Вы писали:

IT>Куда положено эту багу уже сабмитили не раз. Кто у нас поближе к телу, можете прояснить ситуацию?

Багу закрыли как Won't Fix (я удивлён что вообще не как By Design). Почему — потому что предыдущее поведение они посчитали багой, а рослин вроде как делает всё верно:

[old] compiler leaks it's codegen strategy to the expression tree generation. It ususally choses to call the least overridden method, but sometimes it doesn't. Roslyn tries to emulate the [old] expression tree shape by encoding calls to the least overridden method. Since the [old] is inconsistent in choosing the least overridden, there are cases where Roslyn and [old] differ in what methods they encode

Ну и как результат,

it would seem that the customer's solution would have to deal with both to be correct.

Если что-то не так, создавайте новый баг на коннекте, можно указать номер старого бага (DevDiv 839441)

Здравствуйте, IT, Вы писали:

IT>Куда положено эту багу уже сабмитили не раз. Кто у нас поближе к телу, можете прояснить ситуацию?

Баг был закрыт как Won't Fix. Я поднял этот вопрос ещё раз. Compatibility Council будет рассматривать его в понедельник (24 ноября 2014).
Если до понедельника (16:00 UTC) ты пришлёшь мне документ (in English), в котором приведёшь доводы в поддержку твоей позиции, я могу направить его в Compatibility Council.
Мой email есть в моём профиле на RSDN.

Здравствуйте, nikov, Вы писали:

N>Баг был закрыт как Won't Fix. Я поднял этот вопрос ещё раз. Compatibility Council будет рассматривать его в понедельник (24 ноября 2014).

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

    Call(() => 0L.ToString());

выхлоп

    IL_0000: ldc.i4.0
    IL_0001: conv.i8
    IL_0002: stloc.0
    IL_0003: ldloca.s 0
    IL_0005: call instance string [mscorlib]System.Int64::ToString() // <--

Понятно, что при изменении поведения для лямбд поломаются и деревья выражений, но тут уже будет железная отмазка: что в il, то и в выражении.

Здравствуйте, Sinix, Вы писали:

S>Дурацкий вопрос: раз решено, что поведение рослина может не совпадать с поведением предыдущих версий, нет возможности генерировать код, совпадающий с обычными лямбдами?

А что генерирует Roslyn? Нет ли там лишнего боксинга?

Здравствуйте, IT, Вы писали:

IT>А что генерирует Roslyn? Нет ли там лишнего боксинга?
У меня сейчас виртуалки с рослином под рукой нет и до понедельника не будет Надо ув Nikov просить проверить.

Здравствуйте, IT, Вы писали:

S>>Дурацкий вопрос: раз решено, что поведение рослина может не совпадать с поведением предыдущих версий, нет возможности генерировать код, совпадающий с обычными лямбдами?

IT>А что генерирует Roslyn? Нет ли там лишнего боксинга?

http://tryroslyn.azurewebsites.net/ тут можно посмотреть что генерирует Розлин, в том числе и IL. Например, так.