javac pretty printer probable bugs
Rémi Forax
forax at univ-mlv.fr
Sun Jan 29 08:45:51 PST 2012
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 ?
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
>>
>>
>
More information about the compiler-dev
mailing list