New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"derive makeArbitrary" error w/ strict types (8.0.1) #17
Comments
Works for me using Derive 2.5.25 and the test case below. Can you check with that test case and Derive version, and we can see where things differ. {-# LANGUAGE TemplateHaskell, DeriveDataTypeable, DeriveGeneric, StandaloneDeriving #-}
module Example where
import Data.Text
import Data.Data
import GHC.Generics
import Data.Time.Clock
import Data.Derive.Arbitrary
import Test.QuickCheck
import Data.DeriveTH
import System.IO.Unsafe
data NoteListItem = NoteListItem {
noteListItemId :: !Text
, noteListItemHash :: !Text
, noteListItemTitle :: !Text
, noteListItemLength :: !Int
, noteListItemCreatedAt :: !UTCTime
, noteListItemUpdatedAt :: !UTCTime
} deriving (Show, Eq, Data, Typeable, Generic, Ord)
instance Arbitrary Text where
arbitrary = return mempty
instance Arbitrary UTCTime where
arbitrary = return $ unsafePerformIO getCurrentTime
$(derive makeArbitrary ''NoteListItem)
main = print =<< generate (arbitrary :: Gen NoteListItem) |
The test case you posted above works fine - no issues. I've created a minimal repo that reproduces the failing behavior for me here: https://github.com/jonschoning/derive-issue-17 *note - not a serious issue for me, but just curious if I'm using the library correctly or am misunderstanding something more basic about how ghc works. |
another side note - what I don't quite understand is where it is getting I would think it should interpret all the fields as
|
Thanks for the awesome test case - I've got a fix, just doing a buildbot test and then I'll release it. I suspect the constructors are either strict, lazy or default. Within a module they are default, but once they leave a module they get given explicit values. |
oh ok.. thank you! I will read up on this behavior |
That behaviour is a complete guess - but it seems to fit with what we're seeing. I expect the two different modules is important. |
Fixed in 2.5.26. Thanks for the awesome test case! |
The text was updated successfully, but these errors were encountered: