注：本人做过静态代码分析，也算是做过code intelligence，两者互有交叉，所以这里将涉及到的有意思的东西记录下来，未来有精力再依次对这些项目进行介绍

文章目录

  • 什么是language server protocol
    • JSONRPC
  • LSIF（Language Server Index Format）
  • SARIF（Static Analysis Results Interchange Format）
  • SASP（Static Analysis Server Protocol）
  • Semmle QL
  • Babelfish（*注：source{d}已经凉凉，网址已然打不开了*）
  • Semantic
    • [How we parse source code into ASTs](https://github.com/github/semantic/blob/master/docs/why-tree-sitter.md)
  • Kythe
  • tree-sitter
    • parser相关补充
      • LL（Left-to-right, Leftmost derivation）
      • LR（Left-to-right, Rightmost derivation in reverse）
  • Glean
  • [Responsive compilers](https://www.youtube.com/watch?v=N6b44kMS6OM)
  • 总结
  • 未来待学习

什么是language server protocol

注：这里复述我之前的总结

LSP(Language Server Protocol)是微软在开发visual studio code中针对Language Server设计的一种协议，关于设计中的抉择，在文章《Language Server Extension Guide》有详细介绍。

下面我粘贴了这篇文章中的一些描述，采用Language Server的原因主要分为如下三点：

  • 不同语言的language server在实现时，通常采用它们自身的语言，例如C++的language server Clangd就是C++实现的。而VSCode只自带了Node.JS的运行时。
  • language server通常是资源密集型的，一言不合就要重新编译整个源码文件，所以就有将langauge server运行放在远端的需求
  • 最后从 M(编辑器) * N(language server实现) 转化成了 M(编辑器) + N(language server实现)

注：由于language server的是编译器的子集，简单的例如符号跳转，diagnostics等功能，编译前端就可以实现，但是另外的一些功能，例如analysis，则需要编译器偏后端的部分实现。由于编译器通常是native programming language实现的，所以language server的实现也会基于现有的编译器实现

First, Language Servers are usually implemented in their native programming languages, and that presents a challenge in integrating them with VS Code which has a Node.js runtime.

Additionally, language features can be resource intensive. For example, to correctly validate a file, Language Server needs to parse a large amount of files, build up Abstract Syntax Trees for them and perform static program analysis. Those operations could incur significant CPU and memory usage and we need to ensure that VS Code’s performance remains unaffected.

Finally, integrating multiple language toolings with multiple code editors could involve significant effort. From language toolings’ perspective, they need to adapt to code editors with different APIs. From code editors’ perspective, they cannot expect any uniform API from language toolings. This makes implementing language support for M languages in N code editors the work of M * N.

个人认为 language server protocol 或者类似的概念在云时代会越来越重要，未来的程序员的开发会越来越摆脱本地的限制，从开发到部署都会在云上实现，这是不可扭转的趋势，而 language server protocol 或者类似的概念会在其中扮演越来越重要的作用。

JSONRPC

注：这里复述我之前的总结

由于LSP是基于JSONRPC2实现的，所以JSONRPC的概念是language server中非常重要的一环。由于自己不是后端工程师，对网络不是很熟，所以这里没有什么经验可谈。只是知道了remote procedure call这种抽象后，自己以前对什么是程序以及程序的执行理解的太肤浅了（这就是学习没有举一反三的原因，没有抽象出本质，caller和callee只是一种约定，完成约定就行，即使不同编程语言也OK）

RPC的核心就是以下三点：

  • Call ID的映射，如何唯一确定callee的ID
  • 序列化和反序列化，由于参数等信息不是通过栈（或者本机内存）传递，所以就需要转换到传输介质（例如网络）所要求的格式进行传递
  • 网络传输，RPC中的R-remote决定了procedure call需要跨越网络

注：知乎用户用心阁的回答和文章Remote Procedure Calls对我的帮助比较大。

LSIF（Language Server Index Format）

LSIF是一种描述程序信息的格式，目前主要用于code intelligence的领域，例如Code intelligence with LSIF 和 Rich code navigation。

The purpose of the Language Index Format (LSIF) is it to define a standard format for language servers or other programming tools to dump their knowledge about a workspace. This dump can later be used to answer language server LSP requests for the same workspace without running the language server itself. - Language Server Index Format

LSIF确定了从程序中提取出来的程序信息的格式，这个所谓的格式有很多：