Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions en/clice/design/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ See [Dependency Scanning](dependency-scanning.md).

Semantic analysis capabilities beyond Clang's native APIs, over the AST of a compilation unit.

- `Semantics`: The unified semantic map — a single AST traversal per compilation records every interesting node and its token ownership; selection, feature projections, and index production are pure queries over the map rather than separate AST walks
- `Semantics`: The unified semantic map — a single AST traversal per compilation records every interesting node and its token ownership; selection, features, and index production are pure queries over the map rather than separate AST walks
- `EntityTable`: The identity of a declaration, equal across translation units for the declarations the compiler would merge
- `TemplateResolver`: Resolves dependent names through pseudo-instantiation, enabling semantic analysis to see through template contexts. See [Template Resolver](template-resolver.md).
- `SymbolKind` / `RelationKind`: Fine-grained symbol kinds and relation types
Expand Down Expand Up @@ -130,15 +130,15 @@ The language server's core runtime, responsible for assembling all the layers ab
**Document state** — Document state and the invalidation machinery.

- `Session` / `SessionStore`: The open-buffer truth for each open file — content, document version, generation, and serving state — created on didOpen and destroyed on didClose. Compile products do not live here
- `ASTProjection` / `ASTProjectionTable`: The published products of each document's most recent compilation (feature results, PCH key, dependency snapshot) — an immutable read model replaced wholesale on each publication
- `DocumentCompile` / `DocumentCompiles`: The published products of each document's most recent compilation (feature results, PCH key, dependency snapshot) — an immutable read model replaced wholesale on each publication
- `EditorContext`: The editor's side of command resolution — the user's context choices and the header contexts resolved for open files — layered over the project's `CommandResolver` for editor-facing compiles only
- `Invalidator`: The invalidation engine — folds file events (on-disk changes and removals, compilation-database reloads, worker crashes) into a deduplicated set of invalidation effects
- `FileTracker`: Stat-polling discovery of changes that happen outside the editor (a regenerated `compile_commands.json`, `git checkout`), feeding events to the `Invalidator`: the project's database watch plus a sweep, through the file table, of the files on disk and of the places a failed include lookup looked
- `Quarantine`: Per-document crash records — a kind of work that crashed a worker on a document pauses for that document until it changes (spaced and bounded) or is saved

**Services** — Read-side services consuming compilation and index results.

- `Features`: Assembles each feature's answer from its providers — the worker's AST, the PCH's cached preamble products, or the index — routing each request by readiness: an up-to-date AST answers when available, otherwise index-backed projections answer immediately. Under `readonly = on/auto`, documents serve exclusively from the index until an edit escalates them to full AST service; compilation is pull-based throughout, triggered by requests rather than lifecycle events
- `Features`: Assembles each feature's answer from its providers — the worker's AST, the PCH's cached preamble products, or the index — routing each request by readiness: an up-to-date AST answers when available, otherwise results computed from the index answer immediately. Under `readonly = on/auto`, documents serve exclusively from the index until an edit escalates them to full AST service; compilation is pull-based throughout, triggered by requests rather than lifecycle events
- `ASTFamily`: The document-AST node family in the task graph — schedules compiles for open documents and publishes their results
- `Dispatcher`: The document side of talking to workers — every request carrying an open document's content (stateful queries, interactive completion/signature builds, formatting) is admitted through the document's quarantine, dispatched, and landed through one exit that answers `ContentModified` for a buffer the client already edited away
- `IndexQuery`: Read-only queries over every index source — the project index, per-file shards, and the live data of open files — under one freshness arbitration, answering in domain values that the transports project onto their protocols
Expand Down
6 changes: 3 additions & 3 deletions en/clice/design/symbol-index.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ ProjectIndex Global directory: external symbols + which TUs contributed which
Shard Per-file variant storage (exact positions and relations), loaded on demand
Instantiations Per-file storage of what instantiations and macro expansions resolve
↑ overlay
Live index The open buffer's latest compile results, owned by its published projection
Live index The index of the open buffer's latest compile
```

**TUIndex** is the raw index data produced by compiling a translation unit, projected from the unified semantic map built during the compile. Since a compilation involves the focus file and all included headers, `TUIndex` internally maintains a separate set of entries per file. It also carries a symbol table and the include tree of this compilation: one node per entered file, naming the file, the node that included it and the line of the directive. The symbol table leaves out file-local symbols — a function's locals, a template's parameters — except the few that another file names, through an instantiation, a macro expansion, or a local class a function returns: the rest only their own file names, and that file's entries describe them. `TUIndex` is transient data, discarded after being merged into the persistent indexes.
Expand All @@ -80,7 +80,7 @@ Live index The open buffer's latest compile results, owned by its published

**Instantiations** of a file hold what the template instantiations and macro expansions of every indexed translation unit resolve in that file's text and its shard leaves open (see below). They live beside the shard, at its content generation.

An open file's **live index** comes from its most recent in-memory compilation and is owned by the document's published projection. It is never written to global state — it only overlays queries, so results reflect the buffer the user is actually editing.
An open file's **live index** comes from its most recent in-memory compilation and is owned by the document's latest compile. It is never written to global state — it only overlays queries, so results reflect the buffer the user is actually editing.

### Symbol Table Layering

Expand All @@ -90,7 +90,7 @@ Symbol metadata (name, kind) is looked up in layers: an open file's live data fi

### Index Construction

`TUIndex` construction is a projection over the unified semantic map: one AST traversal per compilation records every interesting node, and the index projection emits `Occurrence` and `Relation` entries per file. After projection, each file's entries are canonicalized — deduplicated and sorted (occurrences by position for binary search, relations by kind and position for filtering) — so that the encoded blob is deterministic.
`TUIndex` construction is a projection over the unified semantic map: one AST traversal per compilation records every interesting node, and the indexer emits `Occurrence` and `Relation` entries per file from it. After that, each file's entries are canonicalized — deduplicated and sorted (occurrences by position for binary search, relations by kind and position for filtering) — so that the encoded blob is deterministic.

During construction, the focus file's entries are kept separate from the headers'. This allows different treatment during merging — the focus file is merged as the translation unit's own contribution, while headers are merged as context variants.

Expand Down
6 changes: 3 additions & 3 deletions zh/clice/design/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -70,7 +70,7 @@ clice 是一个全新的 C++ 语言服务器,从架构层面重新设计,旨

提供 Clang 原生 API 之外、基于编译单元 AST 的语义分析能力。

- `Semantics`:统一语义映射——每次编译仅遍历一次 AST,记录所有相关节点及其 Token 归属;选择、功能投影和索引生成都是对该映射的纯查询,而无须分别遍历 AST
- `Semantics`:统一语义映射——每次编译仅遍历一次 AST,记录所有相关节点及其 Token 归属;选择、各项功能和索引生成都是对该映射的纯查询,而无须分别遍历 AST
- `EntityTable`:声明的标识;编译器会合并的声明,在不同翻译单元中得到相同的标识
- `TemplateResolver`:通过伪实例化解析依赖名,使语义分析能够透视模板上下文。详见 [模板解析器](template-resolver.md)。
- `SymbolKind` / `RelationKind`:细粒度的符号种类和关系类型
Expand Down Expand Up @@ -130,15 +130,15 @@ LSP 功能的具体实现。每个功能接收 `CompilationUnit`,返回对应
**文档状态** — 文档状态与失效机制。

- `Session` / `SessionStore`:记录每个打开文件的缓冲区权威状态——内容、文档版本、代次和服务状态——在 didOpen 时创建,在 didClose 时销毁。编译产物不存放在这里
- `ASTProjection` / `ASTProjectionTable`:每个文档最近一次编译所发布的产物(功能结果、PCH 键、依赖快照)——一种不可变的读取模型,每次发布时都会整体替换
- `DocumentCompile` / `DocumentCompiles`:每个文档最近一次编译所发布的产物(功能结果、PCH 键、依赖快照)——一种不可变的读取模型,每次发布时都会整体替换
- `EditorContext`:命令解析中属于编辑器的一侧——用户的上下文选择,以及为打开文件解析出的头文件上下文——叠加在项目的 `CommandResolver` 之上,仅用于面向编辑器的编译
- `Invalidator`:失效引擎——归并文件事件(磁盘内容变化与文件删除、编译数据库重新加载、worker 崩溃),生成一组去重的失效操作
- `FileTracker`:通过 stat 轮询发现编辑器之外发生的变化(重新生成 `compile_commands.json`、`git checkout`),并将事件送入 `Invalidator`:它包括对项目编译数据库的监视,以及经由文件表进行的一轮扫描,覆盖磁盘上的文件和查找失败的 include 曾经查找过的位置
- `Quarantine`:按文档记录崩溃——某类工作在某个文档上导致 worker 崩溃后,该文档的这类工作会暂停,直到文档发生变化(有间隔、有次数上限)或被保存

**服务** — 使用编译和索引结果的读取侧服务。

- `Features`:从各提供方——worker 的 AST、PCH 中缓存的 Preamble 产物或索引——组装各项功能的结果,并根据就绪状态路由每个请求:有最新 AST 时由 AST 响应,否则立即由索引支撑的投影响应。在 `readonly = on/auto` 下,文档完全由索引提供服务,直到编辑操作将其提升为完整的 AST 服务;编译始终按需进行,由请求而非生命周期事件触发
- `Features`:从各提供方——worker 的 AST、PCH 中缓存的 Preamble 产物或索引——组装各项功能的结果,并根据就绪状态路由每个请求:有最新 AST 时由 AST 响应,否则立即由根据索引算出的结果响应。在 `readonly = on/auto` 下,文档完全由索引提供服务,直到编辑操作将其提升为完整的 AST 服务;编译始终按需进行,由请求而非生命周期事件触发
- `ASTFamily`:任务图中的文档 AST 节点族——调度打开文档的编译任务并发布结果
- `Dispatcher`:与 worker 通信的文档侧组件——每个携带打开文档内容的请求(有状态查询、交互式代码补全/签名帮助构建、格式化)都会先通过该文档的隔离检查,再进行分发,并统一经由一个出口返回;若客户端已修改该请求对应的缓冲区,则由该出口返回 `ContentModified`
- `IndexQuery`:对所有索引来源——项目索引、按文件划分的分片以及打开文件的实时数据——执行只读查询,并统一仲裁数据时效性;以领域值作答,再由各传输层映射到各自的协议
Expand Down
6 changes: 3 additions & 3 deletions zh/clice/design/symbol-index.md
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ ProjectIndex Global directory: external symbols + which TUs contributed which
Shard Per-file variant storage (exact positions and relations), loaded on demand
Instantiations Per-file storage of what instantiations and macro expansions resolve
↑ overlay
Live index The open buffer's latest compile results, owned by its published projection
Live index The index of the open buffer's latest compile
```

**TUIndex** 是编译翻译单元时产生的原始索引数据,由编译期间构建的统一语义映射投影生成。由于一次编译涉及焦点文件及其包含的所有头文件,`TUIndex` 内部会为每个文件维护一组独立的条目。它还包含一份符号表以及本次编译的包含树:每进入一个文件就有一个节点,记录该文件、包含它的节点以及包含指令所在的行。符号表不收录文件局部符号——函数内的局部符号、模板的参数——但另一个文件涉及的少数几个除外——通过实例化、宏展开,或函数返回的局部类:其余的只有所在文件会涉及,描述它们的也正是该文件的条目。`TUIndex` 是临时数据,合并到持久化索引后即被丢弃。
Expand All @@ -80,7 +80,7 @@ Live index The open buffer's latest compile results, owned by its published

文件的**实例化记录(Instantiations)**保存的是:每个已索引翻译单元的模板实例化和宏展开在该文件文本中解析出、而其分片悬而未决的内容(见下文)。它们与分片存放在一起,对应分片的同一内容版本。

打开文件的**实时索引(live index)**来自其最近一次内存编译,由文档已发布的投影持有。它绝不会写入全局状态——只在查询时作为叠加层,使结果反映用户实际编辑的缓冲区内容。
打开文件的**实时索引(live index)**来自其最近一次内存编译,由文档最近一次编译持有。它绝不会写入全局状态——只在查询时作为叠加层,使结果反映用户实际编辑的缓冲区内容。

### 符号表分层

Expand All @@ -90,7 +90,7 @@ Live index The open buffer's latest compile results, owned by its published

### 索引构建

`TUIndex` 的构建是对统一语义映射的投影:每次编译执行一次 AST 遍历,记录所有需要关注的节点,再由索引投影按文件生成 `Occurrence` 和 `Relation` 条目。投影完成后,会对每个文件的条目进行规范化处理——去重并排序(出现记录按位置排序,以便进行二分查找;关系记录按类别和位置排序,以便过滤)——从而保证编码后的数据块具有确定性。
`TUIndex` 的构建是对统一语义映射的投影:每次编译执行一次 AST 遍历,记录所有需要关注的节点,索引器再据此按文件生成 `Occurrence` 和 `Relation` 条目。此后,会对每个文件的条目进行规范化处理——去重并排序(出现记录按位置排序,以便进行二分查找;关系记录按类别和位置排序,以便过滤)——从而保证编码后的数据块具有确定性。

构建期间,焦点文件的条目与头文件的条目分开保存。这样可以在合并时区别处理——焦点文件作为翻译单元自身的贡献合并,头文件则作为上下文变体合并。

Expand Down
Loading