javac pretty printer probable bugs

[Jonathan Gibbons]

Martin,

The pretty printer is primarily a debugging aid, to accurately show the 
contents of the syntax tree. To assist in that task, a more recent 
development has been to try and make the output be compilable as well.

The difficulty is that, despite first appearances, the AST is not a 
direct, literal representation of the source text and some 
transformations on the tree have already occurred by the time the pretty 
printer gets invoked.

The use of comments has been introduced as a way of showing the parts of 
the AST which are present but which prevent compilation.   It would seem 
you have found a couple of corner cases that need to be fixed.

-- Jon


On 01/29/2012 06:07 AM, Crazy Java wrote:
> It looks like the Enum problem should alreadz be fixed according to 
> bug 6902720 
> (http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b1bb8164a9bd, 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6902720), but it is 
> not.
>
> 2012/1/29 Rémi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
>
>     On 01/29/2012 01:40 PM, Crazy Java wrote:
>
>         Hi,
>         as part of the javac AST Visualizer project, I have some
>         difficulties with javac's pretty printer. The problem is the
>         fact, that I am doing double compilation (after first
>         compilation I get the textual representation of produced AST
>         and that is in fact used for visualization purposes). Double
>         compilation is needed because I want to visualize all the
>         compiler sugar (default constructor, effectively final
>         variables in ARM, code generated for enum, ...).
>         The problem is that javac's pretty printer (I guess it is
>         pretty printer) after calling CompilationUnitTree.toString()
>         produces in some specific situations code that is not able to
>         compile:
>         1.) it transforms
>         public class FullClassUsage {
>            {
>                new <Object> ArrayList<String>(10) {
>                    {
>                        add("123");
>                    }
>                };
>            }
>         }
>         into
>         public class FullClassUsage {
>
>            public FullClassUsage() {
>                super();
>            }
>            {
>                new <Object>ArrayList<String>(10){
>
>                    (int x0) {
>                        super(x0);
>                    }
>                    {
>                        add("123");
>                    }
>                };
>            }
>         }
>         the (int x0) is the problem.
>         2.) when using together with enum types it transforms:
>         public enum SimpleEnum {
>            ENUM_CONSTANT_1,
>            ENUM_CONSTANT_2
>         }
>         into
>         public enum SimpleEnum {
>            /*public static final*/ ENUM_CONSTANT_1 /* = new
>         SimpleEnum() */,
>            /*public static final*/ ENUM_CONSTANT_2 /* = new
>         SimpleEnum() */;
>
>            private SimpleEnum() {
>                super();
>            }
>         }
>         that is really weird. Not only it generates comments ??? but
>         also a super call causing the code not to compile. I would
>         also assume that it will generate all the enum type code
>         (constructors with n+2 arguments, valueOf() factory method,
>         extending java.lang.Enum, ...).
>         Is there any reason why it produces that weird code?
>
>
>     Java language != bytecode,
>     at the end javac will generate bytecodes and there are a lot of
>     things that are allowed
>     in bytecode that are not allowed in Java.
>
>     The pretty printer is something used to debug and not something
>     that will generate fully compatible Java code
>     because some de-sugared code are only valid in bytecode but not in
>     Java.
>
>
>         Is there any better way to get the Textual representation of
>         CompilationUnitTree (using pretty printer) that will compile
>         in both of these examples ?
>
>
>     write your own :)
>
>         //Martin
>
>
>     Rémi
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20120129/8cb4cbfc/attachment.html