如何可靠地确定在设计时使用 var 声明的变量的类型？

Question

我正在 emacs 中为 C# 开发一个完成（智能感知）工具。

这个想法是，如果用户键入一个片段，然后要求通过特定的击键组合完成，则完成工具将使用 .NET 反射来确定可能的完成。

这样做需要知道正在完成的事情的类型。如果它是一个字符串，则有一组已知的可能的方法和属性；如果它是 Int32，则它有一个单独的集合，依此类推。

使用语义（emacs 中提供的代码词法分析器/解析器包），我可以找到变量声明及其类型。鉴于此，使用反射来获取类型的方法和属性，然后向用户呈现选项列表是很简单的。 （好吧，在 emacs 中执行起来不太简单，但是使用 在 emacs 中运行 powershell 进程的能力，它变得更加容易。我编写了一个自定义的 .NET 程序集来进行反射，将其加载到powershell中，然后emacs中运行的elisp可以通过comint向powershell发送命令并读取响应，因此emacs可以快速获得反射的结果。）

当代码使用var 在正在完成的事情的声明中。这意味着未明确指定类型，并且完成将不起作用。

当使用 var 关键字声明变量时，如何可靠地确定所使用的实际类型？需要明确的是，我不需要在运行时确定它。我想在“设计时”确定它。

到目前为止我有这些想法：

1. 编译和调用：
   • 提取声明语句，例如 `var foo = "a string value";`
   • 连接语句 `foo.GetType();`
   • 将生成的 C# 片段动态编译为新程序集
   • 将程序集加载到新的 AppDomain 中，运行框架并获取返回类型。
   • 卸载并丢弃组件

   我知道如何做到这一切。但对于编辑器中的每个完成请求来说，这听起来非常重量级。

   我想我不需要每次都需要一个全新的 AppDomain。我可以将单个 AppDomain 重新用于多个临时程序集，并分摊设置它的成本 跨多个完成请求将其向上和向下拆卸。这更多的是对基本想法的调整。

2. 编译并检查 IL

   只需将声明编译到模块中，然后检查 IL，以确定编译器推断的实际类型。这怎么可能呢？我将使用什么来检查 IL？

还有更好的想法吗？评论？建议？

---

编辑 - 进一步考虑这一点，编译和调用是不可接受的，因为调用可能会产生副作用。所以第一个选项必须排除。

另外，我认为我不能假设 .NET 4.0 的存在。

---

更新 - 正确的答案，上面没有提到，但埃里克·利珀特温和地指出，是实现一个完全保真类型的推理系统。这是在设计时可靠地确定 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.? 

引擎在生成的源代码中添加适当的using子句，使其能够正确编译，然后IL检查也是一样的。

这也有效：

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

它只是意味着 IL 检查必须找到第三个局部变量的类型，而不是第一个。

这是：

var foo = "Tra la la";
var fred = new System.Collections.Generic.List<String>
    {
        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<String>
        {
            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<String> { foo, foo.Length.ToString() };
       var z = fred.Count;
       var mmm = count + z + CsharpCompletion.PrivateStaticField1;
       var nnn = this.InstanceMethod1(mmm);
      }
  }
}

所有实例和静态类型成员都可以在骨架代码。它编译成功。此时，通过反射确定局部变量的类型就很简单了。

使这一切成为可能的是：

• 在 emacs 中运行 powershell
• C# 编译器的速度非常快。在我的机器上，编译一个内存中的程序集大约需要 0.5 秒。对于击键之间的分析来说不够快，但足以支持按需生成完成列表。

我还没有研究过 LINQ。
这将是一个更大的问题，因为 emacs 的语义词法分析器/解析器适用于 C#，不能“执行”LINQ。

Answer 1

我可以为您描述我们如何在“真正的”C# IDE 中高效地做到这一点。

我们要做的第一件事是运行一个过程，仅分析源代码中的“顶级”内容。我们跳过所有方法体。这使我们能够快速建立一个数据库，其中包含有关程序源代码中的名称空间、类型和方法（以及构造函数等）的信息。如果您尝试在击键之间进行分析，则分析每个方法主体中的每一行代码将花费太长时间。

当 IDE 需要计算方法体内特定表达式的类型时，假设您输入了“foo”。我们需要弄清楚 foo 的成员是什么——我们做同样的事情；我们会尽可能多地跳过工作。

我们从一个仅分析该方法中的局部变量声明的过程开始。当我们运行该过程时，我们会从一对“范围”和“名称”到“类型确定器”进行映射。 “类型确定器”是一个对象，表示“如果需要，我可以计算出此本地的类型”的概念。确定当地人的类型可能会很昂贵，因此如果需要的话我们希望推迟这项工作。

我们现在有了一个延迟构建的数据库，可以告诉我们每个本地的类型。那么，回到那个“foo”。 -- 我们找出相关表达式所在的语句，然后针对该语句运行语义分析器。例如，假设您有方法主体：

String x = "hello";
var y = x.ToCharArray();
var z = from foo in y where foo.

现在我们需要计算出 foo 的类型为 char。我们构建一个包含所有元数据、扩展方法、源代码类型等的数据库。我们构建一个包含 x、y 和 z 类型确定符的数据库。我们分析包含有趣表达式的语句。我们首先将其语法转换为：

var z = y.Where(foo=>foo.

为了计算出 foo 的类型，我们必须首先知道 y 的类型。那么此时我们问类型确定器“y 的类型是什么”？然后它启动一个表达式求值器，解析 x.ToCharArray() 并询问“x 的类型是什么”？我们有一个类型确定器，它表示“我需要在当前上下文中查找“String””。当前类型中没有String类型，所以我们在命名空间中查找。它也不存在，所以我们查看 using 指令，发现有一个“using System”，并且 System 具有 String 类型。好的，这就是 x 的类型。

然后，我们在 System.String 的元数据中查询 ToCharArray 的类型，它表明它是一个 System.Char[]。极好的。所以我们有一个 y 的类型。

现在我们问“System.Char[] 有一个方法在哪里吗？”不。所以我们查看 using 指令；我们已经预先计算了一个数据库，其中包含可能使用的扩展方法的所有元数据。

现在我们说“好吧，有十八打扩展方法，名为Where in range，它们中的任何一个都有第一个形式参数，其类型与System.Char[]兼容吗？”因此我们开始了一轮可兑换性测试。然而，Where 扩展方法是通用的，这意味着我们必须进行类型推断。

我编写了一个特殊的类型推理引擎，可以处理从第一个参数到扩展方法的不完整推理。我们运行类型推断器，发现有一个Where方法接受IEnumerable，并且我们可以从System.Char[]到IEnumerable进行推断;，所以 T 是 System.Char。

该方法的签名是 Where(this IEnumerableitems, Funcpredicate)，我们知道 T 是 System.Char。我们还知道扩展方法括号内的第一个参数是 lambda。因此，我们启动一个 lambda 表达式类型推断器，表示“形式参数 foo 假定为 System.Char”，在分析 lambda 的其余部分时使用这一事实。

我们现在拥有分析 lambda 主体所需的所有信息，即“foo.”。我们查找 foo 的类型，根据 lambda 绑定器发现它是 System.Char，我们就完成了；我们显示 System.Char 的类型信息。

除了击键之间的“顶级”分析之外，我们会做所有事情。这才是真正棘手的地方。实际上写出所有的分析并不难；它使它足够快，以便您可以以打字速度完成操作，这是真正棘手的一点。

Answer 2

我可以大致告诉你Delphi IDE如何与Delphi编译器一起工作来进行智能感知（Delphi称之为代码洞察）。它并不 100% 适用于 C#，但它是一种值得考虑的有趣方法。

Delphi 中的大多数语义分析都是在解析器本身中完成的。表达式在解析时被键入，除非这并不容易的情况 - 在这种情况下，使用前瞻解析来计算出想要的内容，然后在解析中使用该决策。

解析主要是 LL(2) 递归下降，但表达式除外，表达式是使用运算符优先级进行解析的。 Delphi 的一个独特之处在于它是一种单遍语言，因此需要在使用之前声明构造，因此不需要顶级传递来带出该信息。

这种功能组合意味着解析器几乎拥有任何需要的地方的代码洞察所需的所有信息。它的工作方式是这样的：IDE 通知编译器的词法分析器光标的位置（需要代码洞察的点），词法分析器将其转换为特殊标记（称为 kibitz 标记）。每当解析器遇到这个标记（可能在任何地方）时，它就知道这是将其拥有的所有信息发送回编辑器的信号。它使用 longjmp 来完成此操作，因为它是用 C 编写的；它的作用是通知最终调用者基比兹点所在的语法结构（即语法上下文）类型，以及该点所需的所有符号表。例如，如果上下文位于作为方法参数的表达式中，我们可以检查方法重载，查看参数类型，并将有效符号过滤为仅那些可以解析为该参数类型的符号（此减少了下拉菜单中许多不相关的内容）。如果它位于嵌套作用域上下文中（例如，在“.”之后），则解析器将返回对该作用域的引用，并且 IDE 可以枚举在该作用域中找到的所有符号。

其他的事情也都做了；例如，如果 kibitz 标记不在其范围内，则方法体将被跳过 - 这是乐观地完成的，如果跳过标记则回滚。扩展方法的等价物——Delphi 中的类帮助器——有一种版本化缓存，因此它们的查找速度相当快。但Delphi 的泛型类型推断比C# 弱得多。

现在，具体问题是：推断用 var 声明的变量的类型相当于 Pascal 推断常量类型的方式。它来自初始化表达式的类型。这些类型是自下而上构建的。如果 x 的类型为 Integer，并且 y 的类型为 Double，则 x + y< /code> 将是 Double 类型，因为这些是语言的规则；等等。您遵循这些规则，直到您拥有右侧完整表达式的类型，这就是您用于左侧符号的类型。

Answer 3

如果您不想编写自己的解析器来构建抽象语法树，您可以考虑使用 SharpDevelop 或 MonoDevelop，两者都是开源的。

Answer 4

智能感知系统通常使用抽象语法树来表示代码，这使得它们能够以与编译器大致相同的方式解析分配给“var”变量的函数的返回类型。如果您使用 VS Intellisense，您可能会注意到，在您完成输入有效（可解析）的赋值表达式之前，它不会为您提供 var 的类型。如果表达式仍然不明确（例如，它无法完全推断表达式的通用参数），则 var 类型将无法解析。这可能是一个相当复杂的过程，因为您可能需要深入树才能解析类型。例如：

var items = myList.OfType<Foo>().Select(foo => foo.Bar);

返回类型是 IEnumerable，但解决这个问题需要知道：

1. myList 是实现 IEnumerable 的类型。
2. 有一个适用于 IEnumerable 的扩展方法 OfType。
3. 结果值为 IEnumerable 并且有一个适用于此的扩展方法 Select。
4. lambda 表达式 foo =>; foo.Bar 具有 Foo 类型的参数 foo。这是通过使用 Select 来推断的，它采用 Func 并且由于 TIn 已知 (Foo)，因此可以推断 foo 的类型。
5. 类型 Foo 有一个属性 Bar，其类型为 Bar。我们知道 Select 返回 IEnumerable，并且 TOut 可以从 lambda 表达式的结果推断出来，因此结果项的类型必须是 IEnumerable。

Answer 5

由于您的目标是 Emacs，因此最好从 CEDET 套件开始。 Eric Lippert 的所有细节都已经在 C++ 的 CEDET/Semantic 工具的代码分析器中涵盖了。还有一个 C# 解析器（可能需要一点 TLC），因此唯一缺少的部分与调整 C# 的必要部分有关。

基本行为在核心算法中定义，这些算法依赖于基于每种语言定义的可重载函数。完成引擎的成功取决于已完成的调整程度。以 C++ 为指导，获得类似于 C++ 的支持应该不会太糟糕。

大牛的回答建议使用MonoDevelop来做解析分析。这可能是替代现有 C# 解析器的机制，或者它可以用于增强现有解析器。

Answer 6

这是一个很难做好的问题。基本上，您需要通过大部分词法分析/解析/类型检查来对语言规范/编译器进行建模，并构建源代码的内部模型，然后您可以查询该模型。 Eric 为 C# 详细描述了它。您始终可以下载 F# 编译器源代码（F# CTP 的一部分）并查看 service.fsi 以查看 F# 编译器公开的接口，F# 语言服务使用该接口来提供智能感知、推断类型的工具提示等。如果您已经将编译器作为 API 调用，那么它会给您一种可能的“接口”的感觉。

另一种途径是按照您所描述的那样按原样重新使用编译器，然后使用反射或查看生成的代码。从您需要“完整程序”才能从编译器获取编译输出的角度来看，这是有问题的，而在编辑器中编辑源代码时，您通常只有尚未解析的“部分程序”，不要是否已实现所有方法等等。

总之，我认为“低预算”版本很难做好，而“真实”版本则非常非常难做好。 （这里的“困难”既衡量“努力”又衡量“技术难度”。）

Answer 7

NRefactory 将为您完成此操作。

Answer 8

对于解决方案“1”，.NET 4 中有一个新工具可以快速轻松地完成此操作。
因此，如果您可以将您的程序转换为 .NET 4，那将是您的最佳选择。