javac pretty printer probable bugs

[Maurizio Cimadamore]

On 29/01/12 16:45, Rémi Forax wrote:
> On 01/29/2012 05:25 PM, Jonathan Gibbons wrote:
>> 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
>
> Jon,
> how the pretty printer can represent "let" construct or bridge methods 
> in Java ?
Was thinking the same. The bridge method question is probably the 
easiest - I think the pretty printer should not print (at least not by 
default) synthetic members. They will be re-generated if you recompile 
the source emitted by the printer.

[Btw I think the same treatments should be applied to the body of an 
anonymous inner class - Printer should not print out the whole class 
declaration - only the methods explicitly overridden in the source].

With Let expression, as everything that happens after lowering, there is 
a problem - in the sense that Lower alters the shape of the code in an 
unrecoverable (for now ;-)) way. What about inner classes desugared into 
toplevel ones? Do we want Pretty to generate stuff containing Foo$1 ? 
Well, probably not.

Depending on the degree of accuracy we want out of Pretty, there could 
be different solutions - we could make small adjustment to the AST 
before printing in out, in order to remove the redundant stuff (i.e. 
synthetic methods) - it would be great if those adjustments could be 
parameterized on some compiler flags, so that the user gets to choose 
which ones to apply in their specific case.

But there will be cases in which the adjustment will be hard (as in the 
case of LetExpr or inner classes), and you somehow need a pointer to the 
untranslated AST to get out of the mess.

Maurizio
>
> Rémi
>
>>
>>
>> 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
>>>
>>>
>>
>