generic type declarations leaking across all files in a build

I can later look into it a bit more to confirm but on a quick glance, I think that the solution suggested may not work when there are (anonymous)inner classes involved where outer class' generic parameter names remain valid inside the inner classes too.

We don't want to end visitClass() for an inner class and clear the genericParameterNames for the outer class as well.

Yep, after sleeping on it, you need to allow for inner classes to, I'd probably just use a similar mechanic in visitClassNode that you already have in the visitConstructorOrMethod code.

a proposed Testcase:

assertScript """
class A<String> {}
class B {
  void foo(String s) {}
}
// use the name to check the class, since the error was that String was seen as 
// a symbol resolved to Object, not as the class String, thus a ...==String would
// not have failed
assert B.class.methods.find{it.name=="foo"}.parameterTypes[0].name.contains("String")
"""

As suspected, the fix seems to have impact on the generics handling for inner classes.

The following code does not work now (doesn't even compile actually)

class A<T> {
    class B {
      void foo(T s) {}
    }
}
assert A.B.class.methods.find{it.name=="foo"}.parameterTypes[0].name.contains("java.lang.Object")

It fails with

D:\Roshan\GroovyDevSetup\Workspace17x\TryGroovy\src\TryGroovy.groovy: 3: unable to resolve class T 
 @ line 3, column 16.
         void foo(T s) {}
                  ^

1 error

Indeed, I see that the visit to the inner class does not happen during the visit to the outerclass, it happens after the outer class has been finished with. So the code from visitMethodOrConstructor cannot be used as when visiting the inner node the type variables of the outer have been forgotten.

There are possibly 3 solutions to the inner class problem.
(1) add a map to the inner class and set it from the resolve visitor and reuse it when parsing the inner class
(2) have some kind of memory persistent map ClassNode->SymbolMap.... I absolutely don't like this one
(3) start the resolving of inner classes after the outer class is done, without using the normal iteration used by CompilationUnit.

I prefer number 3 since it does not require keeping additional information in the AST.

Any progress on this?

since Roshan seems not to have capacity to fix this (which is not his fault), there is no progress atm

I guess someone else will have to take this over, unless Roshan says he still wants to fix this one

If I can find time, I'll take a proper look at the right fix.

Master includes the fix which breaks the non static inner class case. I will try to commit a fix.

Here is the patch against master. Added a unit test for the non static inner class case. If you are ok, I will commit it.