Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 210429 - [1.5][formatter] Formatter unable to format due to AbortFormatting
Summary: [1.5][formatter] Formatter unable to format due to AbortFormatting
Status: CLOSED DUPLICATE of bug 303519
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal with 1 vote (vote)
Target Milestone: 4.5   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-20 13:08 EST by Philipe Mulet CLA
Modified: 2016-01-08 17:30 EST (History)
2 users (show)

See Also:


Attachments
First draft (3.16 KB, patch)
2009-10-28 10:24 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2007-11-20 13:08:21 EST
Build 3.4M3

I can't get the following code to be handled by the formatter:

import java.io.Serializable;

public final class X implements Serializable {

    class SMember extends String {}  

    @Annot(value = new SMember())
     void bar() {}


    @Annot(value = 
            new X(){
                    ZorkAnonymous1 z;
                    void foo() {
                            this.bar();
                            Zork2 z;
                    }
            })
       		void foo() {}
}
@interface Annot {
        String value();
}
Comment 1 Eric Jodet CLA 2008-01-31 10:17:59 EST
Sounds like formatting of annotation is ok here.

The problem seems to originate from the CodeFormatterVisitor aborting the formating while scanning the following MethodDeclaration:
void foo() {
   this.bar();
   Zork2 z;
}
Comment 2 Frederic Fusier CLA 2009-10-02 11:18:35 EDT
These are due to the sytanx errors which make the compiler gives up before having set the statements of method foo. So, as the method has no statement, the formatter expects to have a closing brace after the opening one, hence also gives up at this stage when encountering the token 'this'...

So, close as WORKSFORME
Comment 3 Olivier Thomann CLA 2009-10-28 09:26:41 EDT
Reopen. There is no syntax error in this case.
The only problem is that the anonymous type declaration doesn't get its method bodies parsed properly.
The parser doesn't walk annotations to parse the method bodies. Annotations should be constant expressions. So technically speaking it is not possible to have an anonymous declaration as a annotation value. But syntactically it is possible to get it so we should support it inside the formatter which means we should parse these methods.
Now in order to prevent the parser to slow down, we should set a bit on the method declaration if it has an annotation that contains method declarations.
Comment 4 Olivier Thomann CLA 2009-10-28 10:23:18 EDT
Whatever we do to reduce the impact on parsing, we still need to do more work in order to get the method bodies inside annotation when that case is clearly an error.
So we need a "good" ast for the formatter to work, but it is pointless for the compiler as the code is invalid anyway.
I would be tempted to close as WONTFIX, but I'll let you have a second look using the hack I made.
Comment 5 Olivier Thomann CLA 2009-10-28 10:24:51 EDT
Created attachment 150730 [details]
First draft

We might want to set a bit on the declaration that contains the annotations to indicate if one of its annotations contains a method body. This will still require several arrays traversals inside the parser.
Comment 6 Olivier Thomann CLA 2009-10-28 14:58:30 EDT
The patch is not sufficient as it needs to recursively walk annotations as annotation member value pair can be annotations.
I think the best approach is to close as WONTFIX.
This is not critical enough and the code is incorrect anyway. On save, right errors are reported and once they are fixed, the code will format again.

Philippe, do you really believe we should fix this issue ?
Comment 7 Mateusz Matela CLA 2016-01-08 17:30:12 EST
This problem no longer occurs after formatter redesign.

*** This bug has been marked as a duplicate of bug 303519 ***