How do I dump gcc warnings into a structured format?

Question

Like many, I build my project with the an abundance of warning flags.
Since not all warning flags are detrimental, the compilation becomes noisy.

Warnings such as "unused variables", "shadowing members in initialization lists", "missing switch defaults", are all important to log, but they create too much clutter during builds, and it is hard to spot the important warnings.

Given a large project, there can be thousands of warnings mixed in with build statements, and parsing though it afterwards becomes burdensome. It's equally undesirable to maintain compiler pragmas and push/pop warnings inside code.

How can I dump compiler warnings in a structured format?
Whether it be XML, JSON, YAML, CSV, is there a way to tell the compiler to dump all emitted warnings? A format like this would allow me to view warnings more efficiently, and sort them by type, file, amount, etc.

My suggestion: Disable the "unused" warnings, and fix everything else. — Kerrek SB, Apr 15 '16 at 22:35
Where I work 0 warnings are tolerated, for just this reason. Allowing your code to have warnings shows a lack of pride in your work, and is unprofessional. Warnings are detrimental in that it shows the author has little care for the quality of his/her work, and this means the entire code-base is suspect and probably full of bugs. In answer to your question, there are many scripting languages that can parse your compiler log and filter your 'acceptable' warnings, leaving your 'unacceptable' warnings for your viewing pleasure. — dgsomerton, Apr 16 '16 at 00:02

score 7 · Accepted Answer · answered Mar 18 '19 at 11:14

GCC 9 added[1] support for outputting warnings and error messages in JSON format, just use -fdiagnostics-format=json option.

Compare the output of

$ gcc-9 -c cve-2014-1266.c -Wall
cve-2014-1266.c: In function ‘SSLVerifySignedServerKeyExchange’:
cve-2014-1266.c:629:2: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
  629 |  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
      |  ^~
cve-2014-1266.c:631:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’
  631 |   goto fail;
      |   ^~~~

with JSON-formatted one:

[
    {
        "children": [
            {
                "kind": "note",
                "locations": [
                    {
                        "caret": {
                            "column": 3,
                            "file": "cve-2014-1266.c",
                            "line": 631
                        },
                        "finish": {
                            "column": 6,
                            "file": "cve-2014-1266.c",
                            "line": 631
                        }
                    }
                ],
                "message": "...this statement, but the latter is misleadingly indented as if it were guarded by the \u2018if\u2019"
            }
        ],
        "kind": "warning",
        "locations": [
            {
                "caret": {
                    "column": 2,
                    "file": "cve-2014-1266.c",
                    "line": 629
                },
                "finish": {
                    "column": 3,
                    "file": "cve-2014-1266.c",
                    "line": 629
                }
            }
        ],
        "message": "this \u2018if\u2019 clause does not guard...",
        "option": "-Wmisleading-indentation"
    }
]

[1] https://developers.redhat.com/blog/2019/03/08/usability-improvements-in-gcc-9/

I am wondering if `ld` is possible to report linking errors in JSON as well, or we will have to wait for an update. I can't find anything mentioned of this in the `--help` / man either. — dza, Aug 28 '20 at 13:34

score 5 · Answer 2 · answered Oct 13 '16 at 13:10

The coala project attempts to make the tools it wraps produce the same structured output formats (see http://wordpress.schuirmann.eu/2016/02/coala-at-fosdem-2016/#comment-123 ). Sadly there doesn't seem to be an already made "bear" to wrap a compiler.
On a similar note to the above, Ericsson have built a tool called CodeChecker that lets you track a project's clang static analysis warnings over time.
There is an moribund project called firehose that wrapped the output of gcc and several C static analysis tools.
clang has -fdiagnostics-format=msvc which can make its output slightly more structured.

Something that might help you in the meantime is to turn those compiler warnings you deem critical into errors using -Werror= so you notice them breaking the build above the noise of the warnings.

How do I dump gcc warnings into a structured format?

2 Answers2

Linked