Bug 537467 - Fix regression in ot.RenameVirtualMethodInClassTests after changes in JDT/UI
Summary: Fix regression in ot.RenameVirtualMethodInClassTests after changes in JDT/UI
Status: RESOLVED FIXED
Alias: None
Product: Objectteams
Classification: Tools
Component: OTDT (show other bugs)
Version: 2.7   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 2.7.1   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-29 09:22 EDT by Stephan Herrmann CLA
Modified: 2018-07-29 11:30 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2018-07-29 09:22:16 EDT 
JDT/UI optimized renamve method refactorings via bug 351410. After that change several ot.refactoring tests like RenameVirtualMethodInClassTests.testUpdateReferenceToPrivateRoleMethodInCallinBinding started to fail with:

org.eclipse.core.runtime.AssertionFailedException: assertion failed: Search for method declaration did not find original element: void m1() [in R [in T [in T.java [in p [in src [in TestProject1532865613305]]]]]]
	at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.findAllRippleMethods(RippleMethodFinder2.java:195)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getAllRippleMethods(RippleMethodFinder2.java:170)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2.getRelatedMethods(RippleMethodFinder2.java:163)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor.initializeMethodsToRename(RenameMethodProcessor.java:248)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameMethodProcessor._OT$callOrig(RenameMethodProcessor.java:386)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor._OT$callOrig(RenameVirtualMethodProcessor.java:146)
	at org.objectteams.Team._OT$terminalCallNext(Team.java:598)
	at org.objectteams.Team._OT$callNext(Team.java:582)
	at org.eclipse.objectteams.otdt.internal.refactoring.adaptor.RenameAdaptor._OT$callNext(RenameAdaptor.java:82)
	at org.eclipse.objectteams.otdt.internal.refactoring.adaptor.RenameAdaptor$__OT__RenameVirtualMethodProcessor.doCheckFinalConditions(RenameAdaptor.java:182)
	at org.eclipse.objectteams.otdt.internal.refactoring.adaptor.RenameAdaptor._OT$callReplace(RenameAdaptor.java:95)
	at org.objectteams.Team._OT$callAllBindings(Team.java:557)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.callAllBindings(RenameVirtualMethodProcessor.java)
	at org.eclipse.jdt.internal.corext.refactoring.rename.RenameVirtualMethodProcessor.doCheckFinalConditions(RenameVirtualMethodProcessor.java)
	at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:48)
	at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:222)
	at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:162)
	at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(CheckConditionsOperation.java:79)
	at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(CreateChangeOperation.java:119)
	at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(PerformChangeOperation.java:207)

This happens because the optimization assumes that private methods have no hierarchy. Private role methods, however, do have a hierarchy, so we need to weaken that new check. This will forgo a bit of optimization, but of course correctness is primary.