Re: [Codenarc-developer] [Codenarc-user] Incomplete AST nodes?

[Hamlet D'A. <ham...@gm...>]

I still think that it's possible. I'd like to experiment and see what happens.

My original idea was for each rule to specify the compiler phase it
runs in. To test your idea, you can just change the rules to all run
in a late phase and see if the info you think should be there is.

Here is what I'd do (you'll need svn and mvn installed):

Get the source for CodeNarc:
    $ svn co https://codenarc.svn.sourceforge.net/svnroot/codenarc codenarc
    $ cd codenarc
    $ mvn install
open the file: /src/main/groovy/org/codenarc/source/AbstractSourceCode.groovy

Line 75 says this:
     compUnit.compile(Phases.CONVERSION)
Change it to
     compUnit.compile(Phases.OUTPUT)

The project won't build cleanly any more after this change, but you
can write your transformation and unit test as part of the project and
run it individually.

If you see the AST you need, then we will work to add this feature in.


Regarding the point of your rule.... you basically want a rule that
adds a violation whenever a dynamic variable is found... right?



On Thu, Apr 14, 2011 at 5:41 PM, Klaus Baumecker
<kla...@go...> wrote:
> Now I found a real gap in my story: Groovy classes derived from Java
> classes. The java classes are not inspected and therefore not in the AST. I
> can't check against members of the super class.
>
> -- Gesendet von meinem Palm Pre
> ________________________________
> Am 14.04.2011 10:46 schrieb Hamlet D'Arcy <ham...@gm...>:
>
>> Btw. a topic for a side-discussion at GR-8 in Copenhagen?!
>
> A topic for Hackergarten as well. One of the nights we're planning a
> hacking-fest for groovy projects.
>
> I don't think this problem is specific to CodeNarc, but specific to
> Groovy ast transforms in general.
>
> If you run CodeNarc in a later compiler phase then I bet you'll see
> the information you need, no hackery needed.
>
> Do you want some tips on how to run this in a later phase? I had a
> patch to do this at one point, but Chris and I decided that it wasn't
> worth the effort because there were so many simple rules left to write
> that didn't require much type information.
>
>
>
> On Thu, Apr 14, 2011 at 9:45 AM, Klaus Baumecker
> <kla...@go...> wrote:
>> Hi Hamlet,
>>
>> the class hierarchy problem is because the AST generation takes a
>> class at a time and fills the superClass property just for the next
>> level up. If the superClass itself has not yet been inspected, it gets
>> Object as superClass.
>>
>> The way I (kind of) solved this problem was by using a 2-phase
>> approach. I modified the Codenarc script to run it two times and at
>> the same time build my own class-superClass map. Not perfect, I know.
>> But I got a complete hierarchy.
>>
>> Now to the actual problem I want to solve: I'm writing a rule, that
>> finds non-declared properties (or you might say dynamic properties).
>> That is all variable accesses that are not declared in the
>> class/superClass, the closure or whatever context the access is. I'm
>> pretty close to a working solution but I it will remain an
>> approximation to a strict parser with holes in it. The background is
>> to give the developers in my organisation a tool to check for typos
>> and 'forgotten' variables due to incomplete refactoring.
>> I continued, where GroovyLint stopped. I tried enhancing GroovyLint on
>> this topic, but at some point I got non-debuggable
>> ClassNotFound-exceptions and went over to CodeNarc. At this point I
>> also discovered the differences in completeness of the AST tree
>> between GroovyLint and CodeNarc (mainly because of the different
>> compile stage).
>> I also though about using Groovy++ for that task, but at this point
>> G++ has a different semantic than original Groovy wrt. scope in
>> closures and maybe elsewhere too.
>>
>> Anyway, that is my goal for giving Java programmers a smooth
>> transition to Groovy. You might argue, that CodeNarc is not the right
>> tool. IntelliJ would be an alternative, since it identifies these
>> variables as well, but I miss the reporting capability over a code
>> base.
>>
>> Btw. a topic for a side-discussion at GR-8 in Copenhagen?!
>>
>> Best regards,
>> klaus.
>>
>> On Wed, Apr 13, 2011 at 9:15 PM, Hamlet DArcy <ham...@ca...>
>> wrote:
>>> CodeNarc runs in a fairly early compiler phase. We do this so that you
>>> don't need to have the project's compiled class files on the classpath...
>>> you can still run CodeNarc even if your build/code is broken! On the
>>> negative side, that means a lot of type information is missing. Be careful
>>> when referencing types because any non-JDK types may not exist at the time
>>> you run CodeNarc.
>>>
>>> Do you have a simple example of the source the shows Object as the parent
>>> class with the missing inheritence problem? SOmething like
>>> {code}
>>> class A {}
>>> class B extends A {}
>>> class C extends B {}
>>> {code}
>>> Or something simple like that?
>>>
>>> ALso, I'd love to hear the specifics of the rule. Perhaps I can quickly
>>> write it for you, that way we can include it in the base product rather than
>>> leave it to something for you to maintain. (just a thought)
>>>
>>>
>>> ----- Original Message -----
>>>> I'm trying to build a rather complex rule based on information also
>>>> kept in the super class of a classnode. I made several observations:
>>>> 1. The class hierarchy seems broken with some classes. That is,
>>>> walking up along the superClass members I see java.lang.Object too
>>>> soon
>>>> 2. Not all fields of a class are visible in the classNode.
>>>>
>>>> I've built a rule based on the AbstractAstVisitor and overloaded
>>>> multiple visit* methods, such as visitClassEx and
>>>> visitConstructorOrMethodEx.
>>>>
>>>> For the incomplete fields information I suspect the threaded
>>>> execution
>>>> of the rules against the fileset. But why some superClass info is
>>>> missing I cannot explain.
>>>>
>>>> Any idea, what goes wrong here?
>>>>
>>>> Regards,
>>>> klaus.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Forrester Wave Report - Recovery time is now measured in hours and
>>>> minutes
>>>> not days. Key insights are discussed in the 2010 Forrester Wave
>>>> Report as
>>>> part of an in-depth evaluation of disaster recovery service
>>>> providers.
>>>> Forrester found the best-in-class provider in terms of services and
>>>> vision.
>>>> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>>>> _______________________________________________
>>>> Codenarc-user mailing list
>>>> Cod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Benefiting from Server Virtualization: Beyond Initial Workload
>> Consolidation -- Increasing the use of server virtualization is a top
>> priority.Virtualization can reduce costs, simplify management, and improve
>> application availability and disaster protection. Learn more about
>> boosting
>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>
>
>
> --
> Hamlet D'Arcy
> ham...@gm...
>



-- 
Hamlet D'Arcy
ham...@gm...