[cfe-dev] clang-tidy: identify "C++-code-specific-checks" and "C-Code-specific-checks"

Oza, Hiral via cfe-dev cfe-dev at lists.llvm.org
Wed Sep 15 04:56:45 PDT 2021 

>> From list of supported clang-tidy checks, how to identify "C++-code-specific-checks" and which are "C-Code-specific-checks"? Can this be checked programmatically?
>There is not a way to identify them from the command line, but each check has an `isLanguageVersionSupported()` function that checks for valid language options that you can use to find this information via manual inspection.

>> What happens internally if C++-code-check ran on C-code? Will it skip parsing C-code?
> If the check is designed to be C++-only, then it will be skipped for a C translation unit.

Ok, I could see below LangOpts checks... from "clang-tools-extra/clang-tidy/ClangTidyCheck.h" could read that 'registerPPCallbacks()' and 'registerMatchers' gets executed if the function isLanguageVersionSupported returns true.

$ grep -ri isLanguageVersionSupported llvm-project/clang-tools-extra -A5 | grep LangOpt | grep -v isLanguageVersionSupported | cut -d' ' -f4- | sort -n | uniq
const LangOptions &LangOpts) const {
(LangOpts.CPlusPlus)
LangOpts.CPlusPlus11;
RequireCPlusPlus14 ? LangOpts.CPlusPlus14 : LangOpts.CPlusPlus11;
 return getLangOpts().CPlusPlus && getLangOpts().CXXExceptions;
 return LangOpts.Blocks;
 return LangOpts.Bool;
 return LangOpts.CPlusPlus;
     return LangOpts.CPlusPlus11;
 return LangOpts.CPlusPlus11;
 return LangOpts.CPlusPlus11 || LangOpts.C11;
 return LangOpts.CPlusPlus14;
 return !LangOpts.CPlusPlus17;
 return LangOpts.CPlusPlus17;
 return LangOpts.CPlusPlus && LangOpts.CXXExceptions;
 return LangOpts.CPlusPlus && !LangOpts.ObjC;
 return LangOpts.CPlusPlus && !LangOpts.ThreadsafeStatics;
 return LangOpts.ObjC;
 return LangOpts.ObjC && LangOpts.ObjCAutoRefCount;
 return LangOpts.OpenMP;
 return LangOpts.OpenMP && LangOpts.CPlusPlus && LangOpts.CXXExceptions;

>> Are “clang-analyzer-“ checks only applied to C++-code?
> Not always, those come from the static analyzer (rather than explicitly written as clang-tidy checks) and many of those apply to C code as well as C++ code (for example, there are checks specific to malloc/free behavior, checks for division by zero, etc).

I am seeing strange observation with clang-analyzer-* checks:
For example: if I run below command to list only single "clang-analyzer-apiModeling.StdCLibraryFunctions" but it list all other clang-analyzer-* checks too!

$ clang-tidy --version
  LLVM version 14.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu

$ clang-tidy --list-checks --config-file=<path>/config-file-clang-analyzer-apiModeling.StdCLibraryFunctions
Enabled checks:
    clang-analyzer-apiModeling.StdCLibraryFunctions
    clang-analyzer-core.CallAndMessage
    clang-analyzer-core.CallAndMessageModeling
    clang-analyzer-core.DivideZero
    clang-analyzer-core.DynamicTypePropagation
    clang-analyzer-core.NonNullParamChecker
    clang-analyzer-core.NonnilStringConstants
    clang-analyzer-core.NullDereference
    clang-analyzer-core.StackAddrEscapeBase
    clang-analyzer-core.StackAddressEscape
    clang-analyzer-core.UndefinedBinaryOperatorResult
    clang-analyzer-core.VLASize
    clang-analyzer-core.builtin.BuiltinFunctions
    clang-analyzer-core.builtin.NoReturnFunctions
    clang-analyzer-core.uninitialized.ArraySubscript
    clang-analyzer-core.uninitialized.Assign
    clang-analyzer-core.uninitialized.Branch
    clang-analyzer-core.uninitialized.CapturedBlockVariable
    clang-analyzer-core.uninitialized.UndefReturn

Where,
$ cat <path>/config-file-clang-analyzer-apiModeling.StdCLibraryFunctions
---
Checks: '
 -*,
 -clang-analyzer-*,
 -clang-analyzer-apiModeling-*,
 -clang-analyzer-core-*,
 -clang-analyzer-cplusplus-*,
 -clang-analyzer-deadcode-*,
 -clang-analyzer-fuchsia-*,
 -clang-analyzer-nullability-*,
 -clang-analyzer-optin-*,
 -clang-analyzer-osx-*,
 -clang-analyzer-security-*,
 -clang-analyzer-unix-*,
 -clang-analyzer-valist-*,
 -clang-analyzer-apiModeling.google.GTest,
 -clang-analyzer-apiModeling.llvm.CastValue,
 -clang-analyzer-apiModeling.llvm.ReturnValue,
 -clang-analyzer-apiModeling.StdCLibraryFunctions,
 -clang-analyzer-apiModeling.TrustNonnull,
 -clang-analyzer-core.builtin.BuiltinFunctions,
 -clang-analyzer-core.builtin.NoReturnFunctions,
 -clang-analyzer-core.CallAndMessage,
 -clang-analyzer-core.DivideZero,
 -clang-analyzer-core.DynamicTypePropagation,
 -clang-analyzer-core.NonnilStringConstants,
 -clang-analyzer-core.NonNullParamChecker,
 -clang-analyzer-core.NullDereference,
 -clang-analyzer-core.StackAddrEscapeBase,
 -clang-analyzer-core.StackAddressEscape,
 -clang-analyzer-core.UndefinedBinaryOperatorResult,
 -clang-analyzer-core.uninitialized.ArraySubscript,
 -clang-analyzer-core.uninitialized.Assign,
 -clang-analyzer-core.uninitialized.Branch,
 -clang-analyzer-core.uninitialized.CapturedBlockVariable,
 -clang-analyzer-core.uninitialized.UndefReturn,
 -clang-analyzer-core.VLASize,
 -clang-analyzer-cplusplus.Move,
 -clang-analyzer-cplusplus.PureVirtualCall,
 -clang-analyzer-cplusplus.SelfAssignment,
 -clang-analyzer-cplusplus.SmartPtr,
 -clang-analyzer-cplusplus.VirtualCallModeling,
 -clang-analyzer-nullability.NullableDereferenced,
 -clang-analyzer-nullability.NullablePassedToNonnull,
 -clang-analyzer-nullability.NullableReturnedFromNonnull,
 -clang-analyzer-nullability.NullPassedToNonnull,
 -clang-analyzer-nullability.NullReturnedFromNonnull,
 -clang-analyzer-optin.mpi.MPI-Checker,
 -clang-analyzer-optin.performance.GCDAntipattern,
 -clang-analyzer-security.FloatLoopCounter,
 -clang-analyzer-security.insecureAPI.decodeValueOfObjCType,
 -clang-analyzer-security.insecureAPI.getpw,
 -clang-analyzer-security.insecureAPI.gets,
 -clang-analyzer-security.insecureAPI.mkstemp,
 -clang-analyzer-security.insecureAPI.mktemp,
 -clang-analyzer-security.insecureAPI.SecuritySyntaxChecker,
 -clang-analyzer-security.insecureAPI.UncheckedReturn,
 -clang-analyzer-unix.cstring.BadSizeArg,
 -clang-analyzer-unix.cstring.CStringModeling,
 -clang-analyzer-unix.DynamicMemoryModeling,
 -clang-analyzer-valist.CopyToSelf,
 -clang-analyzer-valist.ValistBase,
 clang-analyzer-apiModeling.StdCLibraryFunctions'

Just enabled one "

Thanks Aaron.

-----Original Message-----
From: Aaron Ballman <aaron at aaronballman.com> 
Sent: Wednesday, 15 September, 2021 16:43
Cc: cfe-dev at lists.llvm.org; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [cfe-dev] clang-tidy: identify "C++-code-specific-checks" and "C-Code-specific-checks"

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




On Wed, Sep 15, 2021 at 3:09 AM Oza, Hiral via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>
> Greetings!
>
> We are using clang-tidy with single ‘config-file’ listing enabled tidy-checks to run for both “C++-code” and “C-code”.
>
> We are looking for your inputs:
>
> From list of supported clang-tidy checks, how to identify "C++-code-specific-checks" and which are "C-Code-specific-checks"? Can this be checked programmatically?

There is not a way to identify them from the command line, but each check has an `isLanguageVersionSupported()` function that checks for valid language options that you can use to find this information via manual inspection.

> Are “clang-analyzer-“ checks only applied to C++-code?

Not always, those come from the static analyzer (rather than explicitly written as clang-tidy checks) and many of those apply to C code as well as C++ code (for example, there are checks specific to malloc/free behavior, checks for division by zero, etc).

> What happens internally if C++-code-check ran on C-code? Will it skip parsing C-code?

If the check is designed to be C++-only, then it will be skipped for a C translation unit.

~Aaron

>
>
>
> Thank you in advance for your valuable inputs.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

More information about the cfe-dev mailing list