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

clang-tidy tool reports warnings generated by gcc

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      A bit related to JENKINS-64612. The clang-tidy tool reports warnings generated by gcc.

      This is a bigger problem than it may seem. You could argue "well, just put them in different files for different tools to parse", but a common way to run clang-tidy is via cmake as 

      cmake -DCMAKE_CXX_CLANG_TIDY=clang-tidy .. && cmake --build .

      Meaning both the clang-tidy and gcc warnings are generated as a result of the same command being executed. This can't be separated (https://discourse.cmake.org/t/run-clang-tidy-only/2537), and has benefits over other ways of running clang-tidy (only check the files that have changed in incremental builds).

      In the same way JENKINS-64612 argues for only including warnings with a "-W" in them, here I would like to argue that the clang-tidy tool should filter-out the warnings with a "-W" in them.

      In fact, as of clang-tidy 11.0.0, the only categories clang-tidy reports are:

      abseil-*
      android-*
      boost-*
      bugprone-*
      cert-*
      clang-analyzer-*
      cppcoreguidelines-*
      darwin-*
      fuchsia-*
      google-*
      hicpp-*
      linuxkernel-*
      llvm-*
      llvmlibc-*
      misc-*
      modernize-*
      mpi-*
      objc-*
      openmp-*
      performance-*
      portability-*
      readability-*
      zircon-*

      (none of them starting with "-W").

       

        Attachments

          Activity

          reddwarf94 Cristian created issue -
          reddwarf94 Cristian made changes -
          Field Original Value New Value
          Description A bit related to JENKINS-64612. The clang-tidy tool reports warnings generated by gcc.

          This is a bigger problem than it may seem. You could argue "well, just put them in different files for different tools to parse", but a common way to run clang-tidy is via cmake as

           
          {noformat}
          cmake -DCMAKE_CXX_CLANG_TIDY=clang-tidy .. && cmake --build .{noformat}
          Meaning both the clang-tidy and gcc warnings are generated as a result of the same command being executed. This can't be separated ([https://discourse.cmake.org/t/run-clang-tidy-only/2537]), and has benefits over other ways of running clang-tidy (only check the files that have changed in incremental builds).

          In the same way JENKINS-64612 argues for only including warnings with a "-W" in them, here I would like to argue that the clang-tidy tool should filter-out the warnings with a "-W" in them.

          In fact, as of clang-tidy 11.0.0, the only categories clang-tidy reports are:
          {noformat}
          abseil-*
          android-*
          boost-*
          bugprone-*
          cert-*
          clang-analyzer-*
          cppcoreguidelines-*avoid-c-arrays
          darwin-*
          fuchsia-*
          google-*
          hicpp-*
          linuxkernel-*
          llvm-*
          llvmlibc-*
          misc-*
          modernize-*
          mpi-*
          objc-*
          openmp-*
          performance-*
          portability-*
          readability-*
          zircon-*{noformat}
          (none of them starting with "-W").

           
          A bit related to JENKINS-64612. The clang-tidy tool reports warnings generated by gcc.

          This is a bigger problem than it may seem. You could argue "well, just put them in different files for different tools to parse", but a common way to run clang-tidy is via cmake as 
          {noformat}
          cmake -DCMAKE_CXX_CLANG_TIDY=clang-tidy .. && cmake --build .{noformat}
          Meaning both the clang-tidy and gcc warnings are generated as a result of the same command being executed. This can't be separated ([https://discourse.cmake.org/t/run-clang-tidy-only/2537]), and has benefits over other ways of running clang-tidy (only check the files that have changed in incremental builds).

          In the same way JENKINS-64612 argues for only including warnings with a "-W" in them, here I would like to argue that the clang-tidy tool should filter-out the warnings with a "-W" in them.

          In fact, as of clang-tidy 11.0.0, the only categories clang-tidy reports are:
          {noformat}
          abseil-*
          android-*
          boost-*
          bugprone-*
          cert-*
          clang-analyzer-*
          cppcoreguidelines-*
          darwin-*
          fuchsia-*
          google-*
          hicpp-*
          linuxkernel-*
          llvm-*
          llvmlibc-*
          misc-*
          modernize-*
          mpi-*
          objc-*
          openmp-*
          performance-*
          portability-*
          readability-*
          zircon-*{noformat}
          (none of them starting with "-W").

           
          drulli Ulli Hafner made changes -
          Assignee Ulli Hafner [ drulli ]
          Labels help-wanted

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            reddwarf94 Cristian
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: