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

Implicit value can no longer be accessed via implicit conversion #15670

Closed
WojciechMazur opened this issue Jul 13, 2022 · 6 comments · Fixed by #16001
Closed

Implicit value can no longer be accessed via implicit conversion #15670

WojciechMazur opened this issue Jul 13, 2022 · 6 comments · Fixed by #16001

Comments

@WojciechMazur
Copy link
Contributor

Community build regression for https://github.com/giiita/refuel (maintainer @giiita)
Based on Open Community Build #1884
Part of #15647 regressions tracker

Compiler version

Works in 3.1.1
Fails in 3.1.2 and 3.1.3
Fails in 3.2.0-RC* and 3.2.1-RC1-bin-20220711-6efd92d-NIGHTLY

Minimized code

trait JsonRowEntry {
  def readAs[E](implicit c: Read[E]): Option[E] = ???
}
trait Read[T]
trait Codec[T] extends Read[T]
trait CodecTypeProjection[C[_]]
object JsonTransform  {
  given SetCodec[T, C[_]: CodecTypeProjection]: scala.Conversion[C[T], C[Set[T]]] = ???
  given SetCodecExp[T, C[_]: CodecTypeProjection](using codec: C[T]): C[Set[T]] = codec
  given Codec[String] = ???
  given CodecTypeProjection[Read] = ???
}

@main def Test() = {
  import JsonTransform.given
  val tree = new JsonRowEntry {}
  tree.readAs[Set[String]]
}

Output

rror] ./test.scala:17:27: No given instance of type Read[Set[String]] was found for parameter c of method readAs in trait JsonRowEntry.
[error] I found:
[error] 
[error]     JsonTransform.SetCodecExp[String, C](
[error]       JsonTransform.given_CodecTypeProjection_Read
[error]     , /* missing */summon[C[String]])
[error] 
[error] But no implicit values were found that match type C[String].
[error]   tree.readAs[Set[String]]
[error]              

Expectation

Should be able to find correct implicit value by usage of implicit conversion

@griggt
Copy link
Contributor

griggt commented Jul 14, 2022

First bad commit is db5956b from #13886

@odersky
Copy link
Contributor

odersky commented Jul 14, 2022

That one is as expected. We now refuse to search implicits for type variables that are unknown, and we know that this will refuse to compile some code that compiled before. The reason for the restriction is that there is a latent danger of unboundedly long implicit searches, in particular as programs grow. That's more important than a small expressiveness win.

@odersky odersky closed this as completed Jul 14, 2022
@odersky odersky added stat:wontfix and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Jul 14, 2022
@smarter
Copy link
Member

smarter commented Jul 14, 2022

Related: #15160

@griggt griggt closed this as not planned Won't fix, can't repro, duplicate, stale Jul 14, 2022
@KacperFKorban
Copy link
Member

KacperFKorban commented Jul 16, 2022

I found a similar issue in earogov/ordset

Compiled for 3.0.0, ..., 3.1.1
Gives an error for 3.1.2, .., 3.2.0-RC1, 3.2.1-RC1-bin-20220715-d247c37-NIGHTLY

trait Box[E]

trait Domain

def fun[E, D[_] <: Domain](box: Box[E])(implicit domain: D[E]): Unit = {

  val newBox: Box[E] =  ???

  fun(newBox)
}

error:

[error] ./main.scala:11:14: No given instance of type D[E] was found for parameter domain of method fun
[error] 
[error] where:    D is a type variable with constraint <: [_] =>> Domain
[error]   fun(newBox)
[error]              ^

Is this behavior also expected? @odersky

@odersky
Copy link
Contributor

odersky commented Jul 16, 2022

Is this behavior also expected? @odersky

Probably. It looks similar. We know for sure if it is the same commit that broke it.

@KacperFKorban
Copy link
Member

The commit that broke it is the same (db5956b), so it probably is also expected.

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.

6 participants