docs: comprehensive feature checklists, Chinese translations, and documentation overhaul - #461
Conversation
- Add docs/en/features/ with 14 feature checklist pages covering LSP features, lint, and project-wide format - Add docs/en/sidebar.yaml for centralized sidebar ordering - Rewrite README.md with accurate project description - Update all existing en/ and zh/ docs against source code: guide/ (configuration, quick-start), design/ (architecture, compilation, header-context, index, template-resolver), dev/ (build, contribution, test-and-debug) - All feature claims verified against source code by sub-agents - Remove unstable source line number references from docs
📝 WalkthroughWalkthroughThe PR rewrites and substantially expands clice's documentation in both English and Chinese. It adds new LSP feature reference pages (completion, hover, signature help, diagnostics, navigation, semantic tokens, inlay hints, document symbols, document links, folding ranges, formatting, code action, lint), rewrites design docs with multi-process architecture and persistent indexing, refreshes user guides (quick-start, configuration), updates developer workflow docs (build, test-and-debug, contribution), adds sidebar navigation configs, and renames repository references from ChangesDocumentation Overhaul
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Poem
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
|
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
docs/en/guide/configuration.md (1)
61-61: 💤 Low valueMinor grammar improvement: clarify subject of sentence.
Line 61 starts with "Can be either..." which lacks a clear subject. Consider revising to "These can be either..." or merging with the preceding sentence for better flow.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/guide/configuration.md` at line 61, The sentence starting with "Can be either..." on line 61 of the configuration.md file lacks a clear subject, making it grammatically unclear. Revise this sentence by either prepending it with "These can be either..." to establish the subject clearly, or merge it with the preceding sentence about paths to search for compile_commands.json files to improve overall flow and readability.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/en/design/architecture.md`:
- Around line 81-94: The fenced code block containing the architecture diagram
does not specify a language identifier. Add plaintext as the language specifier
immediately after the opening triple backticks (```plaintext) to ensure proper
markdown formatting and syntax highlighting in the documentation.
In `@docs/en/design/template-resolver.md`:
- Around line 27-29: The three-item numbered list in the template resolver
documentation has repetitive sentence openings where each item begins with "It"
(assumes, only performs, ignores). Restructure these three list items to vary
the sentence structure and avoid the repetitive phrasing pattern. Consider
reorganizing the numbered list by rewriting each item to start with different
sentence structures or converting to a bullet-point format with more varied
wording while preserving the technical meaning about template lookup
limitations, instantiation issues, and default parameter handling.
In `@docs/en/dev/test-and-debug.md`:
- Around line 82-117: The "Debug the VS Code extension" section instructs to
open the `editors/vscode` folder in VS Code and press F5, but the VS Code
extension launch configurations are located in the repository root's
`.vscode/launch.json`, not in `editors/vscode/.vscode/`. Update step 2 to
clarify that the entire repository root must be opened in VS Code (not just the
`editors/vscode` folder) for the launch configurations to be available when F5
is pressed, or alternatively create the necessary `.vscode/launch.json`
configuration file in the `editors/vscode/` directory with the appropriate
extension host launch configurations.
In `@docs/en/features/completion.md`:
- Around line 89-91: The footnote definitions for [^clangd-2626],
[^clangd-2577], and [^vscode-67714] are defined but never cited anywhere in the
document, making them unused. Remove these three footnote definition lines from
the file at lines 89-91, or alternatively, if these footnotes are meant to be
referenced, add appropriate citations using the footnote syntax (like
[^clangd-2626]) in the relevant text sections within the document where these
issues or topics are discussed.
---
Nitpick comments:
In `@docs/en/guide/configuration.md`:
- Line 61: The sentence starting with "Can be either..." on line 61 of the
configuration.md file lacks a clear subject, making it grammatically unclear.
Revise this sentence by either prepending it with "These can be either..." to
establish the subject clearly, or merge it with the preceding sentence about
paths to search for compile_commands.json files to improve overall flow and
readability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 09e70d9a-1d49-4699-9a33-ad40f7f211c5
📒 Files selected for processing (36)
README.mddocs/en/design/architecture.mddocs/en/design/compilation.mddocs/en/design/header-context.mddocs/en/design/index.mddocs/en/design/template-resolver.mddocs/en/dev/build.mddocs/en/dev/contribution.mddocs/en/dev/test-and-debug.mddocs/en/features/completion.mddocs/en/features/diagnostics.mddocs/en/features/document-links.mddocs/en/features/document-symbols.mddocs/en/features/folding-ranges.mddocs/en/features/formatting.mddocs/en/features/hover.mddocs/en/features/inlay-hints.mddocs/en/features/lint.mddocs/en/features/navigation.mddocs/en/features/overview.mddocs/en/features/project-format.mddocs/en/features/semantic-tokens.mddocs/en/features/signature-help.mddocs/en/guide/configuration.mddocs/en/guide/quick-start.mddocs/en/sidebar.yamldocs/zh/design/architecture.mddocs/zh/design/compilation.mddocs/zh/design/header-context.mddocs/zh/design/index.mddocs/zh/design/template-resolver.mddocs/zh/dev/build.mddocs/zh/dev/contribution.mddocs/zh/dev/test-and-debug.mddocs/zh/guide/configuration.mddocs/zh/guide/quick-start.md
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9c5ef19f3d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- Replace wrong clice-project URLs with clice-io across docs and editor metadata
- Fix compile_commands_paths default ([] with workspace scan, not ["${workspace}/build"])
- Remove fabricated max_active_file 1-512 range (no clamp exists in code)
- Correct index relation kind: derived, not override
- Replace nonexistent Scanner with scan.h/DependencyDirectivesScanner in architecture
…se translations - Rewrite 13 feature docs with detailed checklists, code examples, and ~200 clangd issue references - Add Chinese (zh) translations for all feature pages - Merge project-format.md into formatting.md, remove standalone page - Remove implementation file paths from all feature docs - Cross-validate all issue references via review agents
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ccc84d3bac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (9)
docs/en/features/diagnostics.md (1)
13-17: ⚡ Quick winAdd language specification to fenced code blocks.
Lines 13–17 and 28–31 are missing language specifications. Per markdownlint (MD040), all fenced code blocks should declare their language to enable syntax highlighting.
- Lines 13–17: Use
```cpp(C++ example)- Lines 28–31: Use
```cpp(C++ comment example)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/features/diagnostics.md` around lines 13 - 17, The fenced code blocks in the diagnostics documentation are missing language specifications required by markdownlint rule MD040. Add the language identifier cpp to the opening fence of the code blocks showing C++ examples: change the opening fence from three backticks to ```cpp``` for both the code block at lines 13-17 containing the missing_a.h, missing_b.h, missing_c.h includes and the code block at lines 28-31 containing the C++ comment example to enable proper syntax highlighting.docs/zh/features/document-symbols.md (1)
12-20: ⚡ Quick winAdd language specifications to fenced code blocks showing symbol tree and output examples.
Eight fenced code blocks are missing language specifications (per markdownlint MD040). These are all output/diagram examples—apply consistent language specs:
- Lines 12–20, 24–27, 44–52, 56–59, 63–65: Use
```text(symbol tree / outline diagrams)- Lines 69–72, 87–90, 94–97: Use
```text(output format examples)This improves readability and consistency with other feature documentation.
Also applies to: 24-27, 44-52, 56-59, 63-65, 69-72, 87-90, 94-97
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/zh/features/document-symbols.md` around lines 12 - 20, Add language specifications to fenced code blocks in the markdown file to comply with markdownlint MD040 rule. Find all eight fenced code blocks that currently lack language specifications and add text as the language identifier. For the symbol tree and outline diagrams shown at lines 12-20, 24-27, 44-52, 56-59, and 63-65, change the opening fence from triple backticks to triple backticks followed by text. Similarly, for the output format examples at lines 69-72, 87-90, and 94-97, add text as the language specification to their respective fenced code blocks. This ensures consistent formatting across all code examples throughout the documentation.docs/zh/features/completion.md (1)
77-77: ⚡ Quick winFix spacing in inline code spans.
Line 77 contains spaces inside inline code:
` `(空格)`should be`(空格)`. Per markdownlint (MD038, no-space-in-code), remove padding spaces from inline code spans.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/zh/features/completion.md` at line 77, The inline code spans on line 77 contain unnecessary padding spaces that violate markdownlint rule MD038. Remove the extra spaces inside the backticks for the inline code block containing `(空格)`. Specifically, change `` ` `(空格)` `` to `` `(空格)` `` by removing the space immediately after the opening backtick and before the closing backtick in that inline code span.docs/en/features/inlay-hints.md (1)
88-91: ⚡ Quick winAdd language specification to fenced code blocks showing hint display format.
Lines 88–91 and 188–191 contain fenced code blocks without language specifications. These appear to be plaintext/output examples showing how hints are displayed. Mark them as
```textto enable consistent styling.Also applies to: 188-191
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/features/inlay-hints.md` around lines 88 - 91, In the fenced code blocks displaying inlay hint examples that show outputs like "map<str…, int>::iterator", add the language specification "text" to the opening backticks. Change the opening from triple backticks to triple backticks followed by "text" (``` text) for both the code block starting around line 88 showing the map iterator hint and the code block around line 188 (mentioned in "Also applies to") to enable consistent styling and syntax highlighting across the documentation.docs/en/features/document-links.md (1)
22-25: ⚡ Quick winAdd language specifier to code block on line 22.
The code block is missing a language identifier. Add
```textor```cppbefore the example.🧹 Proposed fix
Show resolved absolute path as tooltip - ``` + ```text `#include` <vector> // tooltip: /usr/include/c++/14/vector</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/en/features/document-links.mdaround lines 22 - 25, The code block
example containing the#includedirective and tooltip comment is missing a
language specifier on its opening backticks. Add a language identifier to the
code fence by changing the openingto eithercpp or ```text to properly
denote the code block type in the markdown file.</details> <!-- cr-comment:v1:a4cc2ca1acf7e4ce352a66d3 --> </blockquote></details> <details> <summary>docs/en/features/navigation.md (1)</summary><blockquote> `450-450`: _⚡ Quick win_ **Add language specifiers to code blocks.** Multiple code blocks at lines 450, 486, 496, 503, 509, and 516 are missing language identifiers. Add ` ```cpp` to each. <details> <summary>🧹 Fix pattern</summary> For each flagged code block showing C++ examples, change: ``` - ``` + ```cpp <code> ``` ``` </details> Also applies to: 486-486, 496-496, 503-503, 509-509, 516-516 <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/en/features/navigation.mdat line 450, Multiple code blocks in the
documentation are missing language identifiers for C++ syntax highlighting.
Locate each unmarked code block fence (the openingwithout a language specifier) at the positions noted and change them fromto ```cpp to properly
identify them as C++ code examples. This applies to all six flagged code blocks
throughout the file.</details> <!-- cr-comment:v1:78d3cbb2011132e5557931c5 --> </blockquote></details> <details> <summary>docs/en/dev/contribution.md (1)</summary><blockquote> `13-15`: _⚡ Quick win_ **Add language specifier to code block.** The fenced code block on line 13 is missing a language identifier (e.g., ` ```text`). This helps with syntax highlighting and passes linting. <details> <summary>🧹 Proposed fix</summary> ```diff 1. **Commit messages**: Use [conventional commits](https://www.conventionalcommits.org/): - ``` + ```text <type>(<scope>): <short description> ``` ``` </details> <details> <summary>🤖 Prompt for AI Agents</summary> ``` Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/en/dev/contribution.md` around lines 13 - 15, The fenced code block containing the commit message format pattern `<type>(<scope>): <short description>` is missing a language identifier on its opening fence. Add the language specifier `text` to the opening triple backticks of this code block (change from triple backticks with no identifier to triple backticks followed by `text`) to enable proper syntax highlighting and satisfy linting requirements. ``` </details> <!-- cr-comment:v1:31b13f8a73b560c17845dad3 --> </blockquote></details> <details> <summary>docs/en/features/folding-ranges.md (1)</summary><blockquote> `94-98`: _⚡ Quick win_ **Add language specifier to code block on line 94.** The code block showing `collapsedText` placeholder examples is missing a language identifier. Add ` ```text`. <details> <summary>🧹 Proposed fix</summary> ```diff `collapsedText` placeholder (LSP 3.17) — show a summary when folded ([clangd#2667](https://github.com/clangd/clangd/issues/2667)) - ``` + ```text void processData(const Config& cfg) {...} // shows signature + {...} `#include` <vector> ... (5 more) // shows include count /* License header... */ // shows first line ``` ``` </details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/en/features/folding-ranges.mdaround lines 94 - 98, The code block
displaying the collapsedText placeholder examples is missing a language
identifier for proper syntax highlighting. Add the language specifier "text" to
the opening triple backticks before the example that shows void processData and
the include statement, changing the openingtotext to complete the
markdown code fence formatting.</details> <!-- cr-comment:v1:147751523e675547475ef802 --> </blockquote></details> <details> <summary>docs/en/features/document-symbols.md (1)</summary><blockquote> `12-12`: _⚡ Quick win_ **Add language specifiers to code blocks.** Multiple code blocks are missing language identifiers: lines 12, 24, 44, 56, 63, 69, 87, and 94. Add ` ```cpp` or ` ```text` as appropriate. <details> <summary>🧹 Example fix pattern</summary> For each code block missing a language specifier, change: ``` - ``` + ```cpp <code example> ``` ``` Given that document-symbols.md contains C++ code examples throughout, using ` ```cpp` is appropriate for all these blocks. </details> Also applies to: 24-24, 44-44, 56-56, 63-63, 69-69, 87-87, 94-94 <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/en/features/document-symbols.mdat line 12, Add language specifiers to
all unmarked code blocks in the document-symbols.md file. Locate the opening
code fences (the triple backticks) at lines 12, 24, 44, 56, 63, 69, 87, and 94,
and appendcppto each one to change them from baretocpp. Since all
code examples in this document are C++ examples, using the cpp language
identifier is appropriate for all of these code blocks.</details> <!-- cr-comment:v1:63f49796d8057910cf779b6c --> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.Inline comments:
In@docs/zh/features/signature-help.md:
- Around line 143-146: The code block containing the comparison comments about
push_back is missing a language specifier on the opening fence. Add the language
identifiercppto the opening triple backticks (```cpp) for the code block
that shows the current and expected parameter names for push_back. This will
ensure proper syntax highlighting and comply with markdown linting standards.
Nitpick comments:
In@docs/en/dev/contribution.md:
- Around line 13-15: The fenced code block containing the commit message format
pattern<type>(<scope>): <short description>is missing a language identifier
on its opening fence. Add the language specifiertextto the opening triple
backticks of this code block (change from triple backticks with no identifier to
triple backticks followed bytext) to enable proper syntax highlighting and
satisfy linting requirements.In
@docs/en/features/diagnostics.md:
- Around line 13-17: The fenced code blocks in the diagnostics documentation are
missing language specifications required by markdownlint rule MD040. Add the
language identifier cpp to the opening fence of the code blocks showing C++
examples: change the opening fence from three backticks tocppfor both
the code block at lines 13-17 containing the missing_a.h, missing_b.h,
missing_c.h includes and the code block at lines 28-31 containing the C++
comment example to enable proper syntax highlighting.In
@docs/en/features/document-links.md:
- Around line 22-25: The code block example containing the
#includedirective
and tooltip comment is missing a language specifier on its opening backticks.
Add a language identifier to the code fence by changing the openingto eithercpp or ```text to properly denote the code block type in the markdown
file.In
@docs/en/features/document-symbols.md:
- Line 12: Add language specifiers to all unmarked code blocks in the
document-symbols.md file. Locate the opening code fences (the triple backticks)
at lines 12, 24, 44, 56, 63, 69, 87, and 94, and appendcppto each one to
change them from baretocpp. Since all code examples in this document
are C++ examples, using the cpp language identifier is appropriate for all of
these code blocks.In
@docs/en/features/folding-ranges.md:
- Around line 94-98: The code block displaying the collapsedText placeholder
examples is missing a language identifier for proper syntax highlighting. Add
the language specifier "text" to the opening triple backticks before the example
that shows void processData and the include statement, changing the openingtotext to complete the markdown code fence formatting.In
@docs/en/features/inlay-hints.md:
- Around line 88-91: In the fenced code blocks displaying inlay hint examples
that show outputs like "map<str…, int>::iterator", add the language
specification "text" to the opening backticks. Change the opening from triple
backticks to triple backticks followed by "text" (``` text) for both the code
block starting around line 88 showing the map iterator hint and the code block
around line 188 (mentioned in "Also applies to") to enable consistent styling
and syntax highlighting across the documentation.In
@docs/en/features/navigation.md:
- Line 450: Multiple code blocks in the documentation are missing language
identifiers for C++ syntax highlighting. Locate each unmarked code block fence
(the openingwithout a language specifier) at the positions noted and change them fromto ```cpp to properly identify them as C++ code examples. This
applies to all six flagged code blocks throughout the file.In
@docs/zh/features/completion.md:
- Line 77: The inline code spans on line 77 contain unnecessary padding spaces
that violate markdownlint rule MD038. Remove the extra spaces inside the
backticks for the inline code block containing(空格). Specifically, change` `(空格)`to`(空格)`by removing the space immediately after the opening
backtick and before the closing backtick in that inline code span.In
@docs/zh/features/document-symbols.md:
- Around line 12-20: Add language specifications to fenced code blocks in the
markdown file to comply with markdownlint MD040 rule. Find all eight fenced code
blocks that currently lack language specifications and add text as the language
identifier. For the symbol tree and outline diagrams shown at lines 12-20,
24-27, 44-52, 56-59, and 63-65, change the opening fence from triple backticks
to triple backticks followed by text. Similarly, for the output format examples
at lines 69-72, 87-90, and 94-97, add text as the language specification to
their respective fenced code blocks. This ensures consistent formatting across
all code examples throughout the documentation.</details> <details> <summary>🪄 Autofix (Beta)</summary> Fix all unresolved CodeRabbit comments on this PR: - [ ] <!-- {"checkboxId": "4b0d0e0a-96d7-4f10-b296-3a18ea78f0b9"} --> Push a commit to this branch (recommended) - [ ] <!-- {"checkboxId": "ff5b1114-7d8c-49e6-8ac1-43f82af23a33"} --> Create a new PR with the fixes </details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: Path: .coderabbit.yaml **Review profile**: CHILL **Plan**: Pro **Run ID**: `cb6929ff-94dc-424f-8dd6-8a729da0161f` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 9c5ef19f3d12589f628456a20b9413dac3717408 and ccc84d3bac2c3153f017446e2a75864f2f52be9e. </details> <details> <summary>📒 Files selected for processing (53)</summary> * `README.md` * `docs/clice.toml` * `docs/en/design/architecture.md` * `docs/en/design/compilation.md` * `docs/en/design/header-context.md` * `docs/en/design/index.md` * `docs/en/design/template-resolver.md` * `docs/en/dev/build.md` * `docs/en/dev/contribution.md` * `docs/en/dev/test-and-debug.md` * `docs/en/features/code-action.md` * `docs/en/features/completion.md` * `docs/en/features/diagnostics.md` * `docs/en/features/document-links.md` * `docs/en/features/document-symbols.md` * `docs/en/features/folding-ranges.md` * `docs/en/features/formatting.md` * `docs/en/features/hover.md` * `docs/en/features/inlay-hints.md` * `docs/en/features/lint.md` * `docs/en/features/navigation.md` * `docs/en/features/overview.md` * `docs/en/features/semantic-tokens.md` * `docs/en/features/signature-help.md` * `docs/en/guide/configuration.md` * `docs/en/guide/quick-start.md` * `docs/en/sidebar.yaml` * `docs/zh/design/architecture.md` * `docs/zh/design/compilation.md` * `docs/zh/design/index.md` * `docs/zh/dev/build.md` * `docs/zh/dev/contribution.md` * `docs/zh/dev/test-and-debug.md` * `docs/zh/features/code-action.md` * `docs/zh/features/completion.md` * `docs/zh/features/diagnostics.md` * `docs/zh/features/document-links.md` * `docs/zh/features/document-symbols.md` * `docs/zh/features/folding-ranges.md` * `docs/zh/features/formatting.md` * `docs/zh/features/hover.md` * `docs/zh/features/inlay-hints.md` * `docs/zh/features/lint.md` * `docs/zh/features/navigation.md` * `docs/zh/features/overview.md` * `docs/zh/features/semantic-tokens.md` * `docs/zh/features/signature-help.md` * `docs/zh/guide/configuration.md` * `docs/zh/guide/quick-start.md` * `docs/zh/sidebar.yaml` * `editors/vscode/README.md` * `editors/vscode/package.json` * `editors/zed/LICENSE` </details> <details> <summary>✅ Files skipped from review due to trivial changes (29)</summary> * editors/vscode/package.json * editors/zed/LICENSE * docs/zh/sidebar.yaml * docs/zh/features/code-action.md * docs/zh/features/overview.md * docs/clice.toml * docs/en/features/code-action.md * docs/en/features/formatting.md * docs/zh/features/formatting.md * docs/zh/features/lint.md * docs/en/design/template-resolver.md * docs/en/features/overview.md * docs/en/sidebar.yaml * docs/en/design/architecture.md * docs/en/design/index.md * docs/en/design/header-context.md * editors/vscode/README.md * docs/zh/design/compilation.md * docs/en/features/lint.md * docs/en/guide/configuration.md * README.md * docs/en/design/compilation.md * docs/en/dev/build.md * docs/zh/design/index.md * docs/zh/guide/configuration.md * docs/zh/features/semantic-tokens.md * docs/zh/guide/quick-start.md * docs/en/guide/quick-start.md * docs/zh/dev/build.md </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (2)</summary> * docs/zh/dev/test-and-debug.md * docs/en/dev/test-and-debug.md </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
…source Reviewed by gpt-5.5 (xhigh) reading clice src/ and llvm-project clangd source. Key changes across all 13 feature docs (EN + ZH): - Fix inaccurate [x] marks: completion snippet patterns (no actual placeholders), macro completion "from index" (no index query), dot-to-arrow trigger (fix-its not propagated) - Promote verified items to [x]: hover truncation (#710), attribute docs, auto/decltype hover, this/predefined expr hover, synthesized accessor docs; inlay-hints forwarding params, operator() hints, comment suppression, deduction failure guard, type length limit, ref hints, block-end hints, deducing-this, default arg hints; diagnostics NOLINT suppression, system-header macro suppression, diagnostic code field; document-links #include_next, macro-expanded paths, __has_include_next; document-symbols Concept, variable/function type detail; folding-ranges collapsedText; signature-help template args, aggregate init, parameter label offsets; semantic-tokens DependentName modifier - Add missing [ ] items across all docs for future goals - Fix wording: code-action raw string direction, using-namespace behavior, if-swap scope, pure-virtual stubs; navigation break/continue via document highlight; semantic-tokens Conflict as token kind - Add new sections: navigation Document Highlight + Switch Source/Header, completion LSP Protocol Features, diagnostics Diagnostic Actions
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9a6e5fb2f1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ## Symbol Detail | ||
|
|
||
| - [x] Function signatures in the `detail` field — parameter types and names for overload disambiguation ([clangd#520](https://github.com/clangd/clangd/issues/520), [clangd#601](https://github.com/clangd/clangd/issues/601), [clangd#1232](https://github.com/clangd/clangd/issues/1232)) |
There was a problem hiding this comment.
Do not promise parameter names in document symbols
For function symbols, symbol_detail() builds the detail string from ValueDecl::getType().print(...), so it never reads the ParmVarDecl names; the LSP result keeps the function name separately and emits a type-like detail such as void (int) rather than process(int x). Users relying on the outline to disambiguate overloads by parameter names will not see the advertised information, so either print parameters from FunctionDecl::parameters() or narrow this checklist item to parameter types only.
Useful? React with 👍 / 👎.
| draw(/*x=*/10, /*y=*/20); // no hints needed — inline comments serve the same purpose | ||
| ``` | ||
|
|
||
| - [x] Default argument value hints |
There was a problem hiding this comment.
Do not mark disabled default-argument hints implemented
On the LSP path, StatefulWorker calls feature::inlay_hints(..., {}, ...), while InlayHintsOptions::default_arguments defaults to false and there is no client/config plumbing here to enable it. In normal editor requests, calls that use defaulted parameters therefore do not produce default-argument hints despite this checked item; please enable/wire the option or mark it planned.
Useful? React with 👍 / 👎.
|
|
||
| ## Block End Hints | ||
|
|
||
| - [x] Show the declared name after a closing brace for long blocks ([clangd#1634](https://github.com/clangd/clangd/issues/1634)) |
There was a problem hiding this comment.
Do not mark disabled block-end hints implemented
The only LSP inlay-hints call passes default InlayHintsOptions, and block_end defaults to false, so VisitFunctionDecl/VisitTagDecl/loop visitors never add the closing-brace labels for editor requests. Long functions therefore will not show the advertised } // Widget::processData hints unless this option is wired on or the checklist is changed back to planned.
Useful? React with 👍 / 👎.
|
|
||
| ## Project-wide Format | ||
|
|
||
| Beyond the LSP `textDocument/formatting` request (which formats a single open file), clice provides project-wide formatting via CLI. |
There was a problem hiding this comment.
Do not promise a project-wide format CLI
The clice format subcommand is only a stub: src/clice.cc logs format is not yet implemented for every non-help invocation, and the checklist immediately below also leaves batch formatting unchecked. Users following this sentence will try a CLI workflow that cannot format files, so this should describe planned work until the command is implemented.
Useful? React with 👍 / 👎.
| ## Find References | ||
|
|
||
| - [x] Index-based cross-TU find references | ||
| - [x] Include declarations option |
There was a problem hiding this comment.
Do not mark declarations as included in references
The LSP references handler only adds RelationKind::Definition when include_declaration is true, even though declarations are indexed as a separate RelationKind::Declaration; forward declarations without definitions in the queried files will still be omitted. This checked item will mislead users expecting the standard include-declaration behavior, so query declarations as well or narrow the claim to including definitions.
Useful? React with 👍 / 👎.
|
|
||
| **Template intelligence** — Type `vec2[0].` inside a template body and get full completions. clice uses pseudo-instantiation to resolve dependent types through nested typedefs and template specializations without needing concrete type arguments. Types like `std::vector<std::vector<T>>::reference` resolve to `std::vector<T>&`, enabling completion, hover, and go-to-definition inside generic code. | ||
|
|
||
| **Compilation context** — A first-class concept in clice. For source files, switch between different compilation commands (e.g. different build configurations). For header files, switch which source file provides the including context (preprocessor state, preceding declarations). This handles non-self-contained headers and context-dependent macros naturally, with automatic context switching as you navigate. |
There was a problem hiding this comment.
Do not document source-file context switching as available
For source files with multiple CDB entries, clice/switchContext has no way to select a specific entry: it stores only a path id, fill_compile_args() normally takes cdb.lookup(...).front(), and an active context sends the source file through the header-context path, which requires an include-chain host and fails for ordinary sources. Users with debug/release entries therefore cannot switch build configurations as described here.
Useful? React with 👍 / 👎.
|
|
||
| ### Supersede Logic | ||
|
|
||
| When a file is edited while its previous compilation is in-flight, the old build is "superseded" — its interest is released and a new build starts. The old worker task observes the cancellation token and aborts early. |
There was a problem hiding this comment.
Do not say superseded workers abort early
The cancellation token is applied to the compile-graph coroutine, but the PCM dispatch itself is just pool.send_stateless(bp) with no token or cancellation message to the stateless worker. When a module build is superseded, the master can stop waiting and drop interest, but the worker process continues compiling until that IPC request finishes, so document this as abandoning stale results or wire cancellation through to workers before promising early aborts.
Useful? React with 👍 / 👎.
| - [x] `// NOLINT` comment suppression | ||
| - [x] `// NOLINTNEXTLINE` comment suppression | ||
| - [x] `// NOLINTBEGIN` / `// NOLINTEND` block suppression |
There was a problem hiding this comment.
Do not mark NOLINT suppression as active
The only NOLINT handling is inside ClangTidyChecker::adjust_level() after context.getCheckName() identifies a clang-tidy diagnostic; normal Clang diagnostics never consult these comments, and the LSP compile path still does not enable clang-tidy. In editor diagnostics, adding // NOLINT/NOLINTNEXTLINE therefore will not suppress the advertised warnings, so this should be scoped to future clang-tidy support or wired into the active diagnostic path.
Useful? React with 👍 / 👎.
|
|
||
| ## Configuration | ||
|
|
||
| Respects standard `.clang-tidy` configuration files in the project tree. |
There was a problem hiding this comment.
Do not claim .clang-tidy files are respected
The clang-tidy option builder uses hardcoded defaults and even has a TODO for adding the file-based options provider, while clice lint itself is still a stub. Users who put checks or suppressions in a project .clang-tidy will not have that file loaded by clice today, so this configuration section should be marked planned until file discovery is implemented.
Useful? React with 👍 / 👎.
| Add the clice Neovim plugin to your runtime path: | ||
|
|
||
| ```lua | ||
| -- lazy.nvim | ||
| { dir = "/path/to/clice/editors/nvim" } | ||
|
|
||
| -- or manually | ||
| vim.opt.rtp:append("/path/to/clice/editors/nvim") |
There was a problem hiding this comment.
Do not present runtimepath as sufficient Neovim setup
Adding editors/nvim to runtimepath only loads plugin/clice-nvim.lua, which currently just creates an augroup and has TODOs; the actual LSP config is in doc/clice.lua, which Neovim will not auto-load as a server configuration from runtimepath. Following this quick-start leaves users without a running clice LSP client, so document the needed lsp/clice.lua/vim.lsp.config setup or move the config into a loadable location.
Useful? React with 👍 / 👎.
Summary
docs/en/features/covering all implemented LSP features with source-verified[x]/[ ]checklists and clangd issue referencesdocs/zh/features/) for all 13 feature docs, plus sidebar and overview pagesrc/feature/) and clangd source (LLVM) using gpt-5.5 automated reviewproject-format.mdintoformatting.md, update README, configuration guide, design docs (architecture, compilation, header-context, index, template-resolver)Feature docs
Each feature doc follows a consistent format: categorized checklist items with
[x](implemented in clice) /[ ](future goal), code examples, and inline clangd issue references for known gaps.completion.mdnavigation.mdhover.mddiagnostics.mdcode-action.mdsemantic-tokens.mdinlay-hints.mdsignature-help.mddocument-symbols.mddocument-links.mdfolding-ranges.mdformatting.mdlint.mdOther changes
clang_tidy,max_active_file,worker_memory_limitas not-yet-wired/enforcedScopedPauseto completion/signature-help/formatting (not hover)Test plan
pixi run docs[x]items verified against clice source code