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.

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.

OK. A few more improvements here.

1. When the secret system property to enable requesting of concrete asts is set, the there are info messages sent to the log, that notfies you when a concrete or non-concrete ast is requested. This is only a temporary measure because I imagine for regular use, this will get annoying.

2. I added some assertions to ensure that a concrete ast is never requested when the system property is left unset.

3. All tests pass when the property is usset.

Unfortunately, I still have some test failures when the system property is set. I'm still exploring why.

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?