Build failure in v0.3.0 with GHC 7.10.3

[sjakobi]

dist/build/Data/ByteString/Lex/Lazy/Double.hs:339:17:
    Pattern bindings containing unlifted types should use an outermost bang pattern:
      ((I# (ord_c))) = ord c
    In the expression:
      let
        (base) = alexIndexInt32OffAddr alex_base s
        ((I# (ord_c))) = ord c
        (offset) = (base +# ord_c)
        ....
      in
        case new_s of {
          -1# -> (new_acc, input)
          _ -> alex_scan_tkn
                 user orig_input (len +# 1#) new_input new_s new_acc }
    In a case alternative:
        Just (c, new_input)
          -> let
               (base) = alexIndexInt32OffAddr alex_base s
               ((I# (ord_c))) = ord c
               ....
             in
               case new_s of {
                 -1# -> (new_acc, input)
                 _ -> alex_scan_tkn
                        user orig_input (len +# 1#) new_input new_s new_acc }
    In the second argument of ‘seq’, namely
      ‘case alexGetChar input of {
         Nothing -> (new_acc, input)
         Just (c, new_input)
           -> let
                (base) = ...
                ....
              in
                case new_s of {
                  -1# -> ...
                  _ -> alex_scan_tkn
                         user orig_input (len +# 1#) new_input new_s new_acc } }’

dist/build/Data/ByteString/Lex/Lazy/Double.hs:343:31:
    Couldn't match expected type ‘Bool’ with actual type ‘Int#’
    In the first argument of ‘(&&)’, namely ‘(offset >=# 0#)’
    In the expression: (offset >=# 0#) && (check ==# ord_c)
    In the expression:
      if (offset >=# 0#) && (check ==# ord_c) then
          alexIndexInt16OffAddr alex_table offset
      else
          alexIndexInt16OffAddr alex_deflt s

dist/build/Data/ByteString/Lex/Lazy/Double.hs:343:50:
    Couldn't match expected type ‘Bool’ with actual type ‘Int#’
    In the second argument of ‘(&&)’, namely ‘(check ==# ord_c)’
    In the expression: (offset >=# 0#) && (check ==# ord_c)
    In the expression:
      if (offset >=# 0#) && (check ==# ord_c) then
          alexIndexInt16OffAddr alex_table offset
      else
          alexIndexInt16OffAddr alex_deflt s
cabal: Failed to build bytestring-lexing-0.3.0

I encountered this error while building hedis-0.3.2, with the following build plan:

$ cabal install hedis-0.3.2 -w ghc-7.10.3
Resolving dependencies...
Build profile: -w ghc-7.10.3 -O1
In order, the following will be built (use -v for more details):
 - alex-3.1.4 (exe:alex) (requires download & build)
 - bytestring-0.9.2.1 (lib) (requires download & build)
 - stm-2.2.0.1 (lib:stm) (requires download & build)
 - transformers-base-0.4.2 (lib:transformers-base) (requires download & build)
 - unix-2.7.2.2 (lib:unix) (requires build)
 - bytestring-lexing-0.3.0 (lib:bytestring-lexing) (requires download & build)
 ...

For some reason this failure does not show up in the Hackage Matrix builder: https://matrix.hackage.haskell.org/#/package/bytestring-lexing

I assume the dependency configuration is somehow different there.

[wrengr]

Data.ByteString.Lex.Double was removed in version v0.5.

Taking a look at hedis, it looks like they've required bytestring-lexing>=0.5 since hedis-0.6.7; and hedis-0.6.7 should compile on GHC 7.6.3–8.2.2 (according to the version restrictions on base). Is there any particular reason you're needing to build such an old version of hedis?

[sjakobi]

Actually I simply noticed the dependency failure at https://matrix.hackage.haskell.org/#/package/hedis, and wondered what it was. It would be nice to fix of course, but it doesn't seem particularly likely that other people will encounter it in their builds.

[sjakobi]

I get similar errors with v0.3.0, v0.4.0, v0.4.2 and v0.4.3.

v0.4.3.1 seems to fix the issue by requiring alex >= 3.1.3 with GHC >= 7.8, and by removing Data/ByteString/Lex/Double.hs and Data/ByteString/Lex/Lazy/Double.hs: http://hdiff.luite.com/cgit/bytestring-lexing/diff?id=0.4.3.1&id2=0.4.3

Since Hackage revisions can't remove these files and also cannot add conditional constraints like the one used in v0.4.3.1, I guess the best that could be done is to constrain these versions to base < 4.7, i.e. GHC < 7.8. This may also remove some good build plans, such as those that were apparently used in the Hackage Matrix builds, but which I haven't been able to reproduce.

Please let me know if you would like these constraints to be added. Otherwise feel free to close the issue.

[wrengr]

Since hedis is the one failing rather than bytestring-lexing, wouldn't it make more sense to revise hedis rather than bytestring-lexing? It'd be a shame to cause bytestring-lexing 0.3.0–0.4.3.0 to fail on GHC 7.8–8.0 when it's currently succeeding... Or are these successes the ones you can't replicate? If so, I do still have GHC 7.10.1 and 8.0.2 installed, so I could try my hand at replicating it.

I don't know when/how the matrix runs are re-executed, but the bytestring-lexing metadata has been edited a number of times, so I wonder if that might be contributing to why bytestring-lexing succeeds on its own whereas fails in conjunction with hedis?

[sjakobi]

@wrengr It's bytestring-lexing that fails to build. That's why Hackage Matrix reports the status as FAIL (deps) and not FAIL (pkg). For example, I expect that you could reproduce the failure with

cabal install bytestring-lexing-0.4.0 -w ghc-8.0.2

[wrengr]

D'oh, of course! Yeah, I guess, go ahead and add the constraint

[sjakobi]

Actually I'm still too confused about the conditions under which the build fails to feel comfortable to make revisions in this case. We can revisit the issue if there's evidence that these build failures actually cause harm.