INRIA / spoon

Spoon is a metaprogramming library to analyze and transform Java source code. :spoon: is made with :heart:, :beers: and :sparkles:. It parses source files to build a well-designed AST with powerful analysis and transformation API.
http://spoon.gforge.inria.fr/
Other
1.74k stars 347 forks source link

Inner classes reference fails with pretty print #4001

Open moisesventura opened 3 years ago

moisesventura commented 3 years ago

A class defines two inner classes:

` public static class ByReference extends WFSALMCAPS implements Structure.ByReference {}

public static class ByValue extends WFSALMCAPS implements Structure.ByValue {}`

If spoon processes with PRETTY_PRINTING_MODE.FULLYQUALIFIED the references to the inner classes are correct:

public class WFSALMCAPS extends com.ardan1.xfs.Structure<com.ardan1.xfs.generated.WFSALMCAPS, com.ardan1.xfs.generated.WFSALMCAPS.ByValue, com.ardan1.xfs.generated.WFSALMCAPS.ByReference>

But if spoon processes with PRETTY_PRINTING_MODE.AUTOIMPORT the references to the inner classes are incomplete (it does not compile):

public class WFSALMCAPS extends Structure<WFSALMCAPS, ByValue, ByReference>

It should be:

public class WFSALMCAPS extends Structure<WFSALMCAPS, WFSALMCAPS.ByValue, WFSALMCAPS.ByReference>

slarse commented 3 years ago

Hi @moisesventura,

Thanks for the bug report. It appears as if the declaring type on type arguments is marked implicit at some point when running with auto-import.

Here's a minimal test input to reproduce the problem when running with auto-imports enabled:

import java.util.ArrayList;

public class Type extends ArrayList<Type.Nested> {
    public static class Nested {}
}

With auto-import enabled, this gets pretty-printed like so:

import java.util.ArrayList;

public class Type extends ArrayList<Nested> {
    public static class Nested {}
}

This causes a compile error as the reference to Type.Nested in the type argument becomes just Nested. The header of a type is technically outside of it, so nested types must be referenced with names qualified within the context (here, the compilation unit, but it applies recursively to nested types as well).

Note to other maintainers: This problem does not occur when running DJPP without ignoring implicit elements (i.e. DefaultJavaPrettyPrinter.setIgnoreImplicit(false)). So there's most likely a problem specifically in the auto-import stuff.