microsoft / clang-tools-extra Goto Github PK

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

When running clang-tidy-9 using the script run-clang-tidy-9.py, with these command:

run-clang-tidy-9.py -header-filter='.' -checks='-,readability-identifier-naming' -fix -config="{CheckOptions: [ {key: readability-identifier-naming.ClassCase, value: CamelCase}, {key: readability-identifier-naming.StructCase, value: CamelCase}, {key: readability-identifier-naming.TypedefCase, value: CamelCase}, {key: readability-identifier-naming.VariableCase, value: lower_case}, {key: readability-identifier-naming.ParameterCase, value: camelBack}, {key: readability-identifier-naming.FunctionCase, value: camelBack}, {key: readability-identifier-naming.NamespaceCase, value: lower_case}, {key: readability-identifier-naming.GlobalConstantCase, value: UPPER_CASE}, {key: readability-identifier-naming.EnumCase, value: CamelCase} ]}"

"make_shared" was changed to "makeShared" and "allocated_shared" was changed to "AllocatedShared".

Maybe a list of exceptions / reserved function names?

Explicit constructor check fix is wrong when already specified explicit(false) on that constructor

struct A {};

struct B {
  explicit(false) B(A) {}
};

The checker tries to fix it with adding a new explicit keyword which makes compilation error.

struct A {};

struct B {
  explicit(false) explicit B(A) {}
};

No warning/error should exist when specifying the explicit(false) attribute.

[llvm-header-guard] check does not seem to handle Windows style file paths with "" rather than "/" correctly. It reports errors even on correctly formatted guards, and generated wrong fixup guards.
Fix this issue.

clang-tidy reports [llvm-include-order] failures even though the #includes are sorted per LLVM convention. This is likely to be a Windows-specific issue. Investigate and fix the problem.

I am currently using the CXX_CLANG_TIDY functionality in CMake to add clang-tidy to targets. I have one file that is generated during the build that is out of my control that generates warnings for which I would like to suppress. I have tried the two line filters below but neither seem to change anything the header still produces warnings. Is my approach incorrect?

The file that contains the header that I would like to suppress:

#include <tesseract_monitoring/EnvironmentMonitorDynamicReconfigureConfig.h>

Line Filter Tried:

-header-filter=.* -line-filter=[{"name":"tesseract_monitoring/EnvironmentMonitorDynamicReconfigureConfig.h"}]

and

-header-filter=.* -line-filter=[{"name":"EnvironmentMonitorDynamicReconfigureConfig.h"}]

clang-tidy.exe intermittently crashes with the following assertion failure
[both release and debug builds on X64]

D:\3\llvm\include\llvm\ADT\IntrusiveRefCntPtr.h:79
assert (ref_cnt > 0 && "Reference count is already zero.");

Repro: clang-tidy -checks=* file.c -- failed intermittently on almost all input files.
For example file.c = int main() { return 1+1; }

Warning Clang : do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead.

m_pCmdLine = new CCommandLine(m_lpCmdLine); // warning

// CCommandLine Headerfile
CCommandLine(LPTSTR lpCmdLine)

I run clang as a check on an MFC project I work on. Why does it give me a warning when making a copy of a Long Pointer to a TStr? What explicit cast does it wants from me to fix this warning?