CodingSpectator does not compute the set of compilation problems before and after refactorings correctly

[Wanderer777]

If a refactoring renames or moves a compilation unit or a package, CodingSpectator would not detect any changes in compilation problems, because after such refactoring the affected compilation units (which were calculated before the refactoring was performed) no longer exist.

[Wanderer777]

CodingSpectator detects compilation problems before a refactoring is about to be performed/undone/redone and after a refactoring failed (see RefactoringProblemsListener#historyNotification(OperationHistoryEvent)). CodingSpectator correctly computes the set of affected compilation units before a refactoring is performed/undone/redone. Then, if this refactoring failed, CodingSpectator reuses the same set of affected compilation units. If a rename or move refactoring fails, then the set of affected compilation units remains valid, and CodingSpectator would correctly detect the related compilation problems. The only scenario, when CodingSpectator might not find some compilation units from the initial set of affected compilation units, is when a rename or move refactoring fails partially, and thus, some of the previously calculated compilation units are renamed or moved. But, I expect such scenario to be very rare since Eclipse implements many mechanisms to ensure that a change is either performed completely or not performed at all. Besides, it is hard to reconstruct a partially failed refactoring (which we need to do in order to update the initial set of affected compilation units), because we do not know the refactoring's point of failure.

[reprogrammer]

@Wanderer777: I created a class p.C that contained some compilation problems. Then, I renamed package p to q. After performing the refactoring, I consulted the refactoring-problems.log file, but, I didn't find any compilation problems there. Is there anything wrong with my test?

[Wanderer777]

@reprogrammer: It depends on your expectations of what should be logged to refactoring-problems.log file. If CodingSpectator should record compilation problems before a refactoring, then this is a bug in the current functionality, but it is not related to the way the set of affected files is calculated because this set is valid before a rename/move refactoring. If you expected to see the problems that remained after a refactoring, then you either need to apply a failing refactoring, or change the current code, which detects the difference in compilation problems only for the failed refactorings.