Community
Participate
Working Groups
Compile the following class with -1.5 -g : public class LineNumberBug { class Inner { public Inner() { System.out.println("Inner()"); } // line 10 } public static void main(String[] args) { new LineNumberBug().new Inner(); } } Inspecting the generated line number table you'll see that the first few instructions are mapped to line 10, which is at least confusing.
Created attachment 193971 [details] test & proposed fix Here's the same test as a regression test case and a proposed simple fix. The line in question was last modified for bug 15250 to ensure that the free return maps to the closing brace rather than the ctor header. For target < 1.4 this seemed to work OK, but since 1.4 a constructor of an inner class may have instructions before the super-ctor call, which assign to the this$0 synthetic field. PC positions for these instructions (generated from generateSyntheticFieldInitializationsIfNecessary(..)) are never recorded, but this line codeStream.recordPositionsFrom(0, this.bodyEnd) will actually be applied to those leading instructions. At first look it seems safe to just avoid using a startPC of 0, but simply remembering the position before the free return is generated. Unfortunately I couldn't find any tests for bug 15250 to see if the change breaks anything. Also, the "0" argument has been there since day one, so I can't see why it is there. Any idea?
Created attachment 193972 [details] Alternative fix I guess this fix is even better and has minimal impact: Instead of changing the final recordPositionsFrom(..) I simply added another call to this method right where it was missing: immediately after generateSyntheticFieldInitializationsIfNecessary(..)
Looks good. Targeting M7.
Created attachment 194026 [details] previous patch with copyright updated The same patch as before (second strategy) with copyright updated.
Released for 3.7M7.
Will be verified once a build with v_B51 is available.
Verified.
