Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Static Analysis Framework for CDT

It would also be cool if we could start looking at how we'd implement
quick fix. If we started adding that capability, I think we could almost
declare that we've caught up to the JDT bar. :)

Does anyone have experience with JDT's quick fix? Does it rely on the
refactoring framework? Could we extend what we have for refactoring to
apply here?

Doug.

On Mon, 2009-04-20 at 17:43 +0200, Schorn, Markus wrote:
> This is great start! 
> In addition to your proposal it would be useful to (optionally) run 
> some (or all?) of the checkers on the editor every time the user stops
> typing.
> The editor creates an AST at this point of time anyways, so as long as
> there 
> are simple checkers this should not add a noteable performance overhead.
> Markus.
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia
> > Sent: Monday, April 20, 2009 4:51 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] Static Analysis Framework for CDT
> > Importance: Low
> > 
> > There is not much of this "framework" can be re-used for self 
> > contained external tool like that.
> > I don't think even error parser is required because it would 
> > just work with gcc error parser, so it would pretty much work 
> > out of box considering integration is provided by makefile 
> > (which should be done anyway on make/build level and not 
> > invoked externally)
> > 
> > Btw, I am pretty much done with preliminary framework 
> > (without data-flow graphs etc), I update wiki page 
> > http://wiki.eclipse.org/CDT/designs/StaticAnalysis
> > added screenshots for user interface, comments are welcome.
> > I have 2 checkers now Assignment in Condition from Markus 
> > presentation and Statement has no Effect.
> > Checkers contributions are welcome. We need at least dozen 
> > checkers to make it worthy to include as feature in next CDT.
> > 
> > Schaefer, Doug wrote:
> > > That sounds reasonable. I'm still concerned about the 
> > licensing issues 
> > > with the GCC plug-in framework, but we're starting to 
> > figure out how 
> > > to manage that with the packaging efforts.
> > > 
> > > Cheers,
> > > Doug. 
> > > 
> > >> -----Original Message-----
> > >> From: cdt-dev-bounces@xxxxxxxxxxx
> > >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Dominique Toupin
> > >> Sent: Monday, April 20, 2009 7:47 AM
> > >> To: CDT General developers list.
> > >> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
> > >>
> > >>
> > >> This is indeed the best setup, everything we can check 
> > rapidly we can 
> > >> do it inside CDT even before the code is build.
> > >> Then the complicated/longer analysis are done by external 
> > tools, some 
> > >> of those analysis are running at night.
> > >> What I was pointing out below is we might be able to use 
> > GCC plugins 
> > >> for complicated/long analysis, we would then have a 
> > complete static 
> > >> analysis framework in CDT.
> > >>
> > >> "If you are doing simple rules, CDT alone should be OK but if you 
> > >> need complicated rules (e.g. data-flow analysis) then you 
> > might want 
> > >> to also look at GCC plugin"
> > >>
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: cdt-dev-bounces@xxxxxxxxxxx
> > >>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
> > >>> Sent: 20-Apr-09 04:03
> > >>> To: CDT General developers list.
> > >>> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
> > >>>
> > >>> I don't have plans to work on something like that. 
> > However, I think 
> > >>> there is lots of value we could add to CDT by doing some
> > >> analysis on
> > >>> the parser side. This is not because we can do better 
> > analysis than 
> > >>> gcc or other tools, it is because we could do some analyis much 
> > >>> earlier, when you edit your code and could ideally also provide 
> > >>> quick-fixes. The most simple example is the detection of
> > >> assignments
> > >>> in conditions 'if (a = 0)', which is easy to detect and
> > >> easy to fix. 
> > >>> CDT should offer support for that.
> > >>>
> > >>> Markus.
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: cdt-dev-bounces@xxxxxxxxxxx
> > >>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of 
> > Dominique Toupin
> > >>>> Sent: Friday, April 17, 2009 6:08 PM
> > >>>> To: CDT General developers list.
> > >>>> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
> > >>>> Importance: Low
> > >>>>
> > >>>>
> > >>>> Markus, are you planning on providing advanced static
> > >> analysis e.g.
> > >>>> data-flow analysis :-)
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: cdt-dev-bounces@xxxxxxxxxxx
> > >>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> > >>>>> Sent: 17-Apr-09 11:53
> > >>>>> To: CDT General developers list.
> > >>>>> Subject: RE: [cdt-dev] Static Analysis Framework for CDT
> > >>>>>
> > >>>>> Then I suggest that you need to take a closer look at the
> > >>>> CDT core ;)
> > >>>>> Markus's EclipseCon presentation would be a great place
> > >> to start.
> > >>>>> Doug.
> > >>>>>
> > >>>>> On Fri, 2009-04-17 at 11:21 -0400, Dominique Toupin wrote:
> > >>>>>> In practice I don't think CDT parser has the same
> > >>>>> info/capability as
> > >>>>>> GCC, GCC has a lot of info about the code and we can do
> > >>>>> advance static
> > >>>>>> analysis (not grep like) with this info.
> > >>>>>> I am not suggesting to integrate GCC code into CDT, the
> > >>>> GCC static
> > >>>>>> analysis would be an external tool just like GCC/GDB today.
> > >>>>>> Even if it's an external tool it brings a lot of features
> > >>>>> to CDT, it's
> > >>>>>> just like compile (GCC) and debug (GDB) today.
> > >>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: cdt-dev-bounces@xxxxxxxxxxx 
> > >>>>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
> > >>> Doug Schaefer
> > >>>>>>> Sent: 17-Apr-09 09:52
> > >>>>>>> To: CDT General developers list.
> > >>>>>>> Subject: Re: [cdt-dev] Static Analysis Framework for CDT
> > >>>>>>>
> > >>>>>>> My bigger concern is that all GCC plug-ins must be GPL. I'd 
> > >>>>>>> especially be worried about plug-ins written
> > >>>> specifically for the
> > >>>>>>> CDT and whether that affects the definition of "derived"
> > >>>>>>> and thus, causing us legal grief.
> > >>>>>>>
> > >>>>>>> At any rate, theoretically, the CDT parsers already
> > >>>>> create the same
> > >>>>>>> information that gcc would. And we can avoid any legal
> > >>>>> problems that
> > >>>>>>> way.
> > >>>>>>>
> > >>>>>>> Doug.
> > >>>>>>>
> > >>>>>>> On Fri, 2009-04-17 at 09:43 -0400, Elena Laskavaia wrote:
> > >>>>>>>> GCC plugins means it would be part of GCC which
> > >> is external
> > >>>>>>> to eclipse?
> > >>>>>>>> If so it can be just run as external and not part of the
> > >>>>>>> framework which is Java based.
> > >>>>>>>> Dominique Toupin wrote:
> > >>>>>>>>> Hi Elena,
> > >>>>>>>>>
> > >>>>>>>>> If you are doing simple rules, CDT alone should be OK
> > >>>>> but if you
> > >>>>>>>>> need complicated rules (e.g. data-flow
> > >> analysis) then you
> > >>>>>>> might want
> > >>>>>>>>> to also look at GCC plugin
> > >>>>>>> http://gcc.gnu.org/wiki/GCC_Plugins, they
> > >>>>>>>>> did progress and hopefully the architecture will be
> > >>>>>>> resolve for the
> > >>>>>>>>> GCC summit (http://gccsummit.org/2009/), some CDT
> > >>>> committers
> > >>>>>>>>> will also attend the GCC summit (at least Francois
> > >>>> and Marc).
> > >>>>>>>>> Last year at the GCC summit some static analysis tools
> > >>>>>>> based on GCC
> > >>>>>>>>> where presented e.g. 
> > >>>>> https://developer.mozilla.org/en/Treehydra,
> > >>> 
> > https://developer.mozilla.org/en/Dehydra?rdfrom=https%3A%2F%2Fwiki.m
> > >>>>>>>>> ozil
> > >>>> la.org%2Findex.php%3Ftitle%3DDehydra_GCC%26redirect%3Dno.
> > >>>>>>>>> If we can have good static analysis rules with GCC
> > >>>>>>> plugins it will
> > >>>>>>>>> make sense to integrate those into CDT.
> > >>>>>>>>>
> > >>>>>>>>> Dominique
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> -----Original Message-----
> > >>>>>>>>>> From: cdt-dev-bounces@xxxxxxxxxxx 
> > >>>>>>>>>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf
> > >> Of Elena
> > >>>>>>>>>> Laskavaia
> > >>>>>>>>>> Sent: 16-Apr-09 22:44
> > >>>>>>>>>> To: CDT General developers list.
> > >>>>>>>>>> Subject: [cdt-dev] Static Analysis Framework for CDT
> > >>>>>>>>>>
> > >>>>>>>>>> This is something I am doing in my spare time -
> > >>> I want to
> > >>>>>>>>>> create static analysis framework for CDT, light
> > >>>> weigh set of
> > >>>>>>> classes that
> > >>>>>>>>>> allow to have common interface for dealing
> > >> with problems
> > >>>>>>> produced
> > >>>>>>>>>> by static analysis tools (and some default checkers,
> > >>>>>>> such what JDT
> > >>>>>>>>>> has, i.e Potential Null Pointer Dereference, etc).
> > >>>>>>>>>>
> > >>>>>>>>>> See design details at: 
> > >>>>>>>>>> http://wiki.eclipse.org/CDT/designs/StaticAnalysis
> > >>>>>>>>>> _______________________________________________
> > >>>>>>>>>> cdt-dev mailing list
> > >>>>>>>>>> cdt-dev@xxxxxxxxxxx
> > >>>>>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>>>>>>>
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> cdt-dev mailing list
> > >>>>>>>>> cdt-dev@xxxxxxxxxxx
> > >>>>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>>>>> _______________________________________________
> > >>>>>>>> cdt-dev mailing list
> > >>>>>>>> cdt-dev@xxxxxxxxxxx
> > >>>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>>>> _______________________________________________
> > >>>>>>> cdt-dev mailing list
> > >>>>>>> cdt-dev@xxxxxxxxxxx
> > >>>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> cdt-dev mailing list
> > >>>>>> cdt-dev@xxxxxxxxxxx
> > >>>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>> _______________________________________________
> > >>>>> cdt-dev mailing list
> > >>>>> cdt-dev@xxxxxxxxxxx
> > >>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>>
> > >>>> _______________________________________________
> > >>>> cdt-dev mailing list
> > >>>> cdt-dev@xxxxxxxxxxx
> > >>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>>
> > >>> _______________________________________________
> > >>> cdt-dev mailing list
> > >>> cdt-dev@xxxxxxxxxxx
> > >>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>>
> > >> _______________________________________________
> > >> cdt-dev mailing list
> > >> cdt-dev@xxxxxxxxxxx
> > >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > >>
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top