整理一下现在的核心实现，为泛型做准备

[sumneko]

目前的核心分为3个主要部分：

1. 语法解析：将Lua字符串解析为语法树，并捕获所有的语法错误（指当前Lua版本会导致无法编译的错误）。另外也会编译注解和注释，并将注解和注释与受影响的语法树节点绑定在一起。语法数会在当前文件内容发生变化时丢弃，下次获取语法树时重新编译。
2. 语义节点：在语法树节点上绑定语义节点，语义节点中会保存当前节点在当前状态下的语义，例如它的类型。所有文件的语义会集中在一起，当状态发生变化时全部丢弃。状态发生变化指的是工作区中的任意文件发生变化，因为后台的一个文件如果修改了全局变量，那么当前文件的语义也可能会跟着变化，因此需要全部丢弃。
3. 搜索器：根据需求，以最小路径递归计算某个节点的语义。语义分析开销巨大，而为了自动补全等操作的体验降低延迟，不能对整个语法树从上而下的标记语义，而是按照请求的目标向前递归，只计算递归路径上的语义。

[sumneko]

语法解析
这个功能目前比较稳定，是通过 Lpeg 分词后，手写了递归下降的解析器。之所以手写递归下降解析处于以下原因：

1. 如果直接使用Lpeg解析，很容易遭遇到堆栈溢出的问题，比如 此文件 。手写解析后，因为Lua动态分配栈空间，因此可以轻易支持。
2. 可以提升性能。乍一听感觉用Lua手动解析理论上速度应该更慢才对，但实际上经过测试发现，对于一个已经分词完毕的文件，最大的开销出在创建Lua表上，这点就算纯 Lpeg 也无法避免。而手动解析可以解决很多回溯问题，尤其是表达式的优先级解析，现在可以完全从左往右一次性解析出复杂表达式的优先级顺序，而之前用 Lpeg 时需要不停的回退测试。
3. 可以精细控制错误。解析器的功能之一是收集出所有的语法错误。如果是运行时的编译器，只需要在遇到第一个错误后停止解析即可，但是语言服务使用的解析器需要尽可能的忽略并收集错误，并继续向后解析。这里遇到的问题就是错误恢复，如果用 Lpeg 解析需要大量的错误测试节点来处理错误，写起来还是挺难的，手动解析会简单很多。另一方面此解析器需要根据版本号和上下文语法决定 goto 到底是名字还是关键字，这个用Lpeg感觉也挺难写的。
4. 调试简单。Lpeg复杂了以后，调试还挺麻烦的，毕竟他的匹配过程不透明，需要不停的添加测试节点来调试。纯手写的话，在关键的地方断个点就知道哪里解析错了。

[brynne8]

关于LPeg调试的问题，有一个非常好用的工具PegDebug，可以用一下。我遇到怎么看也看不出问题的LPeg语法就用这个。

[brynne8]

另外，LPeg的匹配过程不透明的问题，也可以通过编译flag来解决。把makefile里面的COPT = -O0 -DLPEG_DEBUG -DDEBUG -g打开，就会在匹配的过程中输出大量的信息。而且只要开启LPEG_DEBUG这个宏，就可以输出pattern的树结构（p:ptree()）以及生成的LPeg VM的code（p:pcode()）。

[sumneko]

调试困难并不是主要的阻碍，毕竟之前已经实现过完整的LPeg语法解析了。主要还是1和3没有办法解决。

[brynne8]

关于第1点，LPeg确实比较容易遇到stack限制的问题，所以在可预见到会用到比较多的栈空间的时候，手动setmaxstack是一种选择。值得一提的是，LPeg本身其实实现了最简单一种情况的尾调用优化，例如

S <- E1 / E2 S

这样的情况，rule最后的S是不会创建stack frame的。不过也许在实际情况下不容易做到写成上面这样，毕竟如果增加一个捕获，或者最后一个S不是S，而是S?可选pattern的话，那么这个优化将会立即失效。

---

第3点确实不太好办。有时候手动写代码确实自己的掌控要多一些。我看到你已经用到了Sérgio Medeiros的lpeglabel，但我没用过这个，不知道好不好用。

[sumneko]

手动 setmaxstack 会被宿主的栈空间限制。我目前使用的宿主最大栈深度可以设置到1000左右，但是依然不够我这个例子里用的。

[sumneko]

语义节点
这个大体就是一个数组，里面保存了该节点所有的来源。例如以下代码：

local x = 1

print(x)

这里的2个 x 会共享同一个语义节点，里面保存了：

1. 局部变量对象 x
2. 声明 x 的语法树节点
3. 整数 1 的语法树节点

业务层只需要访问此语义节点，就可以完成查询定义、类型推断等功能。

这个功能可以解决大部分问题，但是有几个地方却比较难用：

1. alias 的类型擦除

---@alias MyType string|number

---@type MyType
local x

这里的局部变量 x 会保存3个语义来源：type:MyType, type:string, type:number。
如果不做任何处理，那么用户在查看此对象时就会显示联合类型 MyType|string|number 。因此在显示时需要重新检查一遍所有的类型，如果是 alias ，则需要擦除 string 与 number 。

2. class 的 overload

---@overload fun(x: number, y: number): point
---@class point
Point = {}

local p = Point(x, y)

这里的全局变量 Point 会保存2个语义来源：const:fun(x: number, y: number): point, type:point。和前面一样，在显示时需要过滤掉 const:fun 。

3. 难以兼容泛型类

---@class table<K, V>: { [K]: V }

---@type table<number, string>
local t1

---@type table<number, string>
local t2

t1 = t2

最下面的赋值操作会进行一次类型检查，局部变量 t1 与 t2 的语义节点均包含 type:table<number, string> 与 const:{ [number]: string }。目前在检查类型时会无视掉 type:table<number, string>，只对比 const:{ [number]: string }，因此可以检查出类型是否一致。
但以后要支持泛型类型的话，代码可能是这样的：

---@class map<K>
---@field [K]: true

---@type map<number>
local t1

---@type map<string>
local t2

t1 = t2

由于对比时会无视 type:map<number>，而又没有 const 提供，因此会认为2者均为 unknown，无法检查出类型错误。

4. 拷贝开销过高

---@alias ManyInts 1 | 2 | 3 | 4 ... | 255

在这种情况下，展开所有的语义来源后，语义节点的长度会变成两百多，每次拷贝、派生新的语义节点时都要全部复制过去，浪费性能

5. 无法支持递归

---@alias JValue boolean | number | integer | JArray | JObject
---@alias JArray JValue[]
---@alias JObject { [string]: JValue }

在这种类型递归的情况下，需要在很多地方加判断方式递归过深。

6. 类型继承关系较难处理

---@class A
---@class B: A

---@class C
---@operator add(B): 'B'
---@operator add(A): 'A'

---@type C
local c

---@type b
local b

local s = c + b

由于 b 的语义节点上同时存在类型 B 与 A，因此这个加法重载会被解析为 'B'|'A' ，但我们期望的是 'B'。

[sumneko]

目前的主要想法是拆散语义节点，将 变量对象，常量值 和 类型 都保存到不同的对偶表中。

• 对偶表均为弱表，这是否会加重GC的负担？ 先不用弱表了，用弱表本意是节约内存，但是修改结构后大部分对象是同一个引用，天生会比现在更加节约内存。
• 需要使用其中一张表来确定这个语法节点是否已经被语义检查过，目前打算用 类型 表来确定，这意味着所有的节点至少要有一个显性的 unknown 类型？否则需要用一张额外的表来标记。 给语法节点中注入一个语义版本号字段来做标记。类型信息依然使用对偶表而不是保存在语法节点内，因为语义信息需要做统一擦除，避免引用旧的语义信息而导致内存膨胀。

类型不再在内部展开。顺便会将 expandAlias 设置默认改为 false 。

类型不再默认为联合类型，而是添加一个 union 的类来保存联合类型。

可选类型（如 number?） 在类型系统中直接表示为 number|nil。

[sumneko]

目前全局变量与类型都使用的同一个类，应该要拆开来，让类型是单独的类，全局变量作为变量对象的子类。