最大的缺失部分正在连接到管道中,否则你不会比.Emit
提供的更进一步。不要误会,Roslyn 带来了很多很棒的东西,但是对于我们这些想要实现预处理器和元编程的人来说,现在似乎还没有考虑到这一点。您可以实现“代码建议”或他们所谓的“问题”/“操作”作为扩展,但这基本上是代码的一次性转换,充当建议的内联替换,而不是您实现新语言的方式特征。这是您始终可以使用扩展完成的事情,但 Roslyn 使代码分析/转换变得非常容易:
从我在 codeplex 论坛上看到 Roslyn 开发人员的评论来看,在管道中提供挂钩并不是最初的目标。他们在 C# 6 预览版中提供的所有新 C# 语言功能都涉及修改 Roslyn 本身。所以你基本上需要分叉 Roslyn。他们有关于如何构建 Roslyn 并使用 Visual Studio 对其进行测试的文档。这将是分叉 Roslyn 并让 Visual Studio 使用它的一种严厉方式。我说强硬是因为现在任何想要使用你的新语言特性的人都必须用你的替换默认编译器。你可以看到这会开始变得混乱。
构建 Roslyn 并用您自己的构建替换 Visual Studio 2015 Preview 的编译器
另一种方法是构建一个充当 Roslyn 代理的编译器。有用于构建 VS 可以利用的编译器的标准 API。不过,这不是一项微不足道的任务。您将阅读代码文件,调用 Roslyn API 来转换语法树并发出结果。
代理方法的另一个挑战是让智能感知与您实现的任何新语言功能完美配合。您可能必须拥有 C# 的“新”变体,使用不同的文件扩展名,并实现 Visual Studio 所需的所有 API 才能使智能感知正常工作。
最后,考虑 C# 生态系统,以及可扩展编译器的含义。假设 Roslyn 确实支持这些钩子,就像提供 Nuget 包或 VS 扩展来支持新的语言功能一样简单。所有利用新的 Do-Until 功能的 C# 本质上都是无效的 C#,并且在不使用自定义扩展的情况下将无法编译。如果你在这条路上走得足够远,有足够多的人实现新特性,很快你就会发现不兼容的语言特性。也许有人实现了预处理器宏语法,但它不能与其他人的新语法一起使用,因为他们碰巧使用类似的语法来描述宏的开头。如果您利用了很多开源项目并发现自己正在深入研究他们的代码,你会遇到很多奇怪的语法,这些语法需要你跟踪并研究项目正在利用的特定语言扩展。它可能是疯了。我并不是要听起来像一个反对者,因为我对语言特性有很多想法并且对此非常感兴趣,但是人们应该考虑它的含义以及它的可维护性。想象一下,如果你被雇用到某个地方工作,他们已经实现了你必须学习的各种新语法,并且如果没有像 C# 的特性一样对这些特性进行审查,你可以打赌其中一些不会很好地设计/实现.