Static analysis integrations

Embedder exposes language servers and command-line analyzers through one Static Analyzers panel and one configuration model. You can use live file diagnostics during development or run a project scan with explicit coverage and completion reporting.

​

Configure an analyzer

Use /static-analyzer in the CLI. /lsp and /analyzers open the same manager. In the VS Code extension, open the Static Analyzers panel. Project settings are stored in .embedder/lsp.json. Global defaults are stored in ~/.embedder/lsp.json. Store paths and non-secret metadata there, not license contents, passwords, tokens, or authentication keys.

​

LSP analyzer catalog

Language Server Protocol (LSP) analyzers provide diagnostics as Embedder opens or inspects supported files. The common diagnostics file surface covers C and C++ sources and headers, Rust, CMake, Devicetree and overlay files, Kconfig-style files, and shell scripts where the matching analyzer is enabled.

​

CLI analyzer catalog

CLI analyzers run explicit scans and may need build capture, compiler configuration, licenses, or report directories. The project_diagnostics scanner can combine enabled LSP diagnostics with supported CLI analyzers. Its misra and cert profiles default to the whole non-vendored C/C++ source set. Do not narrow that scope unless you explicitly asked for a path or file limit. For a complete open-source setup, follow the MISRA and CERT workflows from analyzer installation and compile-database configuration through the agent assessment, scan, and report.

​

Coverity skills

Embedder bundles workflow skills for Coverity 2026.6. It does not bundle Coverity binaries or licenses. Use one Coverity release and one intermediate directory throughout a run. For a controlled result, preserve the clean build command, source revision, compiler configuration, raw exits, full logs, captured translation units, failed units, and generated reports. The full client can analyze locally. A Thin Client captures locally and sends analysis to Scan Service. Publication, baseline creation, triage changes, suppressions, deviations, and captured-code exclusions require explicit approval. Coverity configuration or a running process does not prove successful analysis. Mark the result incomplete when capture is partial, a translation unit fails, the license cannot be checked out, or a required report or publication fails.

​

Parasoft C/C++test skills

Embedder bundles Parasoft workflow knowledge, not the analyzer, EULA acceptance, license, or Compliance Pack entitlement. Select exactly one current input:

• compile_commands.json
• a cpptest.bdf build data file
• a traced clean build
• one complete compile command for an intentionally limited analysis

A single compile command is not whole-project coverage. Keep C/C++test workspaces single-owner, verify the exact compiler and built-in configuration with the installed CLI, and do not substitute Recommended Rules for an unavailable licensed compliance configuration. The MCP extension reads rules, installed documentation, and local XML reports. It does not run the analysis and cannot prove that the report came from a complete run.

​

Perforce QAC skills

Start every QAC task with validate-qac. It coordinates the specialized qac-* skills for project setup, QA CLI, C, C++, Rust, dataflow, metrics, cross-module analysis, naming rules, standard modules, reports, and optional Validate publication. The current bundled workflow targets QAC 2026.2 and its matching components. The marketplace integration does not install or license QAC. qacli must be on PATH, and a controlled project must contain both prqaproject.xml and prqa/. QAC analysis has a strict first-party boundary:

• Define owned source roots before synchronization.
• Exclude vendor, adopted, generated, and external translation units from the captured analysis scope.
• Allow compiler and system headers only as dependencies needed to analyze first-party code.
• Stop and mark the result incomplete if source ownership is unclear or QAC cannot isolate the required scope.

Use the QAC project’s selected components, ACF, RCF, CCT, exclusions, and suppressions. Do not replace project policy with an inferred marketplace profile. A stale build synchronization or a partial component run is not complete evidence.

​

MISRA workflow

The validate-MISRA skill honors an analyzer you name. Without an explicit choice, it selects an enabled, ready analyzer for the requested standard and prefers Perforce QAC only when its controlled project, required module, binary, and license are ready. The supported routes are:

• Perforce QAC with its controlled MISRA module and project workflow
• Parasoft with the requested licensed MISRA configuration
• Coverity with a reviewed coding-standard configuration
• the cppcheck MISRA addon as the open-source fallback for best-effort whole-project automated evidence

Do not run a second analyzer as silent corroboration. Ask for a separate result if you want to compare analyzers. The misra-c-2012-coding skill is authoring guidance. When the matching per-file compliance profile is active, it can apply a cppcheck gate after C or C++ edits. It does not replace validate-MISRA or the MISRA Compliance:2020 process artifacts. MISRA reports must distinguish:

• analyzer execution coverage
• configuration fidelity
• automated findings
• manual rules and process artifacts that were not assessed
• approved deviations and suppressions

Do not infer Mandatory, Required, or Advisory categories from rule numbers or diagnostic severity. Use those labels only when the configured analyzer emits them.

​

CERT workflow

The validate-CERT skill also honors an analyzer you name. Without an explicit choice, it selects an enabled, ready analyzer and prefers Perforce QAC only when its controlled CERT module, project, binary, and license are ready. The supported routes are:

• Perforce QAC with a controlled CERT module and project
• Parasoft with a licensed CERT C or CERT C++ configuration
• Coverity with a reviewed CERT coding-standard configuration
• the clang-tidy CLI with cert-* checks as the open-source fallback for best-effort whole-project evidence

clang-tidy check names do not prove that every requirement of the corresponding CERT guideline was checked. Do not derive CERT L1, L2, or L3 priority from Clang severity. A supporting cppcheck pass requires your explicit request and remains separate evidence.

​

Usage boundaries

• Listing analyzers and checking binary status does not enable them.
• Installing an analyzer entry or changing project or global settings requires confirmation.
• Commercial binaries, licenses, EULAs, credentials, and server entitlements remain your responsibility.
• Use a current compilation database or controlled build capture for the exact target and build variant.
• Do not report an interrupted, timed-out, partially captured, or partially analyzed run as complete.
• Do not create suppressions, deviations, baselines, remote publications, or shared configuration changes without approval.
• Do not modify source unless you asked for remediation or an active per-file compliance gate requires the agent to fix a finding it introduced.
• Keep secret values out of .embedder/lsp.json, command lines, logs, reports, chat, and delegated review context.