> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# LSP and static analyzers

> Configure language servers and CLI static analyzers, inspect live findings inline, and run scoped file or whole-project diagnostic sweeps.

Embedder manages language servers and CLI static analyzers through one catalog. Language servers provide code navigation and live diagnostics. CLI analyzers add targeted checks, project scans, and compliance workflows.

Static analysis is opt-in. Listing an analyzer or detecting its binary does not enable it.

## Open the analyzer manager

Run any of these commands:

```txt theme={"system"}
/static-analyzer
/lsp
/analyzers
```

The manager has **Installed** and **Browse** views. Use it to:

* Enable or disable an analyzer
* Install a managed analyzer
* See the system-install instructions for a PATH-based analyzer
* Configure semantic settings without editing raw command flags
* Save settings for this project or every project
* Reset project overrides to inherited values
* Review binary status, version, detected configuration files, setup checks, and active capabilities
* Inspect live error, warning, information, and file counts

An analyzer can be selected in the catalog while its binary is still missing. The manager reports selection and binary availability separately.

## Configuration scopes

Global settings are stored in:

```txt theme={"system"}
~/.embedder/lsp.json
```

Project overrides are stored in:

```txt theme={"system"}
.embedder/lsp.json
```

Project values take precedence over global values. Unset project fields inherit the global value, then the catalog default.

Changing an LSP configuration stops its existing clients. The next matching request starts a new client with the updated command, arguments, environment, initialization data, and semantic settings.

The agent can inspect or change the same settings with `lsp_config`. Install, set, and reset operations require confirmation and cannot mutate configuration from Plan mode.

## Supported language servers

Embedder's LSP catalog contains six servers:

* **clangd:** managed LLVM C and C++ language server with clang-tidy diagnostics
* **rust-analyzer:** managed Rust language server for Cargo projects
* **ccls:** C and C++ language server installed from your system PATH
* **neocmakelsp:** managed CMake language server
* **devicetree-language-server:** managed Devicetree server with Zephyr binding support
* **kconfig-lsp:** Kconfig language server installed from your system PATH

Managed entries download their binary when enabled. PATH entries require you to install the executable or configure a command that Embedder can find.

Language server clients start lazily for a matching file and project root. Supported code-intelligence operations include:

* Go to definition and implementation
* Find references
* Hover documentation and type information
* Document and workspace symbols
* Prepare call hierarchy
* Incoming and outgoing calls

Inputs and returned positions use one-based line and character numbers.

## Supported CLI analyzers

The catalog also contains six CLI analyzers:

* **cppcheck:** C and C++ warnings, style, performance, portability, and supported compliance profiles; system install
* **clang-tidy:** opt-in Clang C and C++ checks; system LLVM install
* **Perforce QAC:** licensed C, C++, and Rust analysis with standards and Validate workflows; system install
* **Parasoft C/C++test:** licensed C and C++ analysis with MISRA, CERT, SARIF, and DTP workflows; system install
* **shellcheck:** managed shell-script analyzer
* **Coverity:** licensed C, C++, Rust, Java, C#, and Go analysis with local and Coverity Connect workflows; system install

Enabling a PATH-based entry records and validates its configuration. It does not install or license the commercial product.

Perforce QAC, Parasoft C/C++test, and Coverity have dedicated bundled skills for setup, execution, and evidence review. Load the matching skill before running those product workflows.

## File diagnostics after edits

After Embedder writes a supported file, it can attach diagnostics directly to the tool result:

* Enabled LSP servers publish diagnostics for their matching files.
* C and C++ files can run enabled `cppcheck` and `clang-tidy` checks.
* Shell files can run enabled `shellcheck` checks.

Findings include one-based line and column, severity, source, optional rule code, and message. Large result sets are bounded in the conversation and written to a full diagnostics report for later reading.

For an active per-file compliance profile, the result also reports a gate state:

* `PASS`: the selected automated gate ran without a matching compliance finding.
* `FAIL`: the gate found one or more matching findings.
* `INCOMPLETE`: configuration or parse errors prevented a valid result.
* `NOT RUN`: the required analyzer is disabled, missing, or not configured.

A failed or unavailable compliance gate creates or updates a remediation item in the current todo list. A later passing edit completes that item.

<Note>
  An automated analyzer result is evidence, not certification. MISRA and CERT
  profiles report their implemented or mapped coverage and any gaps.
</Note>

## Run project diagnostics

Ask Embedder to assess the project before a large scan:

```txt theme={"system"}
Assess the C and C++ project for static analysis scope, then run the default
project diagnostics if the configuration is valid.
```

`project_diagnostics` supports:

* `assess`: discover candidate files, project scale, compile databases, analyzer concurrency, and estimated batches without running analyzers
* `scan`: assess first, then run enabled LSP and supported CLI analyzers

The available profiles are:

* `default`: general LSP, cppcheck, and clang-tidy diagnostics; defaults to 250 files
* `misra`: cppcheck MISRA analysis across the non-vendored C and C++ implementation scope, up to 100,000 files
* `cert`: clang-tidy `cert-*` checks across the non-vendored C and C++ implementation scope, up to 100,000 files

The scanner prefers files from `compile_commands.json`. Without one, it walks the selected scope, excludes common build and vendored directories, prioritizes first-party implementation paths, and reports the resulting configuration gap.

A project result distinguishes:

* Analyzer findings
* Configuration findings
* Supporting findings
* Files attempted, completed, failed, or timed out
* Compile database and source-selection evidence
* Truncation and coverage gaps
* `COMPLETE` or `INCOMPLETE` assessment status

MISRA scans request whole-program cppcheck analysis. If that topology is not achieved, cross-translation-unit rules are marked unevaluated and unverifiable findings are withheld.

## Analyzer setup cues

The manager checks common prerequisites:

* clangd, ccls, cppcheck, and clang-tidy look for a compile database.
* rust-analyzer requires `Cargo.toml`.
* CMake, Devicetree, Kconfig, and shellcheck detect their project-specific configuration files.
* QAC checks the controlled project, synchronization input, license source, first-party scope, and required modules.
* Parasoft checks input scope, compiler, properties, workspace, supported version, licensing, and optional DTP destination.
* Coverity checks workflow configuration, build capture, license source, and optional Connect credentials.

Keep credentials in protected product-specific files. Parasoft and Coverity endpoint settings reject embedded credentials, and the manager does not ask the agent to store license secrets in `lsp.json`.

## End-to-end MISRA and CERT workflows

The open-source project profiles use CLI analyzers:

* MISRA uses the cppcheck MISRA addon.
* CERT uses clang-tidy `cert-*` checks.

`clangd` is a language server, not the analyzer that runs either whole-project profile. You can enable managed `clangd` for live C and C++ diagnostics, but it is optional for the workflows below.

Run analyzer setup in Act mode. Enabling an entry or changing project settings requires confirmation.

### MISRA with cppcheck

<Steps>
  <Step title="Install and verify cppcheck">
    On macOS:

    ```bash theme={"system"}
    brew install cppcheck
    cppcheck --version
    ```

    On Debian or Ubuntu:

    ```bash theme={"system"}
    sudo apt update
    sudo apt install cppcheck
    cppcheck --version
    ```

    Embedder validates the installed MISRA addon before it starts a MISRA scan. A cppcheck binary without a working addon cannot produce the automated report.
  </Step>

  <Step title="Prepare one build configuration">
    Use a current `compile_commands.json` for the target and build variant you want to assess. For a CMake project:

    ```bash theme={"system"}
    cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
    cmake --build build
    ```

    For another build system, use its compilation-database export and complete a clean configuration or build. Do not reuse a database from a different target, toolchain, or feature set.
  </Step>

  <Step title="Enable cppcheck for the project">
    Run:

    ```text theme={"system"}
    /static-analyzer
    ```

    Open **Browse**, select **cppcheck**, and enable it for this project. Set **Compile database** to the generated file, such as `build/compile_commands.json`. Keep unrelated analyzers disabled unless you want a separate result.

    You may also enable managed **clangd** if you want live diagnostics while editing. It does not replace the cppcheck MISRA scan.
  </Step>

  <Step title="Ask the agent to assess and scan">
    ```text theme={"system"}
    Use validate-MISRA with cppcheck across the entire non-vendored C and C++
    project. Assess the scope first, then run the MISRA project diagnostics profile
    without a file limit. Write the automated report and separate execution
    coverage, configuration fidelity, findings, and unassessed requirements.
    ```

    The agent inspects analyzer readiness, then runs the equivalent of:

    ```text theme={"system"}
    project_diagnostics({ operation: "assess", profile: "misra" })
    project_diagnostics({ operation: "scan", profile: "misra" })
    ```

    The report is written to:

    ```text theme={"system"}
    .embedder/reports/MISRA-automated-analysis-report.md
    ```
  </Step>

  <Step title="Check completion">
    Treat the result as complete only when the assessment is `COMPLETE`, every attempted file succeeds, no file times out, and the compile database or other analyzer inputs match the intended build. Findings from a partial run remain evidence, but the run is still incomplete.
  </Step>
</Steps>

The report distinguishes automated findings from manual rules, process artifacts, approved deviations, and other evidence needed by MISRA Compliance:2020. It does not establish compliance by itself.

### CERT with clang-tidy

<Steps>
  <Step title="Install and verify clang-tidy">
    On macOS:

    ```bash theme={"system"}
    brew install llvm
    export PATH="$(brew --prefix llvm)/bin:$PATH"
    clang-tidy --version
    ```

    On Debian or Ubuntu:

    ```bash theme={"system"}
    sudo apt update
    sudo apt install clang-tidy
    clang-tidy --version
    ```

    Persist the LLVM path in the environment that launches Embedder when Homebrew's LLVM binaries are not already on `PATH`.
  </Step>

  <Step title="Prepare one build configuration">
    Generate or locate `compile_commands.json` for the exact target and build variant. For CMake:

    ```bash theme={"system"}
    cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
    cmake --build build
    ```

    clang-tidy needs the real compiler, include paths, definitions, and language mode from that database. A host-only or stale database can make configuration evidence incomplete.
  </Step>

  <Step title="Enable clang-tidy for the project">
    Run `/static-analyzer`, open **Browse**, and select **clang-tidy**. Enable it for this project and set **Compile database directory** to the directory containing `compile_commands.json`, such as `build`.

    The CERT project profile selects `cert-*` checks for the scan. Supporting `bugprone-*`, `clang-analyzer-*`, or cppcheck passes remain separate evidence and run only when requested.
  </Step>

  <Step title="Ask the agent to assess and scan">
    ```text theme={"system"}
    Use validate-CERT with clang-tidy across the entire non-vendored C and C++
    project. Assess the scope first, then run the CERT project diagnostics profile
    without a file limit. Write the automated report and separate execution
    coverage, configuration fidelity, CERT-mapped findings, and coverage gaps.
    ```

    The agent inspects analyzer readiness, then runs the equivalent of:

    ```text theme={"system"}
    project_diagnostics({ operation: "assess", profile: "cert" })
    project_diagnostics({ operation: "scan", profile: "cert" })
    ```

    The report is written to:

    ```text theme={"system"}
    .embedder/reports/CERT-automated-analysis-report.md
    ```
  </Step>

  <Step title="Check completion">
    Require a `COMPLETE` assessment, no failed or timed-out files, and configuration evidence for the intended build. Do not map Clang diagnostic severity to CERT L1, L2, or L3 priority unless the project supplies reviewed priority metadata.
  </Step>
</Steps>

clang-tidy check names show implemented automated mappings; they do not prove that every requirement of a CERT guideline was assessed. See [Static analysis integrations](/integrations/static-analysis) for licensed Perforce QAC, Parasoft C/C++test, and Coverity workflows.