Currently, the check-info-test.rkt and standalone.rkt tests fail. We need to decide on a resolution to this issue for the upcoming 8.2 release.
The story here is that we wanted to treat exceptions during argument evaluation of check forms as errors. #109 (a revised version of #107) was merged to do that. That led to bug racket/racket#3410, a regression. That was fixed in #123, but that led to another regression in standalone.rkt. That was then intended to be fixed in #124, but it didn't work, leading to the current situation.
There's discussion of what is wrong in the comments of #124.
@AlexKnauth has a fix for one of the issues in #142 and then blesses the new test behavior for the other failure, but this uses some hackery around the representation of parameters.
After discussing this with @jackfirth @AlexKnauth @sorawee there are a few suggestions for what to do here.
The easiest solution (I think) is merging #142, provided that it really fixes all the tests.
Another approach is to use continuation marks directly for the info stack (instead of parameters) which avoids the hackery in #142.
Another possibility is to bless the current behavior in all cases.
Finally we could revert all the way back to the pre-#109 state.
My recommendation is to merge #142 and then take option 2 at a later point.
Currently, the
check-info-test.rktandstandalone.rkttests fail. We need to decide on a resolution to this issue for the upcoming 8.2 release.The story here is that we wanted to treat exceptions during argument evaluation of
checkforms as errors. #109 (a revised version of #107) was merged to do that. That led to bug racket/racket#3410, a regression. That was fixed in #123, but that led to another regression instandalone.rkt. That was then intended to be fixed in #124, but it didn't work, leading to the current situation.There's discussion of what is wrong in the comments of #124.
@AlexKnauth has a fix for one of the issues in #142 and then blesses the new test behavior for the other failure, but this uses some hackery around the representation of parameters.
After discussing this with @jackfirth @AlexKnauth @sorawee there are a few suggestions for what to do here.
My recommendation is to merge #142 and then take option 2 at a later point.
cc @racket/release