Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CtClass.getSuperClass() returns invalid CtTypeReference #959

Closed
pvojtechovsky opened this issue Nov 10, 2016 · 4 comments
Closed

CtClass.getSuperClass() returns invalid CtTypeReference #959

pvojtechovsky opened this issue Nov 10, 2016 · 4 comments

Comments

@pvojtechovsky
Copy link
Collaborator

The spoon.test.imports.ImportTest.testSpoonWithImports fails with PR #913, because it now calls CtTypeReference.getActualClass() on invalid CtTypeReference to child class

spoon.test.imports.testclasses.internal.SuperClass$InnerClassProtected

which has wrong qualified name

spoon.test.imports.testclasses.internal.ChildClass$InnerClassProtected

I will provide PR with simplified failing test.

@pvojtechovsky
Copy link
Collaborator Author

The wrong declaringType of that inner class is caused by this code in JDTTreeBuilderHelper method createType(TypeDeclaration typeDeclaration)

                // Sorry for this hack but see the test case ImportTest#testImportOfAnInnerClassInASuperClassPackage.
                // JDT isn't smart enough to return me a super class available. So, I modify their AST when
                // superclasses aren't in the same package and when their visibilities are "default".
                List<ModifierKind> modifiers = Arrays.asList(ModifierKind.PUBLIC, ModifierKind.PROTECTED);
                final TypeBinding resolvedType = typeDeclaration.superclass.resolvedType;
                if ((resolvedType instanceof MemberTypeBinding || resolvedType instanceof BinaryTypeBinding)//
                        && resolvedType.enclosingType() != null && typeDeclaration.enclosingType.superclass != null//
                        && Collections.disjoint(modifiers, getModifiers(resolvedType.enclosingType().modifiers))) {
                    typeDeclaration.superclass.resolvedType = jdtTreeBuilder.new SpoonReferenceBinding(typeDeclaration.superclass.resolvedType.sourceName(),
                            (ReferenceBinding) typeDeclaration.enclosingType.superclass.resolvedType);
                }

@GerardPaligot please have a look. As author you can fix it probably the fastest. Thank You!

@monperrus By the way, how do you manage assignment of issues to contributors? May be somebody is already fixing it and I was just wasting my time ;-)

@monperrus
Copy link
Collaborator

By the way, how do you manage assignment of issues to contributors?

I don't assign anything. If somebody starts working on an issue, she/he can simply drop a comment on it to let the others know.

@tdurieux
Copy link
Collaborator

I don't know how to fix this.
With the current implementation we use the qualified name as an access path not the path to the declaration.
In the current metamodel of spoon we cannot store the these informations.
We already discuss this when @GerardPaligot implements this hack.

@monperrus
Copy link
Collaborator

The current behavior is correct, see #971

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants