You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current divergence checker computes the "stripped core" of the types it's resolving implicits for before computing their relative complexity. Unfortunately a missed case in the core computation means that divergent types can be smuggled into the resolution as arguments to a TypeRef and are not counted towards the overall complexity of the type. This causes implicit resolution to loop until stack overflow.
traitFoo[F[_]]
objectFoo {
implicitdefmkFoo[F[_]](implicitff: Foo[({ typeλ[t] =F[F[t]] })#λ]):Foo[F] =???
}
traitBar[F[_]]
objectBar {
implicitdefmkBar[F[_]](implicitbb: Bar[λ forSome { typeλ[t] <:F[t] }]):Bar[F] =???
}
implicitly[Foo[List]] // compile time hang
implicitly[Bar[List]] // compile time hang
I realized after PR'ing this that core only eliminating top levelExistentialTypes and PolyTypes is as per the spec. However, the computation in complexity seems to be assuming that all existentials and poly types have been eliminated throughout.
It would be possible to cover the missing cases in complexity, but it's not clear to me what that buys us over making the change in core as here. I note that in Dotty the stripped core is completely absent and instead we have a typeSize which appears to compute the normalized size of a type directly without constructing the intermediate stripped core type. On balance I would prefer to follow Dotty's approach here.
As reported here, this PR causes a significant slowdown when performing implicit searches for large types: in the case of the "select from large hlist" benchmark it roughly doubles the compile time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current divergence checker computes the "stripped core" of the types it's resolving implicits for before computing their relative complexity. Unfortunately a missed case in the core computation means that divergent types can be smuggled into the resolution as arguments to a
TypeRefand are not counted towards the overall complexity of the type. This causes implicit resolution to loop until stack overflow.Issue reported as scala/bug#10833.
The fix is to have the computation of the core type traverse through the arguments ofTypeRefs.Nb. this fix will also be in the byname implicits PR shortly, but I thought it would be useful to get this change reviewed independently.See comment below ...