Bug 280063 - org.eclipse.jdt.internal.compiler.parser.Parser.parseClassBodyDeclarations(char[], int, int, CompilationUnitDeclaration) should return consistent results
Summary: org.eclipse.jdt.internal.compiler.parser.Parser.parseClassBodyDeclarations(ch...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5.1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-12 07:50 EDT by Frederic Fusier CLA
Modified: 2009-08-28 02:25 EDT (History)
3 users (show)

See Also:
frederic_fusier: review+


Attachments
Proposed fix + regression tests (14.02 KB, patch)
2009-06-22 10:02 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 Frederic Fusier CLA 2009-06-12 07:50:40 EDT
Follow-up of bug 270148...

Using build I20090609-1400 and considering the following snippet:

  class MyCommand extends CommandBase
  {
    protected Command subcommand;

    //...

    public void execute()
    {
      // ...
      Compound subcommands = new CompoundCommand();
      subcommands.appendAndExecute(new AddCommand(...));
      if (condition) subcommands.appendAndExecute(new AddCommand(...));
      subcommand = subcommands.unwrap();
    }

    public void undo()
    {
      // ...
      subcommand.undo();
    }

    public void redo()
    {
      // ...
      subcommand.redo();
    }

    public void dispose()
    {
      // ...
      if (subcommand != null)
     {
        subcommand.dispose();
      }
    }
  }

Before bug 270148 was fixed, parsing the snippet using the
Parser.parseClassBodyDeclarations(...) method returned null. After, e.g. using HEAD, it returns an array with one TypeDeclaration which seems to be the expected result.

However, now considering another snippet:

  class MyCommand extends CompoundCommand
  {
    public void execute()
    {
      // ...
      appendAndExecute(new AddCommand(...));
      if (condition) appendAndExecute(new AddCommand(...));
    }
  }

Parsing it with the same Parser method still returns null. After bug 270148 was fixed, I would expect a non null result for the second snippet either...
Comment 1 Olivier Thomann CLA 2009-06-12 09:45:53 EDT
I'll investigate a fix for 3.5.1.
Comment 2 Olivier Thomann CLA 2009-06-12 13:03:40 EDT
When the statement recovery is not enabled, both cases should not be parsed successfully.
I need to add a bit on the resulting node to remember that the last action as ERROR_ACTION.
Working on it.
Comment 3 Olivier Thomann CLA 2009-06-12 13:17:03 EDT
When the statement recovery is not enabled, thes method org.eclipse.jdt.internal.compiler.parser.Parser.parseClassBodyDeclarations(char[], int, int, CompilationUnitDeclaration) should return consistent results whatever the given source is.
In comment 0, both code snippets should return null as both contains methods with syntax errors.
Comment 4 Olivier Thomann CLA 2009-06-22 10:02:07 EDT
Created attachment 139753 [details]
Proposed fix + regression tests
Comment 5 Olivier Thomann CLA 2009-06-22 10:03:10 EDT
Frédéric, please review.
Comment 6 Frederic Fusier CLA 2009-06-22 10:13:35 EDT
+1 patch looks good to me
Comment 7 Olivier Thomann CLA 2009-06-24 12:01:55 EDT
Released for 3.5.1 and 3.6M1.
Added regression tests:
org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0713
org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2#test0714
Comment 8 Jay Arthanareeswaran CLA 2009-08-05 04:00:57 EDT
Verified for 3.6M1 by regression tests verification and code inspection
Comment 9 Jay Arthanareeswaran CLA 2009-08-28 02:19:20 EDT
Verified for 3.5.1RC2 by regression tests verification and code inspection