Как я могу надежно определить тип переменной, которая объявляется с помощью var во время проектирования?

Я работаю над завершением (intellisense) средство для C# в emacs.

Идея, если пользователь вводит фрагмент, то просит завершение через конкретное сочетание клавиш, средство завершения будет использовать отражение.NET для определения возможных завершений.

Выполнение этого требует, чтобы тип завершаемой вещи, был известен. Если это - строка, существует известный набор возможных методов и свойств; если это - Int32, это имеет отдельный набор и так далее.

Используя семантический, пакет лексического анализатора/синтаксического анализатора кода, доступный в emacs, я могу определить местоположение объявлений переменной и их типов. Учитывая, что, это просто для использования отражения, чтобы получить методы и свойства на типе, и затем представить список опций пользователю. (Хорошо, не совсем простой, чтобы сделать в emacs, но использовании способности выполнить процесс powershell внутри emacs, это становится намного легче. Я пишу пользовательский блок.NET, чтобы сделать отражение, для загрузки его в powershell, и затем elisp работающий в emacs может отправить команды в powershell и считать ответы через comint. В результате emacs может получить результаты отражения быстро.)

Проблема прибывает, когда код использует var в объявлении завершаемой вещи. Это означает, что тип явно не указан, и завершение не будет работать.

Как я могу надежно определить фактический используемый тип, когда переменная объявляется с var ключевое слово? Только, чтобы быть ясным, я не должен определять его во времени выполнения. Я хочу определить его во "Время проектирования".

До сих пор у меня есть эти идеи:

1. скомпилируйте и вызовите:
   • извлеките оператор объявления, например, 'нечто var = "строковое значение"';
   • свяжите оператор 'нечто. GetType ()';
   • динамично скомпилируйте получающийся фрагмент C# это в новый блок
   • загрузите блок в новый AppDomain, выполните framgment и получите тип возврата.
   • разгрузите и отбросьте блок

   Я знаю, как сделать все это. Но это звучит ужасно как тяжеловес для каждого запроса завершения в редакторе.

   Я предполагаю, что мне не нужен свежий новый AppDomain каждый раз. Я мог снова использовать единственный AppDomain для нескольких временных блоков и амортизировать стоимость установки его и разъединения его через несколько запросов завершения. Это - больше тонкая настройка основной идеи.

2. скомпилируйте и осмотрите IL

   Просто скомпилируйте объявление в модуль и затем осмотрите IL, для определения фактического типа, который был выведен компилятором. Как это было бы возможно? Что я использовал бы для исследования IL?

Какие-либо лучшие идеи там? Комментарии? предложения?

РЕДАКТИРОВАНИЕ - думающий об этом далее, компилировать-и-вызывать не приемлемо, потому что вызывание может иметь побочные эффекты. Таким образом, первая опция должна быть исключена.

Кроме того, я думаю, что не могу принять присутствие.NET 4.0.

ОБНОВЛЕНИЕ - корректный ответ, неупомянутый выше, но мягко указанный Eric Lippert, должен реализовать полную систему вывода типа точности. Это; s единственный способ надежно определить тип var во время проектирования. Но, также не легко сделать. Поскольку я не переношу иллюзий, что я хочу попытаться создать такую вещь, я взял ярлык опции 2 - извлекают соответствующий код объявления, и компилируют его, затем осматривают получающийся IL.

Это на самом деле работает для справедливого подмножества сценариев завершения.

Например, предположите в следующих фрагментах кода? положение, в котором пользователь просит завершение. Это работает:

var x = "hello there"; 
x.?

Завершение понимает, что x является Строкой и предоставляет подходящие возможности. Это делает это путем генерации и затем компиляции следующего исходного кода:

namespace N1 {
  static class dmriiann5he { // randomly-generated class name
    static void M1 () {
       var x = "hello there"; 
    }
  }
}

... и затем осматривая IL с простым отражением.

Это также работает:

var x = new XmlDocument();
x.? 

Механизм добавляет соответствующие пункты использования к сгенерированному исходному коду, так, чтобы он скомпилировал правильно, и затем контроль IL является тем же.

Это работает, также:

var x = "hello"; 
var y = x.ToCharArray();    
var z = y.?

Это просто означает, что контроль IL должен найти тип третьей локальной переменной вместо первого.

И это:

var foo = "Tra la la";
var fred = new System.Collections.Generic.List
    {
        foo,
        foo.Length.ToString()
    };
var z = fred.Count;
var x = z.?

... который является всего одним уровнем глубже что предшествующий пример.

Но, что не работает, завершение на любой локальной переменной, инициализация которой зависит в любой точке от члена экземпляра или локальном аргументе метода. Как:

var foo = this.InstanceMethod();
foo.?

Ни синтаксис LINQ.

Я должен буду думать о том, насколько ценный те вещи состоят в том, прежде чем я рассмотрю обращение к ним через то, что является определенно "ограниченным дизайном" (вежливое слово для взлома) для завершения.

Подход к решению проблемы с зависимостями от аргументов метода или методов экземпляра должен был бы заменить во фрагменте кода, который сгенерирован, скомпилированный и затем проанализированная IL, ссылки на те вещи с "синтетическим" локальным Варом того же типа.

Другое Обновление - завершение на Варе, которые зависят от членов экземпляра, теперь работает.

То, что я сделал, было опросить тип (через семантический) и затем генерировать синтетического заместителя участников для всех существующих участников. Поскольку C# буферизует как это:

public class CsharpCompletion
{
    private static int PrivateStaticField1 = 17;

    string InstanceMethod1(int index)
    {
        ...lots of code here...
        return result;
    }

    public void Run(int count)
    {
        var foo = "this is a string";
        var fred = new System.Collections.Generic.List
        {
            foo,
            foo.Length.ToString()
        };
        var z = fred.Count;
        var mmm = count + z + CsharpCompletion.PrivateStaticField1;
        var nnn = this.InstanceMethod1(mmm);
        var fff = nnn.?

        ...more code here...

... сгенерированный код, который компилируется, так, чтобы я мог узнать из вывода о IL тип локального var nnn, похож на это:

namespace Nsbwhi0rdami {
  class CsharpCompletion {
    private static int PrivateStaticField1 = default(int);
    string InstanceMethod1(int index) { return default(string); }

    void M0zpstti30f4 (int count) {
       var foo = "this is a string";
       var fred = new System.Collections.Generic.List { foo, foo.Length.ToString() };
       var z = fred.Count;
       var mmm = count + z + CsharpCompletion.PrivateStaticField1;
       var nnn = this.InstanceMethod1(mmm);
      }
  }
}

Весь экземпляр и статические участники типа доступен в скелетном коде. Это компилирует успешно. В той точке, определяя тип локального var просто через Отражение.

Что делает, это возможное:

• способность выполнить powershell в emacs
• компилятор C# действительно быстр. На моей машине требуется приблизительно 0,5 с для компиляции блока в оперативной памяти. Не достаточно быстро для анализа между нажатиями клавиш, но достаточно быстро поддерживать поколение по запросу списков завершения.

Я еще не изучил LINQ.
Это будет намного большей проблемой, потому что семантический лексический анализатор/синтаксический анализатор emacs имеет для C#, не "делает" LINQ.