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

Avoid spurious suboptimal code errors for code produced by implicit arg inference #183

Open
julien-truffaut opened this issue Feb 25, 2015 · 8 comments

Comments

@julien-truffaut
Copy link

I am getting the following error when I try to define a scalacheck property that generates an object with miniboxed annotation:

Error:(42, 10) Using the type argument "Any" for the miniboxed type parameter T1 of class AbstractMiniboxedFunction1 is not specific enough, as it could mean either a primitive or a reference type. Although class AbstractMiniboxedFunction1 is miniboxed, it won't benefit from specialization:
    check((as: ConsList[Int]) =>
         ^

link to the code: https://github.com/julien-truffaut/brique/blob/miniboxing/tests/src/test/scala/brique/tests/ConsListSpec.scala#L42

@VladUreche
Copy link
Member

That's a warning that somehow ends up being seen as an error -- I will see what's happening. Thanks for the report!

@julien-truffaut
Copy link
Author

I think it is my project configuration that transforms all warning on errors

@VladUreche
Copy link
Member

In that case, maybe you can run the compilation with -P:minibox:warn-off, so miniboxing stops issuing warnings for every little optimization that could be done.

@VladUreche
Copy link
Member

This one took all night to track down, literally:

$ cat gh-bug-183.scala 
package miniboxing.tests.bug183

import scala.language.implicitConversions

class ConsListSpec {

  class Pretty
  implicit def f(a: Any): Pretty = ???
  def check[P](implicit p: P => Pretty): Unit = ???

  check[String]
}

$ mb-scalac gh-bug-183.scala
gh-bug-183.scala:11: warning: Using the type argument "Any" for the miniboxed type parameter T1 of class AbstractMiniboxedFunction1 is not specific enough, as it could mean either a primitive or a reference type. Although class AbstractMiniboxedFunction1 is miniboxed, it won't benefit from specialization:
  check[String]
       ^
one warning found

@VladUreche
Copy link
Member

Since it's quite late, I will leave this bug open, since -P:minibox:warn-off fixes it.

@VladUreche
Copy link
Member

Quick update on this bug: In the morning I tried the simple idea I had, but it's not smart enough to discriminate well between real and spurious errors -- it hides real errors and leaves some spurious ones 👎

@VladUreche VladUreche changed the title scalacheck with miniboxing Avoid spurious suboptimal code errors for code produced by implicit arg inference Mar 5, 2015
@VladUreche
Copy link
Member

To explain the problem: the warning is legit, the code it warns about is indeed suboptimal. But the code is not written by you, it's the result of implicit argument inference, so I don't even know what to do about it:

  • it's legit, the code is really suboptimal
  • it's not the programmer's code, so there should be a special warning saying it's inferred
  • by the time the miniboxing plugin sees this code, there's no trace that it was introduced by implicit lookup anymore, so it looks exactly like programmer code

Still don't know what to do about this...

@julien-truffaut
Copy link
Author

would it be possible to disable warning on locally? I mean it is very useful to get the warning but at the moment they are cases where you cannot do anything about it. Basically something similar to @unchecked for pattern match.

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