[MonoDevelop] Code analysis soc project

[nikhil sarda]

Hi,
I have been working on the basic infrastructure of the code analysis
project. My idea is to create a system which will allow users to write
rules in any .Net language of their choice (currently, provided that
language is C#) to provide for on-the-fly analysis. The way it works
right now is that I extend TextEditorExtension
to get the latest parsed document. I then feed this document into the
analysis engine. This is nothing but a concurrent producer/consumer
queue. Any rule that is written needs to have certain components
specified, such as the type of document it operated upon, the
compilation unit on which it works (for example, method specific rules
will take as their compilation unit a MethodDeclaration node). These
rules are required to register with the analysis engine. When a
document is parsed, an event is raised and the event handler initiates
a new task. This task is then en-queued in the analysis engine queue.
A task consists of 3 parts
1) A task will first identify which rules registered with the analysis
engine apply to the current document.
2) It then executes the logic of all the rules (can this be done
concurrently? execution of logic depends on the AST emitted by parser
service)
3) It updates the text editor with respective squiggly lines and icons

There are now two issues
1) En-queuing policy:  If the same file is being edited, then tasks
will be duplicated. Portions of code that have already been analysed
will be analysed again unnecessarily. Hence some sort of a policy is
required for enqueueing of tasks.

2) If the ActiveDocument changes, I would like that tasks associated
with the ActiveDocument should get higher priority. To implement this,
I could use a priority queue, but theres no such class in the
Collections framework. One possibility is to use the C5 library.

I would be grateful for any feedback.
Thanks
Nikhil Sarda

On Fri, Mar 26, 2010 at 9:14 PM, Lluis Sanchez Gual
<slluis.devel at gmail.com> wrote:
> All the projects you propose look ok to me. I think the code analysis
> project is the one that will benefit more users. AFAIR the new DOM is
> close to be finished, so working on it should be ok. My only concern is
> that the project may clash with the work mkrueger is doing, so you would
> need to be in synch with him.
>
> El dt 23 de 03 de 2010 a les 01:41 +0530, en/na nikhil sarda va
> escriure:
>> Hi,
>> I am writing this mail to get an opinion on the feasibility of the
>> on-the-fly code analysis project. This contains information I gleaned
>> from mhutch and mkrueger in IRC. I had taken the suggestion of mhutch
>> and was sniffing around the code completion bindings of c# in MD. The
>> code to underline with red the line of code that is generating a
>> parser error was straightforward to understand, but trying to
>> implement some more complicated forms of error detection the way
>> resharper does is slightly more difficult. Apparently the current
>> version of NRefactory is not good enough to detect certain types of
>> semantic errors. Hence detecting errors such as invalid return types,
>> incorrect parameters and so on are very difficult to do with the
>> current NRefactory. This is because there is presently no way to go to
>> the parent of the node you've no way to go to the parent and top-down
>> analysis is difficult because "<mkrueger>: because you can't go to the
>> children of the nodes without knowing the type of the node". Some
>> things that can be implemented however are naming conventions,
>> spellings in comments and string literals and so on. Given this
>> backdrop is there any point proceeding with this project? Or should
>> one wait for the new DOM to be completed?
>> I had a bunch of other ideas as well that I talked to people about on
>> IRC and XMPP, but I wanted to get a general opinion as well.
>>
>> 1) Extending the Code metrics addin: The addin i posted on the mailing
>> list does quite a few things, but a lot is still left to implement,
>> such as cohesion, coupling and association between classes. Maybe I
>> can add a few more metrics such as
>> http://yunus.hacettepe.edu.tr/~sencer/oom.html
>> But the killer feature would be CQL, which allows one to query the
>> code base for types, methods and namespaces that satisfy criteria as
>> specified in a very SQL type language. NDepend implements CQL and I
>> will be trying to replicate that.
>>
>> 2) Allowing for collaborative editing over XMPP, a la google wave.
>> This will probably require changes to Mono.Texteditor itself
>>
>> 3) Integration of monodoc (zzz)
>>
>> Thank you for your time
>> Nikhil Sarda
>> _______________________________________________
>> Monodevelop-list mailing list
>> Monodevelop-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
>
>