[cfe-dev] [analyzer] Emit errors from StaticAnalyzer

Tue May 15 18:03:43 PDT 2018

Hi Alexey,

You probably really want to use AST matchers library for similar checks, as it makes the code safer, faster, more concise, and more general.
Cf. https://eli.thegreenplace.net/2014/07/29/ast-matchers-and-clang-refactoring-tools <https://eli.thegreenplace.net/2014/07/29/ast-matchers-and-clang-refactoring-tools> for an example.

As to where the check should belong, since you’re not doing symbolic execution and only doing AST matching,
I think it should be possible to run your checker with core checks disabled (and if it’s not possible, maybe we should fix that).

George

> On May 15, 2018, at 1:01 AM, Sachkov, Alexey <alexey.sachkov at intel.com> wrote:
> 
> Hi,
>  
> Here is an example of diagnostic I implemented:https://github.com/AlexeySachkov/clang/commit/fc9ffedea8155cfd8cdd5da1861b9642e0a6646d <https://github.com/AlexeySachkov/clang/commit/fc9ffedea8155cfd8cdd5da1861b9642e0a6646d>
>  
> And I was able to launch only my checker without any crashes of clang.
>  
> I’m trying to figure out where is the best place for such diagnostics:
> ·         StaticAnalyzer:
> o   + modular, every additional implemented diagnostic/checker can be enabled separately
> o   – cannot emit errors by default
> ·         Sema
> o   – not modular, no fully-built AST (may be “workarounded” like it is done for CUDA)
> o   + no problems with emitting errors, absolutely the right place for semantic analysis.
> ·         Clang-plugins, clang-based tools (clang-tidy), build system configuration
> o   – not acceptable solution for me
>   <>
>  <>From: Gábor Horváth [mailto:xazax.hun at gmail.com] 
> Sent: Friday, May 11, 2018 11:51 PM
> To: George Karpenkov <ekarpenkov at apple.com>
> Cc: Sachkov, Alexey <alexey.sachkov at intel.com>; Clang Dev <cfe-dev at lists.llvm.org>
> Subject: Re: [cfe-dev] [analyzer] Emit errors from StaticAnalyzer
>  
> Hi George!
> 
> George Karpenkov via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> ezt írta (időpont: 2018. máj. 11., P 22:37):
> Hi Alexey,
>  
> Could you give some examples of diagnostics you have implemented?
>  
> In general, clang static analyzer emits warnings as it is allowed to have false positives by design.
> I think your workflow can be achieved without any changes required though: if you know that checker X
> will not have false positive, you can just configure your build system to fail the build if the static analyzer
> finds any bugs with only your checker turned on.
>  
> Unfortunately, it is not that easy. Running the analyzer without the core checks is not supported and likely to cause crashes. Core checks, however, might give false positives. To support this scenario, we should be able to turn diagnostics off from core checks (but keep the modeling part). 
>  
> Regards,
> Gábor
>  
>  
> Regards,
> George
> 
> 
> On May 11, 2018, at 3:22 AM, Sachkov, Alexey via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>  
> Hi,
>  
> I would like to ask what do you think about having possibility to emit errors from clang StaticAnalyzer?
>  
> Recently I encountered a problem with implementing complex diagnostics in clang (which requires call graph analysis, for example): it is hard to implement such diagnostics in Sema because there is no place with fully-built AST.
> So, I used static analyzer and implemented a few additional checkers, but the problem with static analyzer is that all diagnostics are emitted as warnings.
> Here is an example of the patch I would like to commit: https://github.com/AlexeySachkov/clang/commit/898c9c566d4c1c37c2d56787fd08ff8b1697aca9 <https://github.com/AlexeySachkov/clang/commit/898c9c566d4c1c37c2d56787fd08ff8b1697aca9>
>  
> What do you think?
> If there are no objections from adding possibility to emit errors from static analyzer, I will put a patch for review. Any comments on implementation?
>  
>  
> My main task is to implement some diagnostic messages, probably someone can advise me a better solution than static analyzer? Here an example (I’m interested in OpenCL C):
>  
> int val __attribute__((my_attr1));
> void func() {
>     val = 10; // expected-error{{variables declared with my_attr1 attribute cannot be used from kernels declared with my_attr2 attribute}}
> }
> __attribute__((my_attr2))
> __kernel void my_kernel() {
>     func();
> }
>  
> I knew that call graph analysis is used in Sema during compilation of CUDA sources and if static analyzer is completely wrong place for such stuff, I can try to use CUDA approach and update the Sema.
> Also I wouldn’t like to use clang plugins or to create a clang-based tool.
>  
> Best regards,
> Alexey Sachkov
> 
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park, 
> 17 Krylatskaya Str., Bldg 4, Moscow 121614, 
> Russian Federation
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>  
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park, 
> 17 Krylatskaya Str., Bldg 4, Moscow 121614, 
> Russian Federation
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180515/da2b56f9/attachment.html>