-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Very slow compile time involving path-dependent types #15525
Comments
I tried to reproduce that and it is hanging for me for a few minutes on the current main. This is something nasty. |
Oh, I see now! I lost the definition of The correct case is also taking longer to compile but it is not that dramatic. |
I looked into this a bit more. It seems that tp1 = Delegating[?1.Type / ?2.Type / ... / ?15.Type / (?16 : Resolution[Delegating[Unit]])#Type]
tp2 = Delegating[?17.Type / ?18.Type / ... / ?31.Type / ?32.Type] The tp1 = Delegating[(param)1#Type / (param)2#Type / ... / (param)15#Type / (param)16#Type]
tp2 = Delegating[Aux[Delegating[Unit]] / Aux[Delegating[Unit]] / ... / Aux[Delegating[Unit]] / Aux[Delegating[Unit]]] Type-checking this is as fast as you would expect. Does it make sense to get rid of |
I checked that indeed every increase in element number by one gives twice as many subtype calls. (How?: I turned the inline value Stats.enabled on, compiled with -Ydetailed-stats and looked at the number of "total subtype" entries for various sizes of element.). The reason, I believe is this: When testing equality |
…ucture Two deeply applied types with the same structure uses recursive isSameType tests. Each of these translated to two isSubType tests which can lead to exponential blowup relative to the type's nesting depth. This problem does not occur if the two types are `eq`. But two types might still be structurally equal modulo dealiasing. We now cache isSameType successes after a certain nesting level to avoid recomputation. Fixes scala#15525. Reclassifies scala#15365 as a pos test
This helps in the particular test case because then the two types that are compared hash-cons after dealiasing to the same type. But the fix in #15556 is more general. |
Compiler version
3.1.2
Minimized code
Given the minimized code:
The following code compiles almost instantly (which is expected):
But the following example, which is just a slightly bigger version of the previous example (22 instead of 16 parameters), takes 10+ seconds to compile on my machine:
My “real” (not minimized code) has a few more parameters and takes ages to compile (did not finish yet after a several minutes), which makes me think that code in this shape maybe triggers some kind of exponential explosion in the type checker.
Expectation
Scala 2.13 compiles the code instantly. The expectation would be the same for Scala 3.
Note
FYI, I found #14224, which may or may not have the same root cause.
The text was updated successfully, but these errors were encountered: