Community
Participate
Working Groups
Build 20031119 In a self-hosted workspace, I checked out a couple changes from CVS, and triggered an incremental workspace build (autobuild off). Dependents got recompiled as expected, but based on the nature of the changes I did not expected any of the .class files in dependent projects to be written out.
Created attachment 6882 [details] Builder trace
Forgot to mention that my workspace had been fully builds a few minutes before. Example of surprising .class file rewritten in org.eclipse.jdt.ui: Writing changed class file SurroundWithTryCatchRefactoring.class
I copied my workspace before sync'ing up & taking the changes to ITypeBinding & TypeBinding (in which a new method was added). In the copied workspace I did a full build before adding these 2 changes. I got 28 .class files in jdt.ui which have different debug attributes (line #'s). I put 10 of the 'changed' .class files from the full build & then the incremental build in a directory for Olivier to look at.
The only diffence is in the debug attribute (line number table attribute). It looks like one of the two builds is not using the right line ends table. They should be identical if the source is the same.
The full build version is not using the right line end table. The line numbers are completely messed up. The incremental build is fine.
Full builds of my workspace using M4 do NOT produce these bogus .class files. This is a regression from M4.
Suspicion goes against #getMethodBodies(...) which is updating incorrectly the lineEnds table, though it shouldn't. Wondering if it is not simply forgetting to reset the compilationUnit slot properly using the arg one (and would incorrectly point at the last dietParsed one).
The problem comes from a side effect in setLineEnds(...). The call in getMethodBodies(...) was sharing the same memory between the lineEnds of the scanner and the compilation result line separator positions. Because another diet parse occured, it corrupted the compilation result line separator positions that are then used to generate the line number attributes. And we end up with invalid debug attributes. So it would be impossible to step properly through the code. Fixed by removing setLineEnds and inlining it where we used it. This is done to prevent other wrong usage of setLineEnds.
Fixed and released in HEAD.
Indeed a subsequent diet parse can occur upon request during name resolution of method bodies; and before we generate the original code for the initial unit. Thus altering its lineEnds table due to the sharing issue. This problem was introduced for Javadoc diagnosis in local types (since M4) and doesn't affect 2.1 stream.
Verified.
