Restrictive upper bound on QuickCheck 2.10.1 hides potential segfault

[snoyberg]

QuickCheck-2.10.1 is out of bounds for:

• text-1.2.3.0 (>=2.7 && < 2.10). No maintainer. @haskell. Used by: test-suite

[hvr]

This is intentional: the test-suite isn't yet compatible with QC 2.10's semantics, hence why I set the upper bound. But it's no big deal either; the cabal solver simply falls back to the most recent compatible QC version for Travis CI.

[snoyberg]

I see two test failures with the newer QuickCheck:

    errors:
      t_utf8_err: [Failed]
*** Failed! (after 6 tests): 
Exception:
  Data.Text.Array.unsafeWrite: bounds error, offset 4, length 4
  CallStack (from HasCallStack):
    error, called at ./Data/Text/Array.hs:163:37 in main:Data.Text.Array
Solo
Replace
"\240\129\140\154"
(used seed -4447769247167586605)

      t_infix_concat: [Failed]
*** Failed! (after 52 tests and 16 shrinks): 
Exception:
  Data.Text.Array.unsafeIndex: bounds error, offset 2, length 2
  CallStack (from HasCallStack):
    error, called at ./Data/Text/Array.hs:155:36 in main:Data.Text.Array
"\128"
"a"
""
Just '\428388'
(used seed -7715035259973790205)

What I'm concerned about in these results is that this looks like it's uncovering a legitimate bug in the library, not a mismatch with new semantic in QuickCheck. Given the importance of text in the ecosystem, this is something worth looking into. (I'm doing so now, but if you have some insights, that would be great.)

[hvr]

It's got to do with decodeUtf8With having an undocumented invariant/assumption (which sane code/usage shouldn't violate); but if that assumption doesn't hold you'd have to significantly over-allocate by a factor of 2 iirc.

[snoyberg]

So to confirm: there's a known, undocumented aspect of decodeUtf8With which can lead to segfault, and this behavior is triggered by the new QuickCheck library but not the older one?

[snoyberg]

I've opened up PR #212 as a workaround for this.