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

Regression in typer method dispatch when using context bounds with ClassTag of function #17245

Closed
WojciechMazur opened this issue Apr 13, 2023 · 2 comments · Fixed by #18286
Closed
Assignees
Labels
area:typer itype:bug regression This worked in a previous version but doesn't anymore
Milestone

Comments

@WojciechMazur
Copy link
Contributor

Compiler version

3.3.1-RC1-nighlty

Last good release: 3.3.1-RC1-bin-20230302-8020c77-NIGHTLY
First bad release: 3.3.1-RC1-bin-20230303-6ad22aa-NIGHTLY

The commit-based bisect for range of commits 8020c77..6ad22aa failed due to other failures.

Minimized code

Based on Open CB failures in pjfanning/akka-rabbitmq, compilation logs can be found here: https://github.com/VirtusLab/community-build3/actions/runs/4650721329/jobs/8229907414

import scala.reflect.ClassTag

trait MockSettings

object Mockito {
  def mock[T : ClassTag]: T = ???
  def mock[T : ClassTag](settings: MockSettings): T = ??? 
}

trait Channel 
type OnChannel = Channel => Any

@main def Test =
  val fail1: OnChannel = Mockito.mock[OnChannel] // fails
  val fail2: OnChannel = Mockito.mock // fails

  val workaround1 = Mockito.mock[OnChannel]  // compiles
  val workaround2: OnChannel =  Mockito.mock[OnChannel](summon[ClassTag[OnChannel]]) // compiles  

Output

-- [E134] Type Error: /workspace/dotty/bisect/main.scala:14:33 -----------------
14 |  val fail1: OnChannel = Mockito.mock[OnChannel] // fails
   |                         ^^^^^^^^^^^^
   |None of the overloaded alternatives of method mock in object Mockito with types
   | [T](settings: MockSettings)(implicit evidence$2: reflect.ClassTag[T]): T
   | [T](implicit evidence$1: reflect.ClassTag[T²]): T²
   |match type arguments [OnChannel] and expected type OnChannel
   |
   |where:    T  is a type variable
   |          T² is a type variable
-- [E134] Type Error: /workspace/dotty/bisect/main.scala:15:33 -----------------
15 |  val fail2: OnChannel = Mockito.mock // fails
   |                         ^^^^^^^^^^^^
   |None of the overloaded alternatives of method mock in object Mockito with types
   | [T](settings: MockSettings)(implicit evidence$2: reflect.ClassTag[T]): T
   | [T](implicit evidence$1: reflect.ClassTag[T²]): T²
   |match expected type OnChannel
   |
   |where:    T  is a type variable
   |          T² is a type variable
2 errors found

Expectation

Compiler should pick def mock[T : ClassTag]: T and allow for compilation

@WojciechMazur WojciechMazur added itype:bug area:typer regression This worked in a previous version but doesn't anymore labels Apr 13, 2023
@Kordyjan
Copy link
Contributor

According to bisect, it was broken by #16507
@natsukagami, @nicolasstucki, what do you think?

@nicolasstucki
Copy link
Contributor

It might be due to an unintended change with MethodTypes or function types.

@nicolasstucki nicolasstucki self-assigned this Jul 14, 2023
@jchyb jchyb assigned jchyb and unassigned nicolasstucki Jul 20, 2023
jchyb added a commit to dotty-staging/dotty that referenced this issue Jul 25, 2023
jchyb added a commit to dotty-staging/dotty that referenced this issue Jul 25, 2023
jchyb added a commit that referenced this issue Jul 27, 2023
The problem lied with slightly adjusted unapply of FunctionOf in a
previous PR, which caused different behavior in `resolveOverloaded`,
where due to a pattern match into a FunctionOf
`resolveOverloaded1` would return no candidates, causing more issues
later on.

To keep the new behavior of FunctionOf unapply (which as a side-effect
ended up fixing few issues represented with added tests), with the previous
behavior of overloaded functions, we allow the method candidate
filtering to fallback from the FunctionOf candidate filtering into the
previous behavior in case no candidates are kept. This also fixes an
additional case, which is not part of the regression, but produces
an incorrect error in similar manner.

Fixes #17245
@Kordyjan Kordyjan added the backport:accepted This PR needs to be backported, once it's been backported replace this tag by "backport:done" label Jul 31, 2023
@Kordyjan Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
@Kordyjan Kordyjan removed the backport:accepted This PR needs to be backported, once it's been backported replace this tag by "backport:done" label Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:typer itype:bug regression This worked in a previous version but doesn't anymore
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants