[llvm-dev] [cfe-dev] clang-tidy: identify "C++-code-specific-checks" and "C-Code-specific-checks"
Oza, Hiral via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 21 20:17:04 PDT 2021
Any reference on flow of clang-analyzer-* tidy-checks?
What is diff between clang-tidy and https://clang.llvm.org/docs/ClangStaticAnalyzer.html?
Thank you.
-Hiral
-----Original Message-----
From: Aaron Ballman <aaron at aaronballman.com>
Sent: Wednesday, 15 September, 2021 17:38
To: Oza, Hiral <Hiral.Oza at netapp.com>
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 7:56 AM Oza, Hiral <Hiral.Oza at netapp.com> wrote:
>
> >> 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.
Correct.
> $ 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.StdCLibrar
> yFunctions
> 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 "
That is interesting -- I have no idea why there's a discrepancy there (or if it's intentional for some reason).
~Aaron
>
> 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 llvm-dev
mailing list