groovy

IndexOutOfBoundsException for labeled assertion statement

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.7.1
  • Fix Version/s: 1.8-beta-1
  • Component/s: Compiler
  • Labels:
    None
  • Environment:
    Mac OS 10.6.2
  • Number of attachments :
    0

Description

Try to compile the following code (or run it in GroovyConsole):

mylabel:
assert true == true

Result:

java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
	at java.util.ArrayList.RangeCheck(ArrayList.java:547)
	at java.util.ArrayList.get(ArrayList.java:322)
	at org.codehaus.groovy.transform.powerassert.SourceText.getNormalizedColumn(SourceText.java:103)
	at org.codehaus.groovy.classgen.AsmClassGenerator.record(AsmClassGenerator.java:1661)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitBinaryExpression(AsmClassGenerator.java:1625)
	at org.codehaus.groovy.ast.expr.BinaryExpression.visit(BinaryExpression.java:49)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitBooleanExpression(AsmClassGenerator.java:1901)
	at org.codehaus.groovy.ast.expr.BooleanExpression.visit(BooleanExpression.java:40)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitAssertStatement(AsmClassGenerator.java:978)
	at org.codehaus.groovy.ast.stmt.AssertStatement.visit(AssertStatement.java:47)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:161)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:707)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:51)
	at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:161)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitBlockStatement(AsmClassGenerator.java:707)
	at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:51)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:97)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:108)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitStdMethod(AsmClassGenerator.java:586)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:562)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:119)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:664)
	at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1044)
	at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50)
	at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:275)
	at org.codehaus.groovy.control.CompilationUnit$11.call(CompilationUnit.java:758)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:973)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:520)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:498)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:475)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:292)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:727)
	at groovy.lang.GroovyShell.run(GroovyShell.java:512)
	at groovy.lang.GroovyShell.run(GroovyShell.java:170)
	at groovy.lang.GroovyShell$run$1.call(Unknown Source)
	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy:848)
	at sun.reflect.GeneratedMethodAccessor423.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:66)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:151)
	at groovy.ui.Console$_runScriptImpl_closure16.doCall(Console.groovy)
	at sun.reflect.GeneratedMethodAccessor422.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:88)
	at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233)
	at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272)
	at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:886)
	at groovy.lang.Closure.call(Closure.java:276)
	at groovy.lang.Closure.call(Closure.java:271)
	at groovy.lang.Closure.run(Closure.java:354)
	at java.lang.Thread.run(Thread.java:637)

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. GROOVY-4095 Labeled statements have wrong source position

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Roshan Dawrani added a comment -

Peter, wanted to check if you have given it a look? I was just seeing where the error was coming from and it looks like a AST formation issue to me, because of which the AssertStatement has the wrong line number set on it.

I was wondering if you were planning to deal with it in the power assert code somehow (by offsetting the line number, etc)

Show
Roshan Dawrani added a comment - Peter, wanted to check if you have given it a look? I was just seeing where the error was coming from and it looks like a AST formation issue to me, because of which the AssertStatement has the wrong line number set on it. I was wondering if you were planning to deal with it in the power assert code somehow (by offsetting the line number, etc)
Hide
Permalink
Peter Niederwieser added a comment -

Thanks for reminding me. Will have a look at it.

Show
Peter Niederwieser added a comment - Thanks for reminding me. Will have a look at it.
Hide
Permalink
Roshan Dawrani added a comment -

If instead of AssertStatement, we had AssertExpression wrapped in an ExpressionStatement, then probably this line number issue wouldn't have been there. But that change seems quite widespread.

Eager to see what solution comes up for this.

Show
Roshan Dawrani added a comment - If instead of AssertStatement, we had AssertExpression wrapped in an ExpressionStatement, then probably this line number issue wouldn't have been there. But that change seems quite widespread. Eager to see what solution comes up for this.
Hide
Permalink
Peter Niederwieser added a comment -

Fixed in rev. 19521 by adding another check for invalid source position (rationale: better output nothing than to throw an IIOBE). Of course the real solution is to fix GROOVY-4095 .

Show
Peter Niederwieser added a comment - Fixed in rev. 19521 by adding another check for invalid source position (rationale: better output nothing than to throw an IIOBE). Of course the real solution is to fix GROOVY-4095 .
Hide
Permalink
Roshan Dawrani added a comment -

When the assertion fails, the big/almost-blank message looks a bit weird now:

Caught: Assertion failed: 

:


	at Try.run(Try.groovy:2)
Show
Roshan Dawrani added a comment - When the assertion fails, the big/almost-blank message looks a bit weird now: Caught: Assertion failed: : at Try.run(Try.groovy:2)
Hide
Permalink
Peter Niederwieser added a comment -

It's now up to GROOVY-4095 to fix this.

Show
Peter Niederwieser added a comment - It's now up to GROOVY-4095 to fix this.
Hide
Permalink
Peter Niederwieser added a comment -

Actually I'm not sure if GROOVY-4095 is sufficient for correct rendering of labeled asserts, but it's necessary.

Show
Peter Niederwieser added a comment - Actually I'm not sure if GROOVY-4095 is sufficient for correct rendering of labeled asserts, but it's necessary.
Hide
Permalink
Roshan Dawrani added a comment -

Wherever it gets fixed - I just wanted to record the bit that still does not look correct.

I think wrong rendering of labeled asserts and wrong line number on AssertStatementare 2 different things.

I will make a note of wrong rendering under GROOVY-4095 as well - for information.

Show
Roshan Dawrani added a comment - Wherever it gets fixed - I just wanted to record the bit that still does not look correct. I think wrong rendering of labeled asserts and wrong line number on AssertStatementare 2 different things. I will make a note of wrong rendering under GROOVY-4095 as well - for information.
Hide
Permalink
Peter Niederwieser added a comment -

>I think wrong rendering of labeled asserts and wrong line number on AssertStatementare 2 different things.
These two things are strongly correlated. The source code for the assertion is not captured (and thus displayed) correctly because the source position is wrong. The values aren't displayed because AssertionRenderer detects that source position is wrong, in which case it doesn't render the value(s).
>wrong line number on AssertStatementare
Just to be clear, it's not wrong source position of assert statements, but wrong source position of (any) labeled statement.

Show
Peter Niederwieser added a comment - >I think wrong rendering of labeled asserts and wrong line number on AssertStatementare 2 different things. These two things are strongly correlated. The source code for the assertion is not captured (and thus displayed) correctly because the source position is wrong. The values aren't displayed because AssertionRenderer detects that source position is wrong, in which case it doesn't render the value(s). >wrong line number on AssertStatementare Just to be clear, it's not wrong source position of assert statements, but wrong source position of (any) labeled statement.
Hide
Permalink
Roshan Dawrani added a comment -

>> wrong line number on AssertStatementare
> Just to be clear, it's not wrong source position of assert statements, but wrong source position of (any) labeled statement.

I know that the source position is not specific to AssertStatement but to others as well but the issue here is specific to AssertStatement. I had tried a few more labeled statements but for them it didn't seem to matter much because expressions inside the statements were still carrying the correct source information. I didn't test extensively though.

That's the reason that as an initial experiment I was exploring having ExpressionStatement (AssertExpression) instead of AssertStatement so that AssertExpression continued to carry the correct source information for power assert and ":" source location was set on wrapping ExpressionStatement, which mattered less.

Show
Roshan Dawrani added a comment - >> wrong line number on AssertStatementare > Just to be clear, it's not wrong source position of assert statements, but wrong source position of (any) labeled statement. I know that the source position is not specific to AssertStatement but to others as well but the issue here is specific to AssertStatement. I had tried a few more labeled statements but for them it didn't seem to matter much because expressions inside the statements were still carrying the correct source information. I didn't test extensively though. That's the reason that as an initial experiment I was exploring having ExpressionStatement (AssertExpression) instead of AssertStatement so that AssertExpression continued to carry the correct source information for power assert and ":" source location was set on wrapping ExpressionStatement, which mattered less.

People

  • Assignee:
    Peter Niederwieser
    Reporter:
    Peter Niederwieser
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: