Format and simplify intergration test (#245)

docs/zh/design/architecture.md

@@ -26,4 +26,4 @@ clice 是一个语言服务器，首先是一个服务器。它使用 [libuv](ht
 
 ## Support
 
-一些其它的工具库。
+一些其它的工具库。

docs/zh/design/compilation.md

@@ -18,5 +18,3 @@ int main () {
 
 
 ## Cancel Compilation
-
-

docs/zh/design/header-context.md

@@ -28,7 +28,7 @@ struct Y { ... };
 
 ```cpp
 // a.h
-struct Y { 
+struct Y {
     X x;
 };
 
@@ -39,4 +39,4 @@ struct X {};
 
 `a.h`自身不能被编译，但是嵌入到`b.cpp`中的时候就编译正常了。这种情况下 clangd 会在`a.h`中报错，找不到`X`的定义。显然这是因为它把`a.h`当成一个独立的源文件了。在 libstdc++ 中的代码中就有很多这样的头文件，现在流行的一些 C++ 的 header-only 的库也有些有这样的代码，clangd 目前无法处理它们。
 
-clice 将会支持**头文件上下文 (header context)**，支持自动和用户主动切换头文件的状态，当然也会支持非自包含的头文件。我们想要实现如下的效果，以最开始那份代码为例。当你从`b.cpp`跳转到`a.h`的时候使用`b.cpp`作为`a.h`的上下文。同理，当你从`c.cpp`跳转到`a.h`的时候则使用`c.cpp`作为`a.h`的上下文。
+clice 将会支持**头文件上下文 (header context)**，支持自动和用户主动切换头文件的状态，当然也会支持非自包含的头文件。我们想要实现如下的效果，以最开始那份代码为例。当你从`b.cpp`跳转到`a.h`的时候使用`b.cpp`作为`a.h`的上下文。同理，当你从`c.cpp`跳转到`a.h`的时候则使用`c.cpp`作为`a.h`的上下文。

docs/zh/design/index.md

@@ -1,2 +1 @@
 # Index
-

docs/zh/design/template-resolver.md

@@ -29,4 +29,4 @@ void foo(std::vector<std::vector<T>> vec2) {
 3. 不考虑默认模板参数，无法处理由默认模板参数导致的依赖名
 
 
-尽管我们可以对标准库的类型开洞来提供相关的支持，但是我希望用户的代码能和标准库的代码有相同的地位，那么我们就需要一种通用的算法来处理依赖类型。为了解决这个问题，我编写了一个伪实例化器（pseudo instantiator）。它能在没有具体类型的前提下对依赖类型进行实例化，从而达到化简的目的。比如上面这个例子里面的`std::vector<std::vector<T>>::reference`就能被化简为`std::vector<T>&`，进一步就能为用户提供代码补全选项。
+尽管我们可以对标准库的类型开洞来提供相关的支持，但是我希望用户的代码能和标准库的代码有相同的地位，那么我们就需要一种通用的算法来处理依赖类型。为了解决这个问题，我编写了一个伪实例化器（pseudo instantiator）。它能在没有具体类型的前提下对依赖类型进行实例化，从而达到化简的目的。比如上面这个例子里面的`std::vector<std::vector<T>>::reference`就能被化简为`std::vector<T>&`，进一步就能为用户提供代码补全选项。

docs/zh/dev/build.md

@@ -15,9 +15,9 @@
 - clang >= 19
 - c++23 compitable standard library
   - MSVC STL >= 19.44(VS 2022 17.4)
-  - GCC libstdc++ >= 14 
+  - GCC libstdc++ >= 14
   - Clang libc++ >= 20
-  
+
 clice 使用 C++23 作为语言标准 ，请确保有可用的 clang 19 以及以上的编译器，以及兼容 C++23 的标准库。
 
 > clice 暂时只能使用 clang 编译，在未来我们会改进这一点，使其能使用 gcc 和 msvc 编译。
@@ -31,7 +31,7 @@ clice 使用 C++23 作为语言标准 ，请确保有可用的 clang 19 以及
 如果你能找到系统的 llvm package 对应的 llvm commit，将该 commit 下的如下三个文件
 
 - `clang/lib/Sema/CoroutineStmtBuilder.h`
-- `clang/lib/Sema/TypeLocBuilder.h` 
+- `clang/lib/Sema/TypeLocBuilder.h`
 - `clang/lib/Sema/TreeTransform.h`
 
 拷贝到 `LLVM_INSTALL_PATH/include/clang/Sema/` 中即可。
@@ -59,7 +59,7 @@ $ 7z x x64-windows-msvc-release.7z "-o.llvm"
 > [!IMPORTANT]
 >
 > 对于 debug 版本的 llvm libs，构建的时候我们开启了 address sanitizer，而 address sanitizer 依赖于 compiler rt，它对编译器版本十分敏感。所以如果使用 debug 版本，请确保你的 clang 的 compiler rt 版本和我们构建的时候**严格一致**。
-> 
+>
 > - Windows 暂时无 debug 构建的 llvm libs，因为它不支持将 clang 构建为动态库，相关的进展可以在 [这里](https://discourse.llvm.org/t/llvm-is-buildable-as-a-windows-dll/87748) 找到
 > - Linux 使用 clang20
 > - MacOS 使用 homebrew llvm@20，一定不要使用 apple clang

docs/zh/dev/contribution.md

@@ -8,4 +8,4 @@
 
 命名
 - 变量名：小写下换线
-- 类名，枚举名：大驼峰
+- 类名，枚举名：大驼峰

docs/zh/guide/configuration.md

@@ -18,9 +18,9 @@
 - `*`: 匹配路径段中的一个或多个字符。
 - `?`: 匹配路径段中的单个字符。
 - `**`: 匹配任意数量的路径段，包括零个。
-- `{}`: 用于分组条件 (例如, `**/*.{ts,js}` 匹配所有 TypeScript 和 JavaScript 文件)。
-- `[]`: 声明要匹配的路径段中的字符范围 (例如, `example.[0-9]` 匹配 `example.0`, `example.1` 等)。
-- `[!...]`: 排除要匹配的路径段中的字符范围 (例如, `example.[!0-9]` 匹配 `example.a`, `example.b`，但不匹配 `example.0`)。
+- `{}`: 用于分组条件 (例如，`**/*.{ts,js}` 匹配所有 TypeScript 和 JavaScript 文件)。
+- `[]`: 声明要匹配的路径段中的字符范围 (例如，`example.[0-9]` 匹配 `example.0`, `example.1` 等)。
+- `[!...]`: 排除要匹配的路径段中的字符范围 (例如，`example.[!0-9]` 匹配 `example.a`, `example.b`，但不匹配 `example.0`)。
 <br>
 
 | 名称             | 类型                | 默认值 |
@@ -89,4 +89,4 @@
 用于储存索引文件的文件夹。
 <br>
 
-## Feature
+## Feature

docs/zh/guide/quick-start.md

@@ -65,4 +65,4 @@ TODO:
 
 ### Others
 
-对于任意其它的构建系统，可以尝试使用 [bear](https://github.com/rizsotto/Bear) 或者 [scan-build](https://github.com/rizsotto/scan-build) 来拦截编译命令并获取到编译数据库（不保证成功）。我们计划在未来编写一个**新的工具**，通过假编译器的方式来实现编译命令的捕获。
+对于任意其它的构建系统，可以尝试使用 [bear](https://github.com/rizsotto/Bear) 或者 [scan-build](https://github.com/rizsotto/scan-build) 来拦截编译命令并获取到编译数据库（不保证成功）。我们计划在未来编写一个**新的工具**，通过假编译器的方式来实现编译命令的捕获。

docs/zh/guide/what-is-clice.md

@@ -20,4 +20,4 @@ clice 是一个全新的 C++ 的语言服务器，旨在解决现存 C++ 语言
 
 既然如此，那么像为 clangd [初步支持 C++20 module](https://github.com/llvm/llvm-project/pull/66462) 这样的大型 PR 被拖了将近一年也就不奇怪了。意识到这个现状之后，我萌生了自己编写一个语言服务器的想法。我估计了一下项目大小，去除测试代码，大概 2w 行就能完成，是一个人花一段时间能完成的工作量，而且也有先例，例如 ccls 和 rust analyzer。另外一点就是 clangd 的代码已经上了年代了，尽管有非常多的注释，但是相关的逻辑仍然很绕，进行大范围修改所花费的时间可能还不如重写来得快。
 
-于是说干就干，我对 clangd 的几百个 issue 进行了分类，看看有没有一些问题是因为 clangd 一开始的架构设计错误而导致很难解决，然后被搁置的。如果有的话，是否能在重新设计的时候就考虑这个问题来解决呢？我发现，确实有一些！于是接下来的时间里，我花了大概两个月的时间来学习研究 clang 里面相关的机制，摸索相关问题的解决方法，探索原型实现，在确定相关的问题基本都可以解决之后，正式开始了 clice 的开发。
+于是说干就干，我对 clangd 的几百个 issue 进行了分类，看看有没有一些问题是因为 clangd 一开始的架构设计错误而导致很难解决，然后被搁置的。如果有的话，是否能在重新设计的时候就考虑这个问题来解决呢？我发现，确实有一些！于是接下来的时间里，我花了大概两个月的时间来学习研究 clang 里面相关的机制，摸索相关问题的解决方法，探索原型实现，在确定相关的问题基本都可以解决之后，正式开始了 clice 的开发。

docs/zh/index.md

@@ -32,4 +32,4 @@ features:
   - icon: I
     title: 内存占用更低，速度更快
     details: 优秀的异步任务调度，支持编译任务取消，缓存必要的信息，避免无意义的 CPU 浪费
----
+---