I am trying to use ClangTidy on some working source code but I cannot get it to ignore / bypass lib{fmt} and see lots of noise such as:
~/.conan/data/fmt/9.1.0///package/2c09c8f84c016041549fcee94e4caae5d89424b6/
include/fmt/core.h:2955:15: warning: 5 uninitialized fields at the end of
the constructor call [clang-analyzer-optin.cplusplus.UninitializedObject]
types_{
^
~/.conan/data/fmt/9.1.0///package/2c09c8f84c016041549fcee94e4caae5d89424b6/
include/fmt/core.h:732:7: note: uninitialized field
'this->context_.num_args_'
int num_args_;
^~~~~~~~~
I am using CMake + Conan and the diagnostic messages I have come from lib{fmt}.
How can I silence them? For CppCheck it was simply a case of specifying that all files under ~/.conan/ should be ignored.
How do I tell Clang-tidy to ignore all files under ~/.conan/
Note I have seen clang-tidy - ignore third party headers code which does not answer my question
Related
I'm currently working on a university assignment where it is mandated that we use C-style arrays for our code. Infuriatingly, they have left the default setting for warning about C-style arrays, which means that every time I use a one I need to add a // NOLINTNEXTLINT(modernize-avoid-c-arrays), which is absolutely terrible in terms of readability.
I have tried silencing the errors using // NOLINTBEGIN(modernize-avoid-c-arrays), but since that was only introduced in clang-tidy-14, it isn't supported by our course-mandated clang-tidy-11.
As such, my only option for a clean way of silencing these errors is by modifying the configuration file. Unfortunately, I haven't found any information on how to silence errors of a particular type in the configuration file. In fact, I haven't found any documentation on the expected structure of the .clang-tidy file at all, except for some example files, none of which appear to silence any errors.
How can I silence the modernize-avoid-c-arrays error on a project-wide basis from my .clang-tidy file?
Disable a check
To disable a check in .clang-tidy, add a Checks: line, and as its
value put the name of the check, preceded by a hyphen (meaning to
disable rather than enable). For example, here is a complete
.clang-tidy file that first enables all of the modernize-* checks
(since they are not enabled by default), then disables
modernize-avoid-c-arrays:
Checks: 'modernize-*,-modernize-avoid-c-arrays'
Documentation of .clang-tidy format
The .clang-tidy format is (tersely!) specified in the
output of clang-tidy --help:
--config-file=<string> -
Specify the path of .clang-tidy or custom config file:
e.g. --config-file=/some/path/myTidyConfigFile
This option internally works exactly the same way as
--config option after reading specified config file.
Use either --config-file or --config, not both.
However, the --config-file option and its documentation are missing
in Clang+LLVM-11, so that may be why you didn't find it. They are in
Clang+LLVM-14 (I'm not sure which version introduced that option).
Nevertheless, Clang+LLVM-11 responds to the presence of .clang-tidy.
You can use the --dump-config option to have clang-tidy print its
current configuration in the .clang-tidy syntax, then trim or edit as
desired.
Related:
github gist: A general clang-tidy configuration file
SO question: Clang Tidy config format
Complete example
Input source code:
// test.cpp
// Test input for clang-tidy.
void f()
{
int arr[3];
bool b = 1;
}
// EOF
Run using the above .clang-tidy:
$ /home/scott/opt/clang+llvm-11.0.1-x86_64-linux-gnu-ubuntu-16.04/bin/clang-tidy test.cpp --
1 warning generated.
/home/scott/wrk/learn/clang/clang-tidy-config/test.cpp:7:12: warning: converting integer literal to bool, use bool literal instead [modernize-use-bool-literals]
bool b = 1;
^
true
Without disabling modernize-avoid-c-arrays, two warnings would be
printed. (And without enabling modernize-*, nothing is printed.)
Note December 2022: it seems that this problem is solved in clang-tidy 14. Just by experimentation I can reproduce the problem with clang-tidy 11, 12 and 13 but not with 14.
I have a Cmake project that uses Boost.UnitTest for testing.
When I do static analysis with clang-tidy it reports some warnings from the Boost.UnitTest headers. I would like to filter those.
As an example (disregard detaisl)
/usr/include/boost/test/tools/old/interface.hpp:84:45: note: expanded from macro 'BOOST_REQUIRE'
#define BOOST_REQUIRE( P ) BOOST_TEST_TOOL_IMPL( 2, \
^
/usr/include/boost/test/tools/old/interface.hpp:65:5: note: expanded from macro 'BOOST_TEST_TOOL_IMPL'
BOOST_TEST_PASSPOINT(); \
^
/usr/include/boost/test/unit_test_log.hpp:261:5: note: expanded from macro 'BOOST_TEST_PASSPOINT'
::boost::unit_test::unit_test_log.set_checkpoint( \
^
/usr/include/boost/test/unit_test_log.hpp:209:82: note: default parameter was declared here
void set_checkpoint( const_string file, std::size_t line_num, const_string msg = const_string() );
^
/home/user/prj/alf/boost/multi/test/zero_dimensionality.cpp:23:3: error: calling a function that uses a default argument is disallowed [fuchsia-default-arguments-calls,-warnings-as-errors]
BOOST_REQUIRE( num_elements(m1) == 3 );
So far, I add the dependency on Boost.UnitTest with these lines
target_link_libraries(${TEST_EXE} PRIVATE Boost::unit_test_framework Boost::serialization)
I tried with this, to make Boost.UnitTest a "system" library but I still get the same warnings
target_include_directories(${TEST_EXE} SYSTEM PRIVATE ${Boost_INCLUDE_DIRS})
target_link_libraries(${TEST_EXE} PRIVATE ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY})
target_link_libraries(${TEST_EXE} PRIVATE ${Boost_SERIALIZATION_LIBRARY})
but I still get the same results.
How can I prevent clang-tidy to check or report errors in the Boost headers?
(I accept answers changing the configuration of clang-tidy itself (I used a .clang-tidy configuration file); although it seems more elegant to change CMakeLists.txt instead.)
ADDED NOTE:
Following one of the recommendations in the comments I disabled these warnings that were "incompatible" with Boost.Test.
I would still prefer to leave them on and make clang-tidy filter somehow the headers of Boost.Test:
# -altera-unroll-loops, // BOOST_REQUIRE macro requires this
# -cert-err58-cpp, // BOOST_AUTO_TEST_CASE macro requires this
# -cppcoreguidelines-avoid-non-const-global-variables, // BOOST_AUTO_TEST_CASE macros require this
# -cppcoreguidelines-macro-usage, // BOOST_TEST_MODULE macro requires this
# -cppcoreguidelines-pro-type-vararg, // BOOST_REQUIRE macros require this
# -fuchsia-default-arguments-declarations // BOOST_AUTO_TEST_CASE_TEMPLATE
# -fuchsia-default-arguments-calls, // BOOST_REQUIRE macros require this
# -fuchsia-statically-constructed-objects, // BOOST_AUTO_TEST_CASE creates these
# -hicpp-vararg, // all BOOST_TEST_REQUIRE macros require this
Okay, I't not entirely clear (to me) from this:
I do CXX=clang++ cmake .. -DCMAKE_CXX_CLANG_TIDY="clang-tidy" (plus a configuration file for clang-tidy)
how or when clang-tidy is actually invoked. Apparently that uses some CMake magic I'm not familiar with. I do remember once seeing such a thing, and there were reasons why I didn't end up using it.
Instead, I use CMAKE_EXPORT_COMPILE_COMMANDS=On (very handy for all tooling based on libclang and then some, like IDEs and LSP servers). Having the compile_commands.json makes it so you can invoke the run-clang-tidy tool with -p pointing to it.
In my experience it does filter system includes as it ought to (and it gives a count of diagnostics suppressed in verbose modes).
If you use macros from a library which incur clang-tidy warnings, I don't think there's a good way to avoid it today. Even if you include the library as a system library (e.g., via -isystem) my understanding is the warnings will still trigger because the macro is used in your code, even if it is declared in the library.
Here's a proposal to fix it, unfortunately it seems stalled since 2021.
Solution: use clang-tidy 14 or newer.
I am working in a project dependent of Boost (http://kratos-wiki.cimne.upc.edu/index.php/Main_Page), this project currently only supports C++03. With the last update of gcc++ (v.5) the C++11 has become the default std, technically I solved the problem modifying the CXX_FLAGS adding:
-std=c++03
The problem comes with the Boost library, which I am not able to compile with the C++03 std (I think, I don't know how to check with which std I have compiled). I tried employing the following command to compile Boost:
./b2 install stage --with-python --with-serialization cxxflags="-std=c++03"
I have tried too modify the Jamroot file, adding the following lines:
<toolset>gcc:<cxxflags>-std=gnu++03
<toolset>clang:<cxxflags>-std=c++03
But the problem persist, when I compile the whole project I obtain the following kind of warning (several times):
/usr/local/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated
# pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
That's why I suspect that my changes do not take effect.
Thank you very much for your help
I think you can safely ignore those warnings for now. I am compiling boost 1_60_0 with gcc 5.2.1 and std=c++11, and I get the same warnings. There is a ticket on it, but meanwhile it hasn't caused me any problems at this time. I commented out the two [#pragma warning] lines in the boost code, so I don't get a lot of distracting output in my build:
boost/type_traits/detail/template_arity_spec.hpp line 13:
// noisy: # pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
boost/type_traits/detail/bool_trait_def.hpp line 18:
// noisy: # pragma message ("NOTE: Use of this header (bool_trait_def.hpp) is deprecated")
UPDATE The problem still exists in boost 1.61.0. I used the same exact fix again.
I'm following the instructions from INSTALL.W32 (various OpenSSL versions), in general it's:
* Configure for building with Borland Builder:
> perl Configure BC-32
* Create the appropriate makefile
> ms\do_nasm
* Build
> make -f ms\bcb.mak
Now, I do get two kind of errors when trying to build:
For OpenSSL < 1.0.0
nasmw -f obj -d__omf__ -ocrypto\md5\asm\m5_win32.obj .\crypto\md5\asm\m5_win32.asm
'nasmw' is not recognized as an internal or external command,
operable program or batch file.
Otherwise
Warning W8017 C:\CBuilder5\Include\sys/stat.h 34: Redefinition of 'S_IFMT' is not identical
Warning W8017 C:\CBuilder5\Include\sys/stat.h 35: Redefinition of 'S_IFDIR' is not identical
Error E2227 .\crypto\rand\randfile.c 226: Extra parameter in call to _open in function RAND_write_file
Warning W8053 .\crypto\rand\randfile.c 262: '_chmod(const signed char *,int,...)' is obsolete in function RAND_write_file
*** 1 errors in Compile ***
Yes, I feel bad for using Borland C++ Builder 5 but I can't do anything about it, and yes, I consider the Shining Light option if everything else fails.
I do not use OpenSSL but from your text some hints:
NASM
is not default assembler for Borland compilers
you need to download and install it first
(it is for free and one of the best compilers I used in the past)
you are missing some #define before including OpenSSL or including in wrong order
that is why you have the first warnings and most likely also the error
some libs need to add configuration #defines (added by some specific IDE's)
to specify what compiler,platform,endianess... is used
before any includes
usually if you include in wrong order then the defines are defined for some instances of a lib file but not for all
so try to reorder the includes
sometimes helps to include before the lib some other thing like conio,stdio,windows,...
to determine which define is missing or wrong open the stat.h
and look for #ifdef #ifndef statements around S_IFMT
The solution for the newest version (1.0.2d) was to:
remove the extra parameter from randfile (which, as comment stated, was unnecessary),
edit ms\bcb.mak, search for -DMD5_ASM -DSHA1_ASM -DRMD160_ASM
and change to -DMD5_NO_ASM -DSHA1_NO_ASM -DRMD160_NO_ASM . (there was an unresolved external error with SHA, MD5 and RMD160, they basically couldn't be compiled in asm).
There were some other steps included as well, but they're just specific to my environment.
I am using PC-lint on windows PC( platform) .
I am running my code but getting this errors/warning and after some percentage of running my code is getting crashed .All errors are related to linting only .
Warnings:
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\usertype.h(118): Note 960: Violates MISRA 2004 Required Rule 10.6, Unsigned integer literals require a 'U' suffix
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\usertype.h(145): Note 960: Violates MISRA 2004 Required Rule 10.6, Unsigned integer literals require a 'U' suffix
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\socket.h(53): Note 960: Violates MISRA 2004 Required Rule 10.6, Unsigned integer literals require a 'U' suffix
C:\Program Files\Texas Instruments\ndk_x_xx_xx_xxx\packages\ti\ndk\inc\socket.h(159): Note 970: Use of modifier or type 'int' outside of a typedef [MISRA 2004 Rule 6.3] ......
As I cannot modify that ndk package .So I want to exclude that files from my linting process ...I got some old answers from stack Overflow but these are related with source files not for header files .
I am having problem in header files like usertype.h and socket.h etc etc
i tried to put -efile(960,usertype.h) option in my lint.lnt file but issue was still there .
Can you please tell me the solution for this ???
-Ashwin
If you get warnings numbered 900 and above, you are running on warning level 4, which is far too high for normal operation. I would start on warning level 1 (syntax only) and make sure everything runs properly. Then you can increase to 2 or 3, and selectively enable some individual warnings from the range 900+ and/or 1900+.
To skip certain parts in the checking process, simply remove the c/c++ source files from the configuration or command line. But make sure to retain the directories as include directories, since other files will need to include those interface headers.
The option -efile is not intended to suppress warnings within a file, but rather to suppress warnings about a file. Look in the description of the option in the manual for details.
The way to limit warnings in source code you are not responsible for is to declare that source code to be 'libraries'. The whole chapter 6 of the PC-Lint manual is devoted to this subject. You can start with -wlib(1) to use warning level 1 (syntax only) for library files, then define what you want to be considered library files with +libclass, +-libdir, and +-libh options. And if you want to see if a certain include file is considered to be a 'library'-header, run PC-Lint with the option -vf.