Summary: | [clean up] Sort members clean up leaks working copies | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> | ||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P3 | CC: | alex.blewitt, benno.baumgartner | ||||
Version: | 3.3 | ||||||
Target Milestone: | 3.3 M5 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Markus Keller
2007-01-29 12:21:47 EST
I released a workaround to SortMembersFix (fixes the test failures). Benno, please verify. Another question is why CompilationUnitSorter.sort(..) needs a working copy at all. Maybe a better solution would be to relax this precondition in JDT/Core. Sorry Markus, I've should have looked at this closer. Alex, you should have asked me what becomeWorkingCopy means, or at least RTFJavadoc: "{@link #discardWorkingCopy} must be call as many times as {@link #becomeWorkingCopy(IProblemRequestor, IProgressMonitor)}." Now we have to request a change in core again, I guess. Created attachment 57912 [details] proposed fix This is a fup of bug 171066. Would it be possible to weaken the working copy precondition as proposed in this patch? Released for 3.3M5. Verifier, please check the javadoc of the new API defined in bug 171066. Is the requirement for working copies not required when running Sort Members outside of CleanUp? The current SortMembersOperation opens a new editor with those changes in. Just a thought ... Alex. Thanks Olivier! (In reply to comment #5) > Is the requirement for working copies not required when running Sort Members > outside of CleanUp? The current SortMembersOperation opens a new editor with > those changes in. Just a thought ... > > Alex. > Sort members action does not use the new API and the old one has not changed... Verified for 3.3 M5 using build I20070205-0009 |