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

Scala 2 Regression: Upper bound of a higher-kinded type variable is not included into implicit search scope #13986

Closed
neko-kai opened this issue Nov 21, 2021 · 3 comments · Fixed by #16001
Milestone

Comments

@neko-kai
Copy link
Contributor

neko-kai commented Nov 21, 2021

Compiler version

3.1.2-RC1-bin-20211118-2b37257-NIGHTLY

Minimized code

Scastie: https://scastie.scala-lang.org/mBqRVwrfQpqZeLBUKzf8xQ

package example

sealed trait Xa[T]
sealed trait Mu[T] extends Xa[T]
object Xa {
  implicit def convertMu[X[x] <: Xa[x], A, B](implicit t: X[A]): X[B] = t.asInstanceOf[X[B]]
}
object Mu {
  implicit def mu: Mu[Int] = new Mu[Int] {}
}

object App extends App {
  def constrain(a: Mu[Long]): Unit = println(a)
  constrain(Xa.convertMu)
}

Output

no implicit argument of type X[A] was found for parameter t of method convertMu in object Xa

where:    A is a type variable
          X is a type variable with constraint <: example.Mu


The following import might fix the problem:

  import example.Mu.mu

Expectation

Expected to work, as in Scala 2: https://scastie.scala-lang.org/MesjnzXeRCSarfLr7HCGHA
This seems to affect only higher-kinded types, I could not reproduce it with a non-parameterized implicit with a roughly similar setup - https://scastie.scala-lang.org/XW8Yy4CXQmSXgslU0Wktew

  • NOTE 1: Specifying just the type Mu explicitly, e.g. using partial application below will get rid of the error:

    def convertMuPartial[X[x] <: Xa[x]]: [A, B] => X[A] ?=> () => X[B] = {
      [A, B] => (t: X[A]) ?=> () => Xa.convertMu[X, A, B](t)
    }
    constrain(convertMuPartial[Mu]())

    The implicit scope gets lost only when the searchable becomes a type parameter at some point in the search.

  • NOTE 2: The searched-for type is determined correctly and applying the suggestion to import example.Mu.mu will get rid of the error. However, this import should not be required because Mu companion object should be included in implicit scope, brought in by constraint on X <: example.Mu.

In addition, varying the above setup slightly produces an assertion failure compiler crash: #13987

This error currently blocks me from porting Izumi BIO to Scala 3, where a similar implicit is used https://github.com/7mind/izumi/blob/develop/fundamentals/fundamentals-bio/src/main/scala/izumi/functional/bio/Root.scala#L120

@prolativ
Copy link
Contributor

The snippet is missing {} after new Mu[Int].

Besides that this seems to be a double regressing as adding the suggested import makes the code compile with 3.1.1-RC1 but not with 3.1.2-RC1-bin-20211118-2b37257-NIGHTLY

@neko-kai
Copy link
Contributor Author

@prolativ Good catch! I didn't check if the import actually works on Nightly, as I started minimizing with 3.1.0 and only confirmed the negative result on Nightly.

@neko-kai
Copy link
Contributor Author

neko-kai commented Aug 19, 2022

Hi, this regression remains one of the regressions preventing the port of https://github.com/izumi/izumi to Scala 3

smarter added a commit that referenced this issue Sep 9, 2022
)

Two improvements for implicit searches involving type variables.

1. We now always add a comment when an implicit search is rejected due
to the "too unspecific" criterion of #13886, commit
[Refine checking for underspecified implicit
queries](db5956b).

There have been quite a few regressions that hit that problem, so it is
good to know immediately what
   the issue is. 

2. There is now a better wildcard approximation of higher-kinded type
applications. This makes several programs (including original #15998)
compile, which were classified as not specific enough before.

Fixes #15998
Fixes #15820
Fixes #15670
Fixes #15160 
Fixes #13986
@Kordyjan Kordyjan added this to the 3.2.2 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants