ekmett / bytes

Serialization primitives that work with both cereal and binary.
http://hackage.haskell.org/package/bytes
Other
22 stars 13 forks source link

bytesting-0.11 breaks on older GHCs. #52

Closed phadej closed 3 years ago

phadej commented 3 years ago
% cabal build -w ghc-7.10.3 --constraint='bytestring >=0.11' --allow-newer=bytestring
src/Data/Bytes/Serial.hs:291:3:
    Not in scope: data constructor ‘PS’
    Perhaps you meant ‘BS’ (imported from Data.ByteString.Internal)

with

source-repository-package
  type: git
  location: https://github.com/haskell/text
  tag: v1.2.4.1-rc1

CI doesn't test these. They are however easy to spot if you grep for PS constructor.

phadej commented 3 years ago

(an easy solution is to allow bytestring-0.11 only with GHC-8.0+, which support PatternSynonyms).

phadej commented 3 years ago

FWIW, I could build acme-kmett with GHC-7.10.3 and bytestring-0.11, if you want to see what fails without going through packages one by one.

RyanGlScott commented 3 years ago

Oops! Good catch. Would using CPP like this be sufficient to fix this issue in a backwards-compatible manner?

FWIW, I could build acme-kmett with GHC-7.10.3 and bytestring-0.11, if you want to see what fails without going through packages one by one.

I don't think there's a need to do all that. If I understand correctly, the only conditional API that we'd have to watch out for in bytestring is the use of the PS data constructor, right?

phadej commented 3 years ago

Re lens patch, yes.

Re, breakage, yeah. There is also removed modules, but those you should notice with any GHC (though again, none GHC on ci uses bytestring-0.11)

RyanGlScott commented 3 years ago

OK. In that case, I checked all of the code that I maintain, and I was fortunate in that bytes is the only PS-using library that I accidentally broke. I'll revert the Hackage revision I made for bytes-0.17 to allow bytestring-0.11 and submit a proper PR to add bytestring-0.11 support momentarily.