Summary: | Java model gives different results | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dani Megert <daniel_megert> | ||||
Component: | Core | Assignee: | David Audel <david_audel> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | david_audel, jerome_lanneluc, markus.kell.r, martinae, rudiger.lincke | ||||
Version: | 3.2 | ||||||
Target Milestone: | 3.3 M1 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Bug Depends on: | |||||||
Bug Blocks: | 149853 | ||||||
Attachments: |
|
Description
Dani Megert
2006-02-27 10:23:54 EST
That's correct, the statement recovery is enabled in the reconciler thread (see JavaReconcilingStategy#reconcile(...)) and it is not when opening a regular ICompilationUnit (through either openWhenClosed(...) or becomeWorkingCopy(...)). David any idea why statement recovery is not enabled in the latter case ? Or should we not report local elements during reconcile during recovery ? Talking with David, it appears that even with statement recovery off, it is possible to add an internal option to the SourceElementParser that will recover headers. Reassigning to David to make the change. Created attachment 46369 [details]
Proposed fix
Add an internal option to the parser to enable the recovery of all headers in methods body.
Released for 3.3M1 Test added LocalElementTests#testLocalType5() *** Bug 149853 has been marked as a duplicate of this bug. *** Verified for 3.3 M1 using build I20060804-0010. *** Bug 208013 has been marked as a duplicate of this bug. *** |