Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a method reference of a varargs method as a BinaryOperator crashes the GWT compiler #9550

Closed
OneGeek opened this issue Sep 27, 2017 · 1 comment

Comments

@OneGeek
Copy link

OneGeek commented Sep 27, 2017

GWT version: 2.8.1
Browser (with version): N/A
Operating System: Windows 7


Description

Trying to use a method reference of a varargs method in a place that expects a BinaryOperator causes the GWT compiler to crash with the following trace:

Compiling module com.ekotrope.TestMethodReferenceArityBug
[ERROR] Unexpected internal compiler error
java.lang.ArrayIndexOutOfBoundsException: 2
	at com.google.gwt.dev.jjs.impl.GwtAstBuilder$AstVisitor.endVisit(GwtAstBuilder.java:1907)
	at org.eclipse.jdt.internal.compiler.ast.ReferenceExpression.traverse(ReferenceExpression.java:946)
	at org.eclipse.jdt.internal.compiler.ast.LocalDeclaration.traverse(LocalDeclaration.java:309)
	at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.traverse(MethodDeclaration.java:357)
	at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.traverse(TypeDeclaration.java:1360)
	at com.google.gwt.dev.jjs.impl.GwtAstBuilder.processImpl(GwtAstBuilder.java:3916)
	at com.google.gwt.dev.jjs.impl.GwtAstBuilder.process(GwtAstBuilder.java:3954)
	at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater$UnitProcessorImpl.process(CompilationStateBuilder.java:129)
	at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.process(JdtCompiler.java:384)
	at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:546)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:458)
	at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:1092)
	at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:325)
	at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:548)
	at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:479)
	at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:465)
	at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:423)
	at com.google.gwt.dev.Precompile.precompile(Precompile.java:222)
	at com.google.gwt.dev.Precompile.precompile(Precompile.java:202)
	at com.google.gwt.dev.Precompile.precompile(Precompile.java:143)
	at com.google.gwt.dev.Compiler.compile(Compiler.java:204)
	at com.google.gwt.dev.Compiler.compile(Compiler.java:155)
	at com.google.gwt.dev.Compiler.compile(Compiler.java:144)
	at com.google.gwt.dev.Compiler$1.run(Compiler.java:118)
	at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
	at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
	at com.google.gwt.dev.Compiler.main(Compiler.java:125)
Steps to reproduce
public class TestMethodReferenceArityBug implements EntryPoint
{
    @Override
    public void onModuleLoad()
    {
        BinaryOperator<Object> op = this::foo;
    }
    
    private Object foo(Object... unused)
    {
        return null;
    } 
}
Known workarounds

Wrap the call in a lambda.

BinaryOperator<Object> op = (a, b) -> foo(a,b);
@rluble
Copy link
Contributor

rluble commented Sep 28, 2017

Thanks for the clear repro case.

The construction used for method references is quite fragile and (as you noted) not correct when there are varargs. The logic in GwtAstBuilder.AstVisitor.endVisit(ReferenceExpression x, BlockScope blockScope) needs to be cleaned up.

I have started a patch here. It would be nice if someone adds tests for vararg constructor method references (with inner classes). The varargs can be in the method reference or in the functional method or both.

It would be nice to see how many of these cases fail.

@jnehlmeier jnehlmeier added this to the 2.8.2 milestone Sep 28, 2017
hubot pushed a commit that referenced this issue Oct 11, 2017
The construction of lambdas for method references is very fragile
and should be cleaned up.

Bug: #9550
Bug-Link: #9550
Change-Id: I4e3156468cefe645421a41fe49271f51f3a23feb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants