[cfe-dev] Building upon the clang static analyzer

[Jordan Rose]

Ah, clever. Both of those seem like reasonable ideas, though they're still a little vague for a project proposal. I will note that the analyzer today is very heavily built around analyzing entire functions—there's no good way to, say, only analyze one loop within a function. If you wanted to do this sort of "targeted" analysis (for GSoC, or just as a project), you'd probably want to scope it within that restriction for now (i.e. only use matchers to identify interesting functions, not interesting pieces of functions).

Alternately, you could work on trying to remove that restriction, which is probably some of the same work that would go into making loop handling more general (see the new Open Projects page). We think this is a pretty hard problem, though, and you might not want to work on it at the same time as the matchers work.

Glad to hear of your interest in the project!
Jordan


On Apr 12, 2013, at 10:14 , Gábor Horváth <xazax.hun at gmail.com> wrote:

> Hi!
> 
> I was thinking about two things. First is path-sensitive refactoring tools. The second would be a way to create analysis tools with superior performance: isolate a part of the AST via matchers which should be fast, then execute path sensitive analysis on only that part of the AST. 
> 
> Thanks,
> Gábor
> 
> 
> On 12 April 2013 02:40, Jordan Rose <jordan_rose at apple.com> wrote:
> Hi, Gabor. I'm not exactly sure what you mean here. Again, although it hasn't been done (to my knowledge), there is nothing stopping you from writing a Clang tool that simply calls the analyzer's ASTFrontendAction. In order to integrate matchers, the tool could call additional ASTFrontendActions in addition to AnalysisAction, or a user could simply write a syntactic checker (check::ASTDecl, check::ASTCodeBody, check::EndOfTranslationUnit) that uses matchers to create analyzer-style output.
> 
> I suppose my main objection is that I'm not sure there's any infrastructure work to be done, let alone a whole summer's worth.
> 
> One thing that does seem a bit intriguing is "replacements"—could this be used to offer suggestions (a la fixits)? could there be path-sensitive refactoring tools?—but without a use case and definite goal in mind, I think this is still lacking a bit as a project.
> 
> But maybe I'm just not seeing the whole picture. Do you have anything in particular in mind?
> Jordan
> 
> P.S. The analyzer team at Apple is discussing some possible GSoC projects (and general open projects), which we'll put up on our website soonish. I'll try to remember to send them to you (and Adam) when that happens.
> 
> 
> On Apr 10, 2013, at 23:41 , Gábor Horváth <xazax.hun at gmail.com> wrote:
> 
>> Hi!
>> 
>> Do you think, it would be a suitable GSoC project to make the Analyzer to work with the libTooling infrastructure? Not just making it able to work as a standalone tool, but make it easier to combine the features of analyzer, matchers and replacements. Because in that case I would like to propose this project for Google Summer of Code, and I would like to work on this project.
>> 
>> I am very interested about your feedbacks on this topic.
>> 
>> Thanks,
>> Gábor Horváth
>> 
>> 
>> On 9 April 2013 18:57, Jordan Rose <jordan_rose at apple.com> wrote:
>> To build on what Anna said, the analyzer predates libTooling, but does use the same ASTFrontendAction infrastructure that a tooling plugin would use. It does seem like you would be able to run the AnalysisAction through libTooling, but we haven't ever tried this. Let us know how it turns out!
>> 
>> (There is of course no reason why you couldn't write custom syntactic checkers that use libASTMatchers, and then you could just use the regular --analyze interface to the analyzer. But that might be a bit more intrusive of a change.)
>> 
>> Jordan
>> 
>> 
>> On Apr 6, 2013, at 11:12 , Gábor Kozár <kozargabor at gmail.com> wrote:
>> 
>> > Hi,
>> >
>> > We're working on a static analysis tool that would enforce certain design (coding) rules in some private C++ projects. So far we've been working on a custom tool, using clang libtooling, to implement some fairly trivial checks using AST matchers - however, we realized that building upon the clang static analyzer would be a much better choice, especially when implementing more complicated checks.
>> >
>> > I have had a quick look at the static analyzer source code, and it appears to me that it's basically an ASTFrontendAction (lib/StaticAnalyzer/FrontendActions.h), which to me indicates that this is "just another" tool built upon clang libtooling. Is this correct?
>> > It would be extremely convenient for us if it were so, because we could extend it seamlessly with our custom checkers into a custom analyzer tool.
>> >
>> > I also read on the website of the static analyzer that C++ support is not complete. However, I'm not sure how up-to-date the information on that website is kept, so I'll just ask it here: what is the state of the C++ (and C++11) support?
>> >
>> > Thanks!
>> >
>> > (Btw, we are very impressed by clang, and its static analyzer. Thank you for all your hard work! You guys are amazing!)
>> >
>> > Gabor
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 

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