if no future thread is running the future; also adjust the
policy for suspending a future so that even synchronized
operations can suspend if there's other work to be done;
also also fix `current-future' for nested `touch'es and when
parallel futures are disabled
which required adding a notion of "lightweight continuation" to
the runtime system, where a lightweight continuation involves
only frames from JIT0generated code (so that details of the stack
layout are known, for example)
Due to the bad interaction between procedure-rename and getting the
contract info from the proxy/chaperone, this will cause a failure in
the contract test cases. I'm submitting a bug report for that issue.
closes PR 11220
Altho, this does not fix the case where a function is being passed thru
another contracted function. Eg, when you give the identity function
this contract: (-> (-> integer? integer?) (-> integer? integer?))
if you pass some function with a name in there, it won't come
back with a name anymore (indeed, it won't even have the name
anymore in the body of the function).
For that, the fix would have to be put into each of the function
contract combinators.
[It will not bother me if we revert this commit. I liked SK's idea and found it easy to implement. I wonder if others will be worried that it is easy to unintentionally leave off the second argument to check-error. I also wonder if it is problematic to add new string constants, like I've done.]
Here is an example:
(check-error (/ 1 0) "/: division by zero")
(check-error (/ 1 0) "divide by zero")
(check-error (/ 1 0))
(check-error 1)
Here is the output:
Ran 4 tests.
2 of the 4 tests failed.
No signature violations.
Check failures:
check-error encountered the following error instead of the expected divide by zero
:: /: division by zero
in ex.rkt, line 2, column 0
check-error expected an error, but instead received the value 1.
in ex.rkt, line 4, column 0
