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

[Oza, Hiral via llvm-dev]

>> 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?
>What are you trying to achieve? clang-tidy addresses more C++ checkers, I don’t recall seeing C specific checkers and no, you cannot determine this programatically since it’s a matter of matching at the AST level.
We are seeing tidy taking lot of time for .c files and some .cc files!
On running each check we observed two things:
1) clang-analyzers are taking contributing lot and
2) “cert-dcl16-c” check is same as “readability-uppercase-literal-suffix” and “hicpp-uppercase-literal-suffix”. We all three enabled and these three also taking time!
So my understanding is – if we have these three checks “cert-dcl16-c”, “readability-uppercase-literal-suffix” and “hicpp-uppercase-literal-suffix” enabled it will parse AST thrice, correct? Shouldn’t it run once?

We would like to run specific tidy-checks for only C-code and specific tidy check for C++-code.
I think tidy performance can be improved if tidy can check file type (either C++ or C), decide whether specific check relevant to C++-code OR C-code and then only parse AST, isn’t it?
For example, tidy should not spend time in parsing C-code if check is about Virtual-Calls/Function etc. e.g.
Just like https://clang.llvm.org/docs/analyzer/checkers.html#core-nulldereference which specifies check is for C++ or C or ObjC… something similar should be there for clang-tidy.


>> Are “clang-analyzer-“ checks only applied to C++-code?
>No, there are a wide variaty of checkers that apply to C and C++ [1]

>> What happens internally if C++-code-check ran on C-code? Will it skip parsing C-code?
> Nothing really, since the clang-tidy checkers are implemented mostly as matcher at the AST level and since specific nodes that are matched for a checkers are not present in the AST the checker will not get triggered.
As mentioned above, (a) can tidy be improved to parse AST only if check relevant to C++ or C code? OR just like https://clang.llvm.org/docs/analyzer/checkers.html#core-nulldereferencecan can tidy highlight which checks are for C++ and which checks are for C-code?

Thank you Andi-Bogdan Postelnicu.
-Hiral

From: Andi-Bogdan Postelnicu <andi at mozilla.com>
Sent: Wednesday, 15 September, 2021 13:01
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"

Hello,

Please see my comments inlined.

[1] https://clang-analyzer.llvm.org/available_checks.html

On 15 Sep 2021, at 10:09, Oza, Hiral via cfe-dev <cfe-dev at lists.llvm.org<mailto: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:

  1.  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?
What are you trying to achieve? clang-tidy addresses more C++ checkers, I don’t recall seeing C specific checkers and no, you cannot determine this programatically since it’s a matter of matching at the AST level.


  1.
  2.  Are “clang-analyzer-“ checks only applied to C++-code?
       No, there are a wide variaty of checkers that apply to C and C++ [1]


  1.
  2.  What happens internally if C++-code-check ran on C-code? Will it skip parsing C-code?
Nothing really, since the clang-tidy checkers are implemented mostly as matcher at the AST level and since specific nodes that are matched for a checkers are not present in the AST the checker will not get triggered.


  1.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210915/9e6da083/attachment-0001.html>