December 2018 - ghc-tickets

[GHC] #15608: Segfault in retainer profiling
by GHC 11 Dec '18

11 Dec '18

#15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce, build ghc using "prof" flavor, then {{{ $ ghc-stage2 --interactive +RTS -hr GHCi, version 8.7.20180905: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> sequence_ (replicate 100000000 (return ())) zsh: segmentation fault (core dumped) ghc-stage2 --interactive +RTS -hr }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15444: 8.4.3 has an undocumented dependency on libnuma.
by GHC 11 Dec '18

11 Dec '18

#15444: 8.4.3 has an undocumented dependency on libnuma. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See also https://github.com/haskell/network/issues/328 for some discussion. The issue seems to be that the rts "package" depends on libnuma. See below for build log and rts package info. {{{ The Glorious Glasgow Haskell Compilation System, version 8.4.3 cabal-install version 2.2.0.0 compiled using version 2.2.0.0 of the Cabal library - network-2.6.3.5 (lib:network) (requires build) }}} {{{ checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking linux/can.h usability... yes checking linux/can.h presence... yes checking for linux/can.h... yes checking linux/tcp.h usability... yes checking linux/tcp.h presence... yes checking for linux/tcp.h... yes checking net/if.h usability... yes checking net/if.h presence... yes checking for net/if.h... yes checking for readlink... yes checking for symlink... yes checking for if_nametoindex... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for getpeereid in unistd.h... checking for getpeereid... no checking for _head_libws2_32_a in -lws2_32... no checking for getaddrinfo... yes checking for gai_strerror... yes checking whether AI_ADDRCONFIG is declared... yes checking whether AI_ALL is declared... yes checking whether AI_NUMERICSERV is declared... yes checking whether AI_V4MAPPED is declared... yes checking whether IPV6_V6ONLY is declared... yes checking whether IPPROTO_IP is declared... yes checking whether IPPROTO_TCP is declared... yes checking whether IPPROTO_IPV6 is declared... yes checking for sendfile in sys/sendfile.h... yes checking for sendfile in sys/socket.h... no checking for gethostent... yes checking for accept4... yes configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h configure: WARNING: unrecognized options: --with-compiler Preprocessing library for network-2.6.3.5.. /usr/bin/ld.gold: error: cannot find -lnuma collect2: error: ld returned 1 exit status linking dist/build/Network/BSD_hsc_make.o failed (exit code 1) command was: /usr/bin/gcc dist/build/Network/BSD_hsc_make.o dist/build/Network/BSD_hsc_utils.o -o dist/build/Network/BSD_hsc_make -fuse-ld=gold -fno-stack-protector -fuse-ld=gold -L/usr/local/lib/ghc-8.4.3/unix-2.7.2.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/unix-2.7.2.2 -lrt -lutil -ldl -lpthread -L/usr/local/lib/ghc-8.4.3/time-1.8.0.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/time-1.8.0.2 -L/usr/local/lib/ghc-8.4.3/bytestring-0.10.8.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/bytestring-0.10.8.2 -L/usr/local/lib/ghc-8.4.3/deepseq-1.4.3.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/deepseq-1.4.3.0 -L/usr/local/lib/ghc-8.4.3/array-0.5.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/array-0.5.2.0 -L/usr/local/lib/ghc-8.4.3/base-4.11.1.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/base-4.11.1.0 -L/usr/local/lib/ghc-8.4.3 /integer-gmp-1.0.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/integer-gmp-1.0.2.0 -lgmp -L/usr/local/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -L/usr/local/lib/ghc-8.4.3/rts -Wl,-R,/usr/local/lib/ghc-8.4.3/rts -lm -lrt -ldl -lnuma -lpthread cabal: Failed to build exe:hsc2hs from hsc2hs-0.68.3 (which is required by cabal-install-2.2.0.0). See the build log above for details. Failed to build network-2.6.3.5 (which is required by cabal- install-2.2.0.0). See the build log above for details. }}} {{{ name: rts version: 1.0 id: rts key: rts license: BSD-3-Clause maintainer: glasgow-haskell-users(a)haskell.org exposed: True library-dirs: /usr/local/lib/ghc-8.4.3/rts hs-libraries: HSrts Cffi extra-libraries: m rt dl numa pthread include-dirs: /usr/local/lib/ghc-8.4.3/include includes: Stg.h ld-options: "-Wl,-u,base_GHCziTopHandler_runIO_closure" "-Wl,-u,base_GHCziTopHandler_runNonIO_closure" "-Wl,-u,ghczmprim_GHCziTuple_Z0T_closure" "-Wl,-u,ghczmprim_GHCziTypes_True_closure" "-Wl,-u,ghczmprim_GHCziTypes_False_closure" "-Wl,-u,base_GHCziPack_unpackCString_closure" "-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure" "-Wl,-u,base_GHCziIOziException_stackOverflow_closure" "-Wl,-u,base_GHCziIOziException_heapOverflow_closure" "-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure" "-Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure" "-Wl,-u,base_ControlziExceptionziBase_nonTermination_closure" "-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure" "-Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure" "-Wl,-u,base_GHCziConcziSync_runSparks_closure" "-Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure" "-Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure" "-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure" "-Wl,-u,base_GHCziTopHandler_runMainIO_closure" "-Wl,-u,ghczmprim_GHCziTypes_Czh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Izh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info" "-Wl,-u,base_GHCziPtr_Ptr_con_info" "-Wl,-u,base_GHCziPtr_FunPtr_con_info" "-Wl,-u,base_GHCziInt_I8zh_con_info" "-Wl,-u,base_GHCziInt_I16zh_con_info" "-Wl,-u,base_GHCziInt_I32zh_con_info" "-Wl,-u,base_GHCziInt_I64zh_con_info" "-Wl,-u,base_GHCziWord_W8zh_con_info" "-Wl,-u,base_GHCziWord_W16zh_con_info" "-Wl,-u,base_GHCziWord_W32zh_con_info" "-Wl,-u,base_GHCziWord_W64zh_con_info" "-Wl,-u,base_GHCziStable_StablePtr_con_info" "-Wl,-u,hs_atomic_add8" "-Wl,-u,hs_atomic_add16" "-Wl,-u,hs_atomic_add32" "-Wl,-u,hs_atomic_add64" "-Wl,-u,hs_atomic_sub8" "-Wl,-u,hs_atomic_sub16" "-Wl,-u,hs_atomic_sub32" "-Wl,-u,hs_atomic_sub64" "-Wl,-u,hs_atomic_and8" "-Wl,-u,hs_atomic_and16" "-Wl,-u,hs_atomic_and32" "-Wl,-u,hs_atomic_and64" "-Wl,-u,hs_atomic_nand8" "-Wl,-u,hs_atomic_nand16" "-Wl,-u,hs_atomic_nand32" "-Wl,-u,hs_atomic_nand64" "-Wl,-u,hs_atomic_or8" "-Wl,-u,hs_atomic_or16" "-Wl,-u,hs_atomic_or32" "-Wl,-u,hs_atomic_or64" "-Wl,-u,hs_atomic_xor8" "-Wl,-u,hs_atomic_xor16" "-Wl,-u,hs_atomic_xor32" "-Wl,-u,hs_atomic_xor64" "-Wl,-u,hs_cmpxchg8" "-Wl,-u,hs_cmpxchg16" "-Wl,-u,hs_cmpxchg32" "-Wl,-u,hs_cmpxchg64" "-Wl,-u,hs_atomicread8" "-Wl,-u,hs_atomicread16" "-Wl,-u,hs_atomicread32" "-Wl,-u,hs_atomicread64" "-Wl,-u,hs_atomicwrite8" "-Wl,-u,hs_atomicwrite16" "-Wl,-u,hs_atomicwrite32" "-Wl,-u,hs_atomicwrite64" pkgroot: "/usr/local/lib/ghc-8.4.3" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows
by GHC 11 Dec '18

11 Dec '18

#16023: Can't bootstrap GHC HEAD with GHC 8.6 on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to bootstrap GHC HEAD with GHC 8.6 on Windows fails shortly after starting the build with {{{ ... Configuring hsc2hs-0.68.4.1... "inplace/bin/ghc-cabal.exe" configure utils/gen-dll dist --with- ghc="/home/ben/ghc-8.6.3-amd64/bin/ghc.exe" --with-ghc- pkg="/home/ben/ghc-8.6.3-amd64/bin/ghc-pkg" --packag e-db=C:/msys64/home/ben/ghc/libraries/bootstrapping.conf --disable- library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-optio n=CFLAGS="-Wall -fno-stack-protector -Wno-error=inline" --configure- option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -W no-error=inline " --constraint "binary == 0.8.6.0" --constraint "text == 1.2.3.1" --constraint "transformers == 0.5.5.0" --constraint "mtl == 2.2.2" --constrain t "parsec == 3.1.13.0" --constraint "Cabal == 2.5.0.0" --constraint "hpc == 0.6.0.3" --constraint "ghc-boot-th == 8.7" --constraint "ghc- boot == 8.7" --constraint "template-haskell == 2.15.0.0" --constraint "ghc-heap == 8.7" --constraint "ghci == 8.7" --with- gcc="C:\\msys64\\home\\ben\\ghc-8.6.3-amd64\\lib\\../mingw/bin/gcc.exe" --with- ld="C:\\msys64\\home\\ben\\ghc-8.6.3-amd64\\lib\\../mingw/bin/ld.exe" --with- ar="C:\\msys64\\home\\ben\\ghc-8.6.3-amd64\\lib\\../mingw/bin/ar.exe" --with-alex="\Use rs\ben\AppData\Roaming/cabal/bin/alex" --with- happy="\Users\ben\AppData\Roaming/cabal/bin/happy" Configuring gen-dll-0.1... ghc-cabal.exe: Encountered missing dependencies: containers ==0.5.* make[1]: *** [utils/gen-dll/ghc.mk:19: utils/gen-dll/dist/package-data.mk] Error 1 make: *** [Makefile:124: all] Error 2 }}} Given that the build succeeds when bootstrapping with GHC 8.4, I suspect that this is a regression in the Cabal released with 8.6. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] Batch modify: #15876, #15878, #15608, #15992, #15995, #15997, ...
by GHC 11 Dec '18

11 Dec '18

Batch modification to #15876, #15878, #15608, #15992, #15995, #15997, #16027, #15998, #16000, #15978, #15977, #15967, #15996, #15897, #15914, #15915, #15917, #16004, #15882, #15940, #15907, #15932, #15905, #15921, #15944, #15883, #15885, #15888, #15880, #15889, #15923, #15924, #15933, #15936, #15895, #16029, #15891, #15444, #14613, #15928, #15946, #15909, #15929, #15958, #15957, #15982, #15973, #15983, #15984, #15913, #15912, #15918, #15927, #15960, #15947, #15942, #15945, #15989, #15966, #15956, #15988, #15991, #15959, #16011, #16012, #16013, #15993, #16015, #16017, #16021, #16020, #16014, #15952, #16023 by bgamari: milestone to None Comment: Ticket retargeted after milestone closed -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=15876%2C15878%2C15608%2C15992%2C15…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16008: GHC HEAD type family regression involving invisible arguments
by GHC 11 Dec '18

11 Dec '18

#16008: GHC HEAD type family regression involving invisible arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles on GHC 8.0.2 through 8.6.2: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C k where type S :: k -> Type data D :: Type -> Type data SD :: forall a. D a -> Type instance C (D a) where type S = SD }}} But fails to compile on GHC HEAD (commit 73cce63f33ee80f5095085141df9313ac70d1cfa): {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:3: error: • Type indexes must match class instance head Expected: S @(D a) Actual: S @(D a1) • In the type instance declaration for ‘S’ In the instance declaration for ‘C (D a)’ | 15 | type S = SD | ^^^^^^^^^^^ }}} This regression prevents [https://cs.brynmawr.edu/~rae/papers/2018/stitch/stitch.tar.gz the stitch library] from compiling. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3379: GHC should use the standard binary package
by GHC 10 Dec '18

10 Dec '18

#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * cc: ulysses4ever (added) Comment: I've been thinking about this one lately. For the sake of experiment, I tried to replace the implementation of a hand-crafted Binary instance (namely, the one for `ArgType`) with the implementation derived by Data.Binary via GHC.Generics. This alone immediately led GHC into panic (see below). [https://gitlab.staging.haskell.org/ulysses4ever/ghc/commit/6156a260cd775a1d… The patch is here]. Maybe my new instance has some flaw? Can anyone comment on any of these? {{{ $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -Wall -hide-all-packages -i -iutils/ghctags/. -iutils/ghctags/dist-install/build -Iutils/ghctags/dist-install/build -iutils/ghctags/dist-install/build/ghctags/autogen -Iutils/ghctags/dist- install/build/ghctags/autogen -optP-include -optPutils/ghctags/dist- install/build/ghctags/autogen/cabal_macros.h -package-id Cabal-2.5.0.0 -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id ghc-8.7 -XHaskell2010 -no-user-package-db -rtsopts -Wnoncanonical- monad-instances -odir utils/ghctags/dist-install/build -hidir utils/ghctags/dist-install/build -stubdir utils/ghctags/dist-install/build -c utils/ghctags/./Main.hs -o utils/ghctags/dist-install/build/Main.dyn_o ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181207 for x86_64-unknown-linux): Binary(IfaceConDecls).get: Invalid IfaceConDecls CallStack (from HasCallStack): error, called at compiler/iface/IfaceSyn.hs:1896:18 in ghc:IfaceSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug utils/ghctags/ghc.mk:18: recipe for target 'utils/ghctags/dist- install/build/Main.dyn_o' failed make[1]: *** [utils/ghctags/dist-install/build/Main.dyn_o] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do
by GHC 10 Dec '18

10 Dec '18

#9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. A long-standing wart which needs some careful attention. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

Re: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust
by GHC 10 Dec '18

10 Dec '18

#4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.12.2 Resolution: duplicate | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate * related: => #9718 Comment: Duplicate of #9718. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4121#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16024: Kind Signatures on data instances
by GHC 10 Dec '18

10 Dec '18

#16024: Kind Signatures on data instances -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's a comment in `compiler/typecheck/TcInstDcls.hs` that reads: > The "header" is the part other than the data constructors themselves > e.g. `data instance D [a] :: * -> * = ...` > Here the "header" is the bit before the "=" sign What's weird is that you cannot actually compile code that this example suggests is valid. Consider this: {{{ {-# language TypeFamilies #-} module BadSig where data family Bar a :: * data instance Bar Int :: * = Bool }}} It fails on GHC 8.6.2 with: {{{ bad_sig.hs:6:28: error: parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' | 6 | data instance Bar Int :: * = Bool | ^ }}} Oddly, GHC will accept the instance if the body is missing: {{{ {-# language TypeFamilies #-} module BadSig where data family Bar a :: * data instance Bar Int :: * }}} It is not clear to me whether or not this one should be accepted, but that is beside the point. The first example should certainly be accepted. It should also be accepted with `TYPE 'LiftedRep` instead of `*`, but it fails with the same parser error when given that kind signature as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16022: Hadrian appears to link against libffi unconditionally
by GHC 10 Dec '18

10 Dec '18

#16022: Hadrian appears to link against libffi unconditionally -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hadrian appears to be linking against `libffi`, even on platforms where it should not be used. I suspect the cause is that Hadrian makes no attempt to set the `ffi` flag when configuring `rts`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4