Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[REVERTED] Prune polymorphic implicits more aggressively#7067

Merged
adriaanm merged 1 commit into
scala:2.12.xfrom
milessabin:topic/implicit-poly-prune-2.12.x
Sep 7, 2018
Merged

[REVERTED] Prune polymorphic implicits more aggressively#7067
adriaanm merged 1 commit into
scala:2.12.xfrom
milessabin:topic/implicit-poly-prune-2.12.x

Conversation

@milessabin
Copy link
Copy Markdown
Contributor

This is a backport of #6580 targetting 2.12.7.

In rankImplicits, before we attempt to fully typecheck the pending candidate implicit, we first attempt to partially instantiate type variables in both the candidate and the target type and check for compatibility. If the compatibility check fails we can immediately prune the the candidate without having to fully typecheck it.

In the kinds of implicit searches typical of the inductive style found in shapeless and related libraries this can result in a drastic reduction in the search space and a corresponding reduction in compile
times.

As an added bonus users of shapeless and shapeless based libraries which use shapeless's Lazy type will see benefits immediately without needing to wait for and port to byname implicit arguments.

@milessabin milessabin added the performance the need for speed. usually compiler performance, sometimes runtime performance. label Aug 14, 2018
@milessabin milessabin added this to the 2.12.7 milestone Aug 14, 2018
@milessabin milessabin requested a review from adriaanm August 14, 2018 06:48
@milessabin

This comment has been minimized.

@milessabin

This comment has been minimized.

@SethTisue

This comment has been minimized.

In rankImplicits, before we attempt to fully typecheck the pending
candidate implicit, we first attempt to partially instantiate type
variables in both the candidate and the target type and check for
compatibility. If the compatibility check fails we can immediately prune
the the candidate without having to fully typecheck it.

In the kinds of implicit searches typical of the inductive style found
in shapeless and related libraries this can result in a drastic
reduction in the search space and a corresponding reduction in compile
times.

As an added bonus users of shapeless and shapeless based libraries which
use shapeless's Lazy type will see benefits immediately without needing
to wait for and port to byname implicit arguments.
@milessabin milessabin force-pushed the topic/implicit-poly-prune-2.12.x branch from 306c280 to 73da4fc Compare August 16, 2018 14:08
@milessabin
Copy link
Copy Markdown
Contributor Author

Rebased ...

@milessabin
Copy link
Copy Markdown
Contributor Author

Awesome 🙂

@SethTisue SethTisue added the release-notes worth highlighting in next release notes label Sep 7, 2018
@adriaanm
Copy link
Copy Markdown
Contributor

@milessabin this regressed a usage of specs2, discovered while running the community build on 2.12.7:

[eff] [error] /home/jenkins/workspace/scala-2.12.x-integrate-community-build/target-0.9.14/project-builds/eff-75b7286f9b1298d2e68cdf27ff1ce0b8e8a5f0c7/scalaz/src/test/scala/org/atnos/eff/addon/scalaz/concurrent/TaskEffectSpec.scala:57:65: type mismatch;
[eff] [error]  found   : => Int(30)
[eff] [error]  required: org.specs2.matcher.Expectable[?]
[eff] [error] Note that implicit conversions are not applicable because they are ambiguous:
[eff] [error]  both method thisValue in trait ShouldExpectations of type [T](t: => T)org.specs2.matcher.ShouldExpectable[T]
[eff] [error]  and method theValue in trait MustExpectations1 of type [T](t: => T)org.specs2.matcher.MustExpectable[T]
[eff] [error]  are possible conversion functions from => Int(30) to org.specs2.matcher.Expectable[?]
[eff] [error]       action[S].runOption.runSequential must returnValue(beSome(30))
[eff] [error]                                                                 ^
[eff] [error] /home/jenkins/workspace/scala-2.12.x-integrate-community-build/target-0.9.14/project-builds/eff-75b7286f9b1298d2e68cdf27ff1ce0b8e8a5f0c7/scalaz/src/test/scala/org/atnos/eff/addon/scalaz/concurrent/TaskEffectSpec.scala:68:84: type mismatch;
[eff] [error]  found   : => Throwable
[eff] [error]  required: org.specs2.matcher.Expectable[?]
[eff] [error] Note that implicit conversions are not applicable because they are ambiguous:
[eff] [error]  both method thisValue in trait ShouldExpectations of type [T](t: => T)org.specs2.matcher.ShouldExpectable[T]
[eff] [error]  and method theValue in trait MustExpectations1 of type [T](t: => T)org.specs2.matcher.MustExpectable[T]
[eff] [error]  are possible conversion functions from => Throwable to org.specs2.matcher.Expectable[?]
[eff] [error]       action[S].taskAttempt.runOption.runSequential must returnValue(beSome(beLeft(boomException)))
[eff] [error]                                                                                    ^
[eff] [error] two errors found
[eff] [error] (scalaz / Test / compileIncremental) Compilation failed

I confirmed that reverting this PR (and the undoLog changes from 6ea993a) makes it compile again. I'm not sure it's the same instance of the problem that you saw in the 2.13.x version. Thoughts?

@adriaanm
Copy link
Copy Markdown
Contributor

Given how far past the 2.12.7 deadline we are, I decided to revert as much as needed to get the community build to go green. We'll have to save these improvements for 2.13

@adriaanm adriaanm mentioned this pull request Sep 25, 2018
@SethTisue SethTisue removed this from the 2.12.7 milestone Sep 25, 2018
@SethTisue SethTisue removed the release-notes worth highlighting in next release notes label Sep 25, 2018
adriaanm added a commit to adriaanm/scalajs-react that referenced this pull request Sep 28, 2018
@SethTisue SethTisue changed the title Prune polymorphic implicits more aggressively [REVERTED] Prune polymorphic implicits more aggressively Mar 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance the need for speed. usually compiler performance, sometimes runtime performance.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants