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

Aaron Ballman via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 15 05:07:32 PDT 2021 

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.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 "

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