Skip to content

Warning in mixed compilation with java classfile on classpath #20

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

Closed
retronym opened this issue Aug 5, 2015 · 1 comment
Closed

Warning in mixed compilation with java classfile on classpath #20

retronym opened this issue Aug 5, 2015 · 1 comment
Assignees
Milestone

Comments

@retronym
Copy link
Member

retronym commented Aug 5, 2015

A.java

public class A {
  public static final int bar() { return 100; }
  public final int baz() { return 100; }
}

Test.scala

class C {
  @inline final def foo = A.bar()
  @inline final def fii(a: A) = a.baz()
  def t = foo + fii(new A)
}
lucmac:sandbox luc$ javac A.java 
lucmac:sandbox luc$ qsc -Yopt:l:classpath -Yopt-warnings:_ Test.scala A.java 
Test.scala:2: warning: there was a problem determining if method bar can be inlined:
No inline information for method A::bar()I could be found.
  @inline final def foo = A.bar()
                               ^
one warning found

Here's the InlineInfo for A (copied from the debugger), note that method bar is not in there:

InlineInfo(None,false,Map(<init>()V -> MethodInlineInfo(false,false,false,false), baz()I -> MethodInlineInfo(true,false,false,false)),None)

Probably related to the fact that bar is static. Check how the inline info is built: from classfile? symbol? note that A.java is being "compiled". When A.java is not passed to scalac (A.class read from the classpath), there's no warning.

retronym added a commit that referenced this issue Aug 24, 2015
Calls to synthetic case class apply methods are inlined to the
underlying constructor invocation in refchecks.

However, this can lead to accessibility errors if the constructor
is private.

This commit ensures that the constructor is at least as accessible
as the apply method before performing this tranform.

I've manually checked that other the optimization still works in other
cases:

scala> class CaseApply { Some(42)  }
defined class CaseApply

    scala> :javap -c CaseApply
    Compiled from "<console>"
    public class CaseApply {
      public CaseApply();
        Code:
           0: aload_0
           1: invokespecial #9                  // Method java/lang/Object."<init>":()V
           4: new           #11                 // class scala/Some
           7: dup
           8: bipush        42
          10: invokestatic  #17                 // Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
          13: invokespecial #20                 // Method scala/Some."<init>":(Ljava/lang/Object;)V
          16: pop
          17: return
    }
@lrytz lrytz added this to the 2.12.0-RC1 milestone May 17, 2016
@lrytz lrytz self-assigned this Jul 4, 2016
@lrytz
Copy link
Member

lrytz commented Jul 19, 2016

scala/scala#5291

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

2 participants