Oza, Hiral via llvm-dev
2021-Sep-15 11:56 UTC
[llvm-dev] [cfe-dev] clang-tidy: identify "C++-code-specific-checks" and "C-Code-specific-checks"
>> 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
Aaron Ballman via llvm-dev
2021-Sep-15 12:07 UTC
[llvm-dev] [cfe-dev] clang-tidy: identify "C++-code-specific-checks" and "C-Code-specific-checks"
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