Fix in #2939 accidentally broke one (actually, inconsistent) assumption about how the lazy values are managed. This may lead to a crash, you can see an example in the newly added test. Incidentally, this does not crash on chez (yet) because of undocumented coindicence of two runtime representations in the current particular implementation (dynamically-typed languages, omg), but this can change in the future at any time. Racket fails properly.
I changed the way the primitive prim__makeFuture is called: now it reuses the way the forcing is actually implemented instead of trying to assume particular implementation. We should be more stable on potential future changes of the way lazy values are treated after this PR.
Pinging @mjustus as the merger of #2939.
UPD: Oh, and I found that one racket test actually run on chez, I think that was a copy-paste error, so I changed it.
Description
Fix in #2939 accidentally broke one (actually, inconsistent) assumption about how the lazy values are managed. This may lead to a crash, you can see an example in the newly added test. Incidentally, this does not crash on chez (yet) because of undocumented coindicence of two runtime representations in the current particular implementation (dynamically-typed languages, omg), but this can change in the future at any time. Racket fails properly.
I changed the way the primitive
prim__makeFutureis called: now it reuses the way the forcing is actually implemented instead of trying to assume particular implementation. We should be more stable on potential future changes of the way lazy values are treated after this PR.Pinging @mjustus as the merger of #2939.
UPD: Oh, and I found that one racket test actually run on chez, I think that was a copy-paste error, so I changed it.