llvm dev - Sep 2021 - [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

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