[ https://issues.apache.org/jira/browse/GROOVY-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul King resolved GROOVY-8742. ------------------------------- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.4.16 2.5.5 3.0.0-alpha-4 >From my and Eric's testing we believe this was resolved as part of GROOVY-7647. > Line number information for method is confusing debugger > -------------------------------------------------------- > > Key: GROOVY-8742 > URL: https://issues.apache.org/jira/browse/GROOVY-8742 > Project: Groovy > Issue Type: Bug > Components: bytecode, class generator > Affects Versions: 2.4.15 > Reporter: Eric Milles > Assignee: Paul King > Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.5, 2.4.16 > > > I have been investigating a case where the IDE will not break on a line > breakpoint in a test method. This method has no parameters or local > variables (this affects its line number table in the bytecode) and the code > is all on one line, with a chain of three method calls. When line-breaking > the code or assigning to temporary, the line numbers table changes and the > line breakpoints work as expected. > {code:groovy} > package a > import org.junit.* > final class Tests { > @Test > void testSomething() { // line 29 > Assert.assertFalse(this.method(one(), "two", Three.class)) // line 30 > } > boolean method(... args) { true } > def one() {} > } > {code} > When compiled with Groovy 2.4 and normal/dynamic groovy, the method has line > information: > {code} > Line numbers: > [pc: 4, line: 29] > [pc: 19, line: 30] > [pc: 68, line: 30] > Local variable table: > [pc: 0, pc: 109] local: this index: 0 type: a.Tests > {code} > I have not tried with the "fast path" optimization disabled. I think its > prelude is what bumps the PC from 0 to 4 and results in the two PC entries > for line 30 (pc 19 and pc 68). > If I assign the result of {{method}} to a new local variable, the line > numbers are altered: > {code} > Line numbers: > [pc: 6, line: 30] > [pc: 63, line: 30] > [pc: 100, line: 31] > Local variable table: > [pc: 0, pc: 113] local: this index: 0 type: a.Tests > [pc: 6, pc: 113] local: variable index: 2 type: java.lang.Object > {code} > If I compile with invoke dynamic on, I get this for the original code: > {code} > Line numbers: > [pc: 0, line: 30] > Local variable table: > [pc: 0, pc: 30] local: this index: 0 type: a.Tests > {code} > I'm not sure the exact outcome expected here in terms of the bytecode, but I > looked at similar methods from Java sources. For a Java test method, the > line number table began with {{[pc: 0, line: whatever]}}. > I looked at GROOVY-4505, which mentions that > {{AsmClassGenerator.visitBlockStatement}} should not be writing line number > information for the block statement (the source of line 29). > {{StatementWriter.writeBlockStatement}} indeed retains a note about this. > However, the overload in {{OptimizingStatementWriter}} still triggers > `onLineNumber` from its `writeBlockStatement` -> {{writeGuards}}. Should > {{onLineNumber}} check for {{BlockStatement}} and exit early? I tried this > quickly and it did alter the line numbers table, but it did not help my > debugger find the breakpoint on line 30. -- This message was sent by Atlassian JIRA (v7.6.3#76005)