Analysis¶

An analysis run examines the sources of a workspace. Midair deploys the analyser on the node of the workspace, builds the code under test with the build command, and reads the result.

The Analysis section of the sidebar has three screens:

Runs: The analysis runs.
Templates: The analysis templates.
Distributions: The analyser builds. See Distributions.

Templates¶

Name: The name that the lists show.
Analysis type: The jobs to run. See Jobs.
Coding standard: The identifier of a standard, for example misra-c-2012. The result holds compliance rows when this field has a value, and no compliance rows when it is empty.
Standard rule texts: The path to the rule texts of the standard, on the machine of the analyser. The field is optional.
Workspace: The workspace to analyse.
Analyzer: The analyser build to deploy. Midair offers the builds that match the architecture and the operating system of the node of the workspace.
Notes: Free text.
Planned runs: The schedule. It has the same shape as the test schedule. See Planned runs.

Jobs¶

An analysis record names the jobs that the analyser runs. A record that selects nothing runs the default set.

Defects: The findings that the issue list shows. A finding names a file, a line, a severity, a rule and an explanation.
Dependencies: The global symbols and the call map. Midair reduces them to what the workspace offers and what it asks for. See Exports, imports and workspace links.
Authors: The authors of the flagged code, read from git blame, with the facts of each commit.
SBOM: The dependency manifest: the packages, their licences, and the known advisories against them.
Metrics: The code metrics for each function: cyclomatic complexity, cognitive complexity, nesting depth and others.

Suspicious places¶

A finding states a defect. A suspicious place states that the code decides something, and that nobody has confirmed the decision. The analyser keeps the two apart, and so does Midair: a suspicious place is never counted as a finding, and it never changes whether a run passes.

Turn the mode on with Report suspicious places on the analysis template. The run then carries a second list beside the findings.

Each entry holds:

Category: The kind of observation. security holds the code that a reviewer always reads: a password or secret check, an access decision, a sign-in, a cryptographic primitive, a token, a change of privilege. The other categories hold code that looks unusual: copy-paste, boundary, error-handling, concurrency, api-shape, type-mixing, inconsistency, magic-value, dead-ish, complexity, naming and todo.
Confidence: high, medium or low. The run reports high and medium. Include low confidence adds the third one, which is an inventory rather than a shortlist.
Rule: The rule that reported it, for example visao/suspicious/security/password-check.
Two sentences: What looks unusual, and what a reader has to check.
Position and code: The file, the line range, and the lines of code around the construct.

Categories restricts the request to the categories that you select. An empty selection asks for every category. A security review selects security and nothing else: the naming complaints of a large tree crowd out the access decisions.

The security category answers a different question from the others. The other rules state that the code looks unusual. The security rules state that the code decides something, and that a reader must confirm the decision. A password check with no defect in it is the place where a mistake stays invisible, so the analyser lists it each time.

The suspicious places are what an attack vector plans from.

An analyser older than this option ignores it and reports findings only. The run then shows an empty list, and says so.

The findings viewer¶

Open a finished run and press Open findings viewer. The viewer has two panes. The left pane holds the source tree of the workspace, as the analysis saw it. The right pane holds one file, with each finding written under the line that it refers to.

The viewer reads the tree at the revision that the run recorded. A checkout that has moved on since the run does not change what the viewer shows.

Exports, imports and workspace links¶

The dependency job reports every global symbol that the analyser saw. Midair sorts them into four lists:

exports: Defined here, and visible outside the translation unit.
imports: Called here, and defined somewhere else.
locals: Defined here, and private to the file.
libs: The standard library and the compiler builtins.

Two workspaces relate through the first two lists. One workspace depends on another when a name that the first imports is a name that the second exports.

Midair recomputes the whole graph after each analysis, because an edge is a fact about a pair of workspaces. An edge can appear without either workspace changing.

The standard library is not an import for this purpose. Every C program calls memcpy, so a graph that counted it would relate every workspace to every other one.

A name that more than one workspace exports cannot decide an edge on its own. Midair counts such names separately, and they add nothing to the weight of an edge.

Review¶

Midair can ask an AI provider for a short engineering assessment of a finished analysis. The answer has a fixed shape: a few bullet points and one line that starts with Verdict:. The run header shows that line, and it shows the rest on demand.

Set the provider under Settings, then Integrations, then AI. See AI providers.