Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64612

clang-tidy warnigns are reported as gcc warnings

      From a quick look it looks like recent gcc warnings are formatted as: 

      <file>:<line>:<column>: warning: <message> [-W<warning_command>]

      while clang-tidy warnings are formatted as:

      <file>:<line>:<column>: warning: <message> [<clang-tidy check>]

      So gcc warnings can be differentiated by the "-W".

      My understanding of https://github.com/jenkinsci/analysis-model/blob/master/src/main/java/edu/hm/hafner/analysis/parser/Gcc4CompilerParser.java#L23 is that it accepts lines with anything after "warning: ". Looking in https://godbolt.org/ it looks like the "[-W<warning_command>]" was not added until gcc 4.6, which would explain this.

      So maybe there is a need for a new "gcc46+" "tool" in Warnings NG / parser in analysis-model?

      Additionally, looking in godbolt, I see clang has used the exact same 

      <file>:<line>:<column>: warning: <message> [-W<warning_command>]

      format since at least clang 3.0.0 (the oldest available version in godbolt). But

      • The clang tool also includes clang-tdy warnings
      • In my codebase (building for multiple toolchains, mostly gcc-based but also for Android/clang) the clang tool reports 58 warnings while the gcc4 tool reports 119 warnings
      • The parsers in analysis model are very different (one based on RegexpLineParser and the other on LookaheadParser) 

      Since I mix clang and gcc builds in my Jenkins jobs, and given that the gcc and clang formats seem to have been identical at least since 2011 (gcc 4.6.0 and clang 3.0 releases) it would be nice if I could use a single "modern gcc/clang" tool to detect the warnings of both.

          [JENKINS-64612] clang-tidy warnigns are reported as gcc warnings

          Ulli Hafner added a comment -

          Yes, this makes sense to update these parsers (or to introduce new ones) that work better on the modified formats.

          Ulli Hafner added a comment - Yes, this makes sense to update these parsers (or to introduce new ones) that work better on the modified formats.

          Cristian added a comment - - edited

          FWIW I have started using a custom groovy parser. I'm using

          (.+):(\d+):(\d+): warning: (.*) \[-W(.*)\]
          

          with this mapping script

          return builder.setFileName(matcher.group(1))
                             .setLineStart(matcher.group(2))
                             .setColumnStart(matcher.group(3))
                             .setMessage(matcher.group(4))
                             .setCategory(matcher.group(5))
                             .buildOptional()
          

          Not only it avoids the clang-tidy warnings, I have also found it avoids problems with https://github.com/jenkinsci/analysis-model/blob/d1b967a1fa8c365a82c7328648bc6f6039cd2b91/src/main/java/edu/hm/hafner/analysis/parser/Gcc4CompilerParser.java#L70 which has a tendency to incorrectly include extra lines with modern gcc versions.

          Cristian added a comment - - edited FWIW I have started using a custom groovy parser. I'm using (.+):(\d+):(\d+): warning: (.*) \[-W(.*)\] with this mapping script return builder.setFileName(matcher.group(1)) .setLineStart(matcher.group(2)) .setColumnStart(matcher.group(3)) .setMessage(matcher.group(4)) .setCategory(matcher.group(5)) .buildOptional() Not only it avoids the clang-tidy warnings, I have also found it avoids problems with https://github.com/jenkinsci/analysis-model/blob/d1b967a1fa8c365a82c7328648bc6f6039cd2b91/src/main/java/edu/hm/hafner/analysis/parser/Gcc4CompilerParser.java#L70 which has a tendency to incorrectly include extra lines with modern gcc versions.

          From a quick look it looks like recent gcc warnings are formatted as:
          <file>:<line>:<column>: warning: <message> [-W<warning_command>]

          Unfortunately that does not cover all cases. Some gcc warnings don't have the [-W<warning_command>] portion, others contain [enabled by default] without -W.

          Davide Pesavento added a comment - From a quick look it looks like recent gcc warnings are formatted as: <file>:<line>:<column>: warning: <message> [-W<warning_command>] Unfortunately that does not cover all cases. Some gcc warnings don't have the [-W<warning_command>] portion, others contain [enabled by default] without -W .

          Cristian added a comment -

          > Unfortunately that does not cover all cases. Some gcc warnings don't have the [-W<warning_command>] portion, others contain [enabled by default] without -W.

          Do you have an example?

          In the following example, warnings enabled by default do follow the format

          bash-5.2# gcc --version
          gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4)
          Copyright (C) 2023 Free Software Foundation, Inc.
          This is free software; see the source for copying conditions.  There is NO
          warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.bash-5.2# clang --version
          clang version 16.0.5 (Fedora 16.0.5-1.fc38)
          Target: x86_64-redhat-linux-gnu
          Thread model: posix
          InstalledDir: /usr/bin
          bash-5.2# cat test.cpp 
          void f(int *a, int b, int c) { a[b, c]; }
          bash-5.2# g++ -c -std=gnu++20 -o test.o test.cpp
          test.cpp: In function 'void f(int*, int, int)':
          test.cpp:1:35: warning: top-level comma expression in array subscript is deprecated [-Wcomma-subscript]
              1 | void f(int *a, int b, int c) { a[b, c]; }
                |                                   ^
          bash-5.2# clang++ -c -o test.o test.cpp
          test.cpp:1:34: warning: left operand of comma operator has no effect [-Wunused-value]
          void f(int *a, int b, int c) { a[b, c]; }
                                           ^
          test.cpp:1:38: warning: expression result unused [-Wunused-value]
          void f(int *a, int b, int c) { a[b, c]; }
                                         ~ ~~~~^
          2 warnings generated.
          bash-5.2#

          Cristian added a comment - > Unfortunately that does not cover all cases. Some gcc warnings don't have the [-W<warning_command>] portion, others contain [enabled by default] without -W . Do you have an example? In the following example, warnings enabled by default do follow the format bash-5.2# gcc --version gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.bash-5.2# clang --version clang version 16.0.5 (Fedora 16.0.5-1.fc38) Target: x86_64-redhat-linux-gnu Thread model: posix InstalledDir: /usr/bin bash-5.2# cat test.cpp  void f(int *a, int b, int c) { a[b, c]; } bash-5.2# g++ -c -std=gnu++20 -o test.o test.cpp test.cpp: In function 'void f(int*, int, int)': test.cpp:1:35: warning: top-level comma expression in array subscript is deprecated [-Wcomma-subscript]     1 | void f(int *a, int b, int c) { a[b, c]; }       |                                   ^ bash-5.2# clang++ -c -o test.o test.cpp test.cpp:1:34: warning: left operand of comma operator has no effect [-Wunused-value] void f(int *a, int b, int c) { a[b, c]; }                                  ^ test.cpp:1:38: warning: expression result unused [-Wunused-value] void f(int *a, int b, int c) { a[b, c]; }                                ~ ~~~~^ 2 warnings generated. bash-5.2#

          Yeah, the "enabled by default" message is misleading. What it really means (afaik) is that there is no dedicated command-line option to turn off that particular warning.

          Two examples I've encountered:

          warning: non-ISO-standard escape sequence, '\e' [enabled by default]
          
          warning: inline function ‘...’ given attribute noinline [enabled by default]
          

          Davide Pesavento added a comment - Yeah, the "enabled by default" message is misleading. What it really means (afaik) is that there is no dedicated command-line option to turn off that particular warning. Two examples I've encountered: warning: non-ISO-standard escape sequence, '\e' [enabled by default] warning: inline function ‘...’ given attribute noinline [enabled by default]

            Unassigned Unassigned
            reddwarf94 Cristian
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: