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
{{ message }}
Repository navigation
Type checker hangs on recursive type with arrays #41771
Hmm, so the problem is that every time we instantiate the false type, the length of the T argument doubles because of the two spreads. The instantiation depth limit is 50, which means by the time we hit it, we’re dealing with a tuple with length 250 ≈ 1.13×1015, which is a pretty long tuple. (I assume this does eventually terminate by running out of memory, but didn’t feel like sticking around to see how long that takes.)
Should there just be a limit on how many elements we’ll try to spread into a tuple? If we hit that limit, do we issue an error or create an array instead?
Activity
andrewbranch commentedon Jan 20, 2021
Hmm, so the problem is that every time we instantiate the false type, the length of the
Targument doubles because of the two spreads. The instantiation depth limit is 50, which means by the time we hit it, we’re dealing with a tuple with length 250 ≈ 1.13×1015, which is a pretty long tuple. (I assume this does eventually terminate by running out of memory, but didn’t feel like sticking around to see how long that takes.)Should there just be a limit on how many elements we’ll try to spread into a tuple? If we hit that limit, do we issue an error or create an array instead?