Thank you Jochen and Paul for looking into it.
At first I’ve tried this exact code and it fixes my test case, but then it
differs from the code in AsmReferenceResolver
only by logic for inner classes, and I have strong feeling that the exact same
code should be reused.
I’m leaving this up to you
The tests still pass replacing the try/catch with:
ClassNodeResolver.LookupResult lookupResult =
getClassNodeResolver().resolveName(name, CompilationUnit.this);
return lookupResult == null ? null : lookupResult.getClassNode();
Not sure whether returning null will cause a problem but if so it isn'
On 14.01.19 18:23, Daniil Ovchinnikov wrote:
Hi all -
So I’ve been investigating https://youtrack.jetbrains.com/issue/IDEA-204305 for
a while now
and found out that getClassNode() in anonymous ClassWriter in
CompilationUnit#createClassVisitor
still uses class loader to obtain class node instea
Hi all -
So I’ve been investigating https://youtrack.jetbrains.com/issue/IDEA-204305 for
a while now
and found out that getClassNode() in anonymous ClassWriter in
CompilationUnit#createClassVisitor
still uses class loader to obtain class node instead of relying on
AsmReferenceResolver.
Is th
