Bug 314365

Description Andrew Clement 2010-05-25 17:32:47 EDT

AJDT uses a pointcut like this:

(persingleton(org.eclipse.ajdt.internal.ui.ras.UIFFDC) && ((handler(java.lang.Throwable+) && args(arg1)) && ((within(org.eclipse.ajdt..*) && (!within(org.eclipse.ajdt.internal.ui.lazystart..*) && (!within(org.eclipse.ajdt.internal.ui.dialogs.OpenTypeSelectionDialog2) && !(within(org.eclipse.ajdt.internal.ui.editor.AspectJBreakpointRulerAction) && handler(org.eclipse.jface.text.BadLocationException))))) && (!(within(org.eclipse.ajdt.core.ras.FFDC+) || handler(org.eclipse.core.runtime.OperationCanceledException)) && !this(java.lang.Object)))))

After the pointcut rewriter has chewed on it, it is reduced to a normal form.  This is meant to be a stable form such that further rewrites of it would not change it.  This turned out not to be the case.  The hashcodes for some of the components were quite large and manifested as negative integers.  The arithmetic in the comparator for the elements would have a problem and give unhelpful responses.  For example, if the elements were C,B,A it might rewrite them to A,B,C but on a subsequent rewrite it would realise that C was less than A, giving B,C,A.  Whether it went wrong was dependent on the order in which the elements were collected by the rewriter.

This is now fixed.  It impacts incremental compilation sometimes as two pointcuts that should be identical look different because one has been through the rewritter more times than the other...