Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Lin Bytes
tests are a pain point as witnessed by #544 #541 #526 #520 #518.This PR improves on the situation by adding a
Bytes.to_seq
target which is a known source of domain-unsafety from theSTM.domain
test, yet was missing from theLin
tests. This addition means theLin_thread
test triggers much more reliably too, so it can be turned into an appropriate negative test.Finally, shrink time of the
Lin Bytes Domain
test is a genuine issue #520 (it just happened again today). While trying to ramp up the targeted bindings of the corresponding STM Bytes tests today, I was playing with adding acmd
shrinker and started seeing similar longer shrink times when I added it forOne problem is shrinking order: in STM, writing the shrinker by myself I could customize it to my liking, reducing the length and index integers first, and only the string secondly. Another problem is the
string
shrinker reducing each char repeatedly:This will take quite a bit of time to reach the
'a'
goal for each entry, and repeatedly start over attempting to do so.To improve on the situation, the PR therefore adds a quick-and-dirty char-shrinker for both strings and bytes in Lin, that simply attempts to reduce a non-
'a'
to'a'
. As a result, shrinking for these should now work much faster out of the box.Overall I'm hoping this fixes #544 #541 #520 #518 and thus represents a good step forward reliability-wise.
#526 is most likely due to Cygwin (signal?) issues and so remains open.