How to navigate to clazy warning in Qt Creator?

by

Summary

A misalignment between Qt Creator’s diagnostic ingestion pipeline and clazy’s export‑fixes behavior prevents non‑fixit clazy warnings from appearing in the Issues pane. Qt Creator only displays diagnostics that arrive through its structured export‑file mechanism, but clazy emits structured data only for warnings that have fixits, leaving all other warnings stranded in the Application Output pane.

Root Cause

The underlying issue is that Qt Creator relies on YAML export files (the same mechanism used by clang‑tidy) to populate its Diagnostics/Issues panes.
However:

  • clazy‑standalone does not export YAML unless a fixit exists
  • Qt Creator does not parse raw stderr/stdout text from clazy
  • clang‑tidy exports all diagnostics, so its warnings appear correctly
  • clazy-as-clang-tidy plugin works, because clang‑tidy handles the export layer

The result is a mismatch: Qt Creator expects structured diagnostics, but clazy does not provide them for most checks.

Why This Happens in Real Systems

This pattern is common when integrating heterogeneous static‑analysis tools:

  • Tools often emit human-readable output, but IDEs require machine-readable formats
  • Some analyzers implement partial support for structured output (e.g., only for fixits)
  • IDEs avoid parsing raw text because it is unstable and tool‑specific
  • Integration layers evolve at different speeds, leaving gaps in feature parity

Real-World Impact

This leads to several practical problems:

  • Missing warnings in the Issues pane, reducing visibility
  • Inconsistent developer experience between clang‑tidy and clazy
  • Navigation only works for fixit‑capable warnings
  • False assumption that Qt Creator is misconfigured, when the limitation is upstream

Example or Code (if necessary and relevant)

A typical clazy export attempt:

clazy-standalone --checks=connect-by-name \
  -p debug/.qtc_clangd/compile_commands.json \
  dialog.cpp --export-fixes=f.yaml

If the warning has no fixit, f.yaml is never created.

How Senior Engineers Fix It

Experienced engineers work around the limitation using one of these approaches:

  • Use clazy through clang‑tidy
    Load clazy as a clang‑tidy plugin (-load=ClazyClangTidy.so).
    This forces clang‑tidy to generate full YAML diagnostics, including non‑fixit warnings.

  • Configure a .clang-tidy file
    Although not all clazy checks work here, the ones that do will export properly.

  • Run clazy externally and treat it as a separate report
    Integrate clazy output into CI pipelines rather than relying on Qt Creator.

  • Patch or extend Qt Creator
    Some teams add custom parsers for clazy output, but this requires modifying Qt Creator’s source.

  • Wait for upstream improvements
    Both Qt Creator and clazy have open issues regarding structured diagnostic export.

Why Juniors Miss It

Less experienced developers often assume:

  • “If the tool prints warnings, the IDE should show them.”
    They don’t yet know that IDEs require structured formats.

  • “Qt Creator must be misconfigured.”
    They overlook that the limitation is in clazy’s export mechanism, not Qt Creator.

  • “All clang-based tools behave the same.”
    They don’t realize clazy is not a drop‑in replacement for clang‑tidy.

  • “Fixit support is optional.”
    They miss that fixits are the trigger for YAML export in clazy.

If you want, I can also generate a companion article explaining how Qt Creator’s diagnostic ingestion pipeline works internally.

Leave a Comment