The problem of ASTs, transforms and how to do code resolution, content assist, etc.

I am playing around locally with creating a copy of the ast that will remain 'concrete'. No ast transforms will be applied to this tree. However, it will be resolved. This appears to be sufficient.

I have not checked performance, but I guess that it will be horrendous.

This solution is still a quick and dirty way to test out a way to better handle AST transforms in the UI. Essentially, what I have now is Option 2. We will only create the AST copy during reconcile. This means that full compiles will not take a hit on ast caching. Testing this out locally, I found that Grails took approx 2x longer to build when running with the AST caching compared to without.

In order to enable AST caching, before starting Eclipse, you must set framework/system property

request.concrete.ast=true 

I am not ready to commit what I have. I need to make sure that it is not running havoc on some other part of the code.

Here are the situations where we would like the transformed ast only:

• problem finding
• build structure
• reconciling (actually, the top two are really special cases of reconciling)
• indexing

Here are the situations where we would like the concrete ast:

• compilation
• hierarchy resolving
• related method finding (ie- searching for method declaration matches while refactoring)

When we were switching backwards and forwards on whether to transform or not as part of reconciling, these situations were not considered separately. Now you have distilled them out (is that definetly all of them?), we can possibly turn off transforms for some but not others and avoid ast copying. Although it avoids the expensive copy, it may still make a right mess of jdt.core as the switches will need to be in place to ensure requestors to specify what they want. If we default one way, I suppose that actually halves the problem as only those who don't want it have to specify they don't.

Here is a list of the currently failing tests that are somewhat troubling:

• InferencingTests.testStaticMethodCall3() : inferred type should have been string. The problem here is that a method call AST node should have been converted into a static method call AST node, but wasn't. This may have to happen in concrete asts.

• FieldCompletionTests.testProperties1() : It looks like properties are not being generated for classes that have concrete ASTs requested. This is another thing that will need to be added to the groovy classes during concrete ast requesting.

• CodeSelectFieldsTest.testCodeSelectOfGeneratedGetter() : This is occurring because properties are not being generated.

• CodeSelectFieldsTest.testCodeSelectOfGeneratedSetter() : This is occurring because properties are not being generated.

• TypeCompletionTests.testCompletionTypesInParameters4() : Looks like aproblem with default expressions of parameters

• RenameTypeTests.testAnnotation2() : Renaming of an annotation reference inside another annotation is not being found. The second 'A' is not being renamed:

@interface Main {
   A child() default @A("Void");
}

• RenameTypeTests.testAlias1() : Here, a constructor call is not being renamed (ie- the 'A' here):

   
  public A(int num) {
      fNum= num;
  }
  

• RenameTypeTests.testEnum1() : Same problem as above.

To summarize, when concrete asts are added, we need to ensure that getters and setters generated from properties are properly added to the class. Also, we need to ensure that static method calls are created where appropriate. For some of the other tests, I am concerned that some special logic we added when we were not dealing with concrete asts, is now causing us problems when we are. I am getting closer to a state where these changes are releasable, but not yet.

The final solution that we are doing now is to selectively run AST transforms for different kinds of operations. For compiles, type hierarchy calculations, and method override calcluations, we are running the transformations, but for reconciles and all other operations that require an AST, transforms are not running. This appears to solve the problems described here. Closing this bug. If there are any new problems to come of this, it will be in a new issue.

We've done enough work here. Future work will go into new issues.

just to note, this solution currently breaks @Grab related reconciling.

Is the
request.concrete.ast=true
still supported?