December 2016 - ghc-tickets

[GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4
by GHC 20 Oct '17

20 Oct '17

#12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, git clone (commit dfe55e97ed86567aafca2e5f3c19096e2a4cb50f - Sep 20th 2016) of commercialhaskell.com from github: {{{ https://github.com/commercialhaskell/commercialhaskell.com.git }}} follow instructions from that repo exactly for os x (stacksetup installed ghc-7.10.2, but i have seen similar issue with 8): {{{ $ brew install icu4c Add the following to your ~/.stack/stack.yaml: extra-include-dirs: - /usr/local/opt/icu4c/include extra-lib-dirs: - /usr/local/opt/icu4c/lib Now: $ stack build }}} Hit one minor issue in build process with icu4c, resolving with following stack build: {{{ stack build --extra-lib-dirs=/usr/local/opt/icu4c/lib --extra-include- dirs=/usr/local/opt/icu4c/include }}} reach build of yesod-auth, with a failure: {{{ yesod-auth-1.4.6: configure yesod-auth-1.4.6: build texmath-0.8.2.2: copy/register Progress: 35/38 -- While building package yesod-auth-1.4.6 using: /Users/stephen/.stack/setup-exe-cache/x86_64-osx/setup-Simple- Cabal-1.22.4.0-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.4.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /Users/stephen/Documents/github/commercialhaskell.com/.stack-work/logs /yesod-auth-1.4.6.log Configuring yesod-auth-1.4.6... Building yesod-auth-1.4.6... Preprocessing library yesod-auth-1.4.6... [ 1 of 11] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/PasswordStore.o ) /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 11] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth/Message.o ) /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/Auth/Message.hs:22:1: Warning: The import of ‘Data.Monoid’ is redundant except perhaps to import instances from ‘Data.Monoid’ To import instances alone, use: import Data.Monoid() [ 3 of 11] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth/Routes.o ) [ 4 of 11] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib: malformed mach-o: load commands size (34176) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So reporting.... I've seen the same error attempting to brew install haskell-stack on sierra betas 3 and 4, but on those occasions, an issue with libghc_44.dylib causing the problem. {{{ [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-558713ad/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc67839_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc67839_0/libghc_44.dylib: malformed mach-o: load commands size (40560) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} stack version: {{{ Version 1.1.2, Git revision cebe10e845fed4420b6224d97dcabf20477bbd4b (3646 commits) x86_64 hpack-0.14.0 }}} stack exec env returns: {{{ stack exec env Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.tEAdTiAWFI/Render GHC_PACKAGE_PATH=/Users/stephen/Documents/github/commercialhaskell.com /.stack- work/install/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/programs/x86_64-osx/ghc-7.10.2/lib/ghc-7.10.2/package.conf.d HASKELL_DIST_DIR=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0 HASKELL_PACKAGE_SANDBOX=/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb HASKELL_PACKAGE_SANDBOXES=/Users/stephen/Documents/github/commercialhaskell… /.stack- work/install/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb: HOME=/Users/stephen LANG=en_IE.UTF-8 LOGNAME=stephen NAME=Stephen Barrett OLDPWD=/Users/stephen/Documents/github PATH=/Users/stephen/Documents/github/commercialhaskell.com/.stack- work/install/x86_64-osx/lts-3.0/7.10.2/bin:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/bin:/Users/stephen/.stack/programs/x86_64-osx/ghc-7.10.2/bin:/Users/stephen/Library/Haskell/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin PWD=/Users/stephen/Documents/github/commercialhaskell.com SECURITYSESSIONID=186a6 SHELL=/bin/bash SHLVL=1 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.RTM6V8Lo2y/Listeners STACK_EXE=/Library/Haskell/ghc-8.0.1-x86_64/bin/stack TERM=xterm-256color TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=377 TERM_SESSION_ID=020844C9-1E8A-410E-8892-43DC0C5A8C0B TMPDIR=/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ USER=stephen XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 _=/usr/local/bin/stack __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x6C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible
by GHC 19 Oct '17

19 Oct '17

#11469: GHCi should get LANGUAGE extensions/defaulting from the module whose full top-level scope is visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.11 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: -------------------------------------+------------------------------------- While helping a Haskell beginner today, we came across this behavior and I wondered why there wasn't already a ticket for this problem in the tracker. In fact, this is technically a duplicate of #3217, but that ticket is long (and it was difficult to find!) so I just want to file a new ticket to summarize what needs to be done. The essential problem is that a user is editing a file that looks like this: {{{ {-# LANGUAGE OverloadedStrings #-} module A where ... some code ... }}} and they load this into ghci with `ghci A.hs`. They then might reasonably type a string into the GHCi prompt and expect it to be overloaded... but it will not be! They had to have invoked GHCi with `ghci -XOverloadedStrings A.hs`. This behavior is unexpected and not very nice. The proposal is this: (from https://ghc.haskell.org/trac/ghc/ticket/3217#comment:15) GHCi should be changed so that at most one module is "fully open", currently denoted *M in GHCi's prompt. If a module M is "fully open", expressions typed at the GHCi prompt are interpreted (roughly) as if they were written in M itself. Specifically: * All the top-level things in the module are in scope * The per-module flags in {-# OPTIONS #-} and {-# LANGUAGE #-} pragmas * M's default declaration holds Note that currently more than one module can be fully open, and their top level scopes are merged. We propose to make that at most one. When compiling an expression typed on the GHCi command line: * Start with the baseline DynFlags * Apply flags specified on the original command-line * (Perhaps: apply flags specified by :set in this GHCi session. We aren't sure whether or not to do this.) * Apply GHCi baseline command-prompt flags (e.g. special defaulting rules) * Apply flags specified by :seti in this GHCi session * If there is a fully-open module M, apply flags specified in M itself. That is, flags in M get the last word. Implementing this plan will require some representation changes. In particular, since we need to apply M's source-code flags in two difference places, we really need to remember the diffs with M, perhaps as a `(DynFlags -> DynFlags)` function or something. See also: https://ghc.haskell.org/trac/ghc/ticket/3217#comment:28 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11343: Unable to infer type when using DuplicateRecordFields
by GHC 18 Oct '17

18 Oct '17

#11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- It seems to me that GHC should be able to easily infer the types for the record updates in this simple example. Is there a reason that it is unable to infer the type currently? {{{ {-# LANGUAGE OverloadedLabels, DuplicateRecordFields #-} module C where main = do print aThing print bThing print (aThing { a = 5 } ) print (bThing { a = 5 } ) data B = B { a :: Int} deriving Show bThing = B 10 data A = A { a :: Int } deriving Show aThing = A 10 {- [1 of 1] Compiling C ( C.hs, C.o ) C.hs:7:10: error: • Record update is ambiguous, and requires a type signature • In the first argument of ‘print’, namely ‘(aThing {a = 5})’ In a stmt of a 'do' block: print (aThing {a = 5}) In the expression: do { print aThing; print bThing; print (aThing {a = 5}); print (bThing {a = 5}) } -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11343> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9112: data families with representational matching
by GHC 17 Oct '17

17 Oct '17

#9112: data families with representational matching ------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Since ghc-7.8, the following is no longer possible: {{{ -- simplified example taken from the vector package class MVectorClass (v :: * -> * -> *) a where basicLength :: v s a -> Int data family MVector s a data instance MVector s Int -- implementation not important newtype Age = Age Int deriving (MVectorClass MVector) -- rejected }}} Following from discussion in #8177, to enable this ghc would need to support data families with representational matching, such that `MVector s Int` and `MVector s Age` are representationally equal. This has broken some code that previously worked, however as there are some workarounds I'm not sure how important it is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth
by GHC 17 Oct '17

17 Oct '17

#10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The problem observed on GHC's code base when explored why exactly some object files are so huge. Let's look at the stats of text code section sizes on today's HEAD (skipping GHCi libraries and stage1 binaries): {{{ ~/dev/git/ghc $ size `find -name *.o -type f | grep -v stage1 | grep -v HS` | sort -k1 -n -r | head -n20 text data bss dec hex filename 1791068 145448 0 1936516 1d8c84 ./compiler/stage2/build/DynFlags.o 1558637 77464 0 1636101 18f705 ./compiler/stage2/build/PprC.o 1397966 23272 0 1421238 15afb6 ./compiler/stage2/build/PlatformConstants.o 1332048 373344 0 1705392 1a05b0 ./libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription.o 1331238 373352 0 1704590 1a028e ./bootstrapping/Distribution/PackageDescription.o 1271578 246240 0 1517818 1728fa ./libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o 1229696 311616 0 1541312 1784c0 ./libraries/Cabal/Cabal/dist- install/build/Distribution/PackageDescription.o 1215082 224288 0 1439370 15f68a ./libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.o 1071746 242664 0 1314410 140e6a ./compiler/stage2/build/HsExpr.o 1015090 40904 0 1055994 101cfa ./compiler/stage2/build/Llvm/PpLlvm.o 970203 124944 0 1095147 10b5eb ./compiler/stage2/build/Parser.o 849693 79760 0 929453 e2ead ./compiler/stage2/build/HsDecls.o 833327 35440 0 868767 d419f ./compiler/stage2/build/X86/CodeGen.o 819959 127192 0 947151 e73cf ./libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Setup.o 819685 125120 0 944805 e6aa5 ./bootstrapping/Distribution/Simple/Setup.o 816927 124520 0 941447 e5d87 ./libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.o 785398 41536 0 826934 c9e36 ./compiler/stage2/build/CoreLint.o 772550 42040 0 814590 c6dfe ./compiler/stage2/build/DriverPipeline.o 766461 36280 0 802741 c3fb5 ./compiler/stage2/build/HscMain.o 735605 23408 0 759013 b94e5 ./libraries/containers/dist- install/build/Data/Sequence.o }}} '''PlatformConstants.o''' is a very clear example of this problem. Trimmed down example of this file is: {{{#!hs module M (D) where data D = D { a0 , a01 , a02 , a03 , a04 , a05 , a06 , a07 , a08 , a09 , a10 , a11 , a12 , a13 , a14 , a15 , a16 , a17 , a18 , a19 , a20 , a21 , a22 , a23 , a24 , a25 , a26 , a27 , a28 , a29 , a30 , a31 , a32 , a33 , a34 , a35 , a36 , a37 , a38 , a39 , a40 , a41 , a42 , a43 , a44 , a45 , a46 , a47 , a48 , a49 , a50 , a51 , a52 , a53 , a54 , a55 , a56 , a57 , a58 , a59 , a60 , a61 , a62 , a63 , a64 , a65 , a66 , a67 , a68 , a69 , a70 , a71 , a72 , a73 , a74 , a75 , a76 , a77 , a78 , a79 , a80 , a81 , a82 , a83 , a84 , a85 , a86 , a87 , a88 , a89 , a90 , a91 , a92 , a93 , a94 , a95 , a96 , a97 , a98 , a99 :: Int } deriving Read }}} Results in 800KB file: {{{ $ ghc-stage2 -c -O1 -fforce-recomp M.hs -o M.o $ size M.o text data bss dec hex filename 847039 16080 0 863119 d2b8f M.o }}} The size growth is quadratic: {{{ # fields code-size 1 6263 21 61767 41 173623 61 347503 81 583367 101 881231 121 1241087 141 1662959 161 2146815 181 2692679 201 3300543 221 3970407 241 4702263 261 5496135 281 6351991 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #11262: Test print022: wrong stdout on powerpc64
by GHC 16 Oct '17

16 Oct '17

#11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Incorrect result | at runtime Test Case: print022 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi prints a NUL(?) character instead of an 'x'. {{{ () -test = C 1 32 1.2 1.23 'x' 1 1.2 1.23 +test = C 1 32 1.2 1.23 '/NUL' 1 1.2 1.23 Breakpoint 0 activated at print022.hs:11:1-7 Stopped at print022.hs:11:1-7 _result :: r = _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9274: GHC panic with UnliftedFFITypes+CApiFFI
by GHC 16 Oct '17

16 Oct '17

#9274: GHC panic with UnliftedFFITypes+CApiFFI -----------------------------------+--------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The following code fails to compile with at least GHC 7.6, 7.8 and HEAD: {{{#!hs import GHC.Prim import Foreign.C type GmpLimb = CULong type GmpSize = CLong -- mp_limb_t mpn_add_1 (mp_limb_t *rp, const mp_limb_t *s1p, mp_size_t n, mp_limb_t s2limb) foreign import capi unsafe "gmp.h mpn_add_1" c_mpn_add_1 :: MutableByteArray# s -> ByteArray# -> GmpSize -> GmpLimb -> IO GmpLimb }}} with the following compile error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.9.20140704 for x86_64-unknown-linux): toCType MutableByteArray# s Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Otoh, replacing `capi` with `ccall` makes the code compile just fine -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12822: Cleanup GHC verbosity flags
by GHC 14 Oct '17

14 Oct '17

#12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple newcomer,flags | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1) In the discussion of Phab:D2679#77898, Simon Marlow suggested that we make verbosity levels (`-v0`, `-v1`...) work just like optimization levels (`-O0`, `-O1`...), i.e., that we make each verbosity level a collection of verbosity flags. Currently the verbosity level is tested against explicitly in several places in GHC's code. 2) Homogenize verbosity flags: currently, flags that change GHC's reporting have various prefixes: - `-fprint-*` - `-fshow-*` - `-dshow-passes` - `-ddump-*` - `-dppr-*` - `-dverbose-*` Maybe we should homogenize (some of) them by using a common `-v` prefix as in `-vshow-source-paths`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11654: User Guide: Generate command line options table from ghc-flags directives
by GHC 11 Oct '17

11 Oct '17

#11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.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: -------------------------------------+------------------------------------- Since the move to ReStructuredText and Sphinx we've generated the options summary tables and manpage with `utils/mkUserGuidePart`. The options are described in a set of Haskell modules which are a pain to edit and may easily fall out of date. It would be far better if we could generate these tables from the `.. ghc- flags` directives already present in the users guide. This will involve a bit of hacking with Sphinx, although it should be more than up to the task. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #10816: Fixity declaration for associated type rejected
by GHC 11 Oct '17

11 Oct '17

#10816: Fixity declaration for associated type rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE TypeOperators, TypeFamilies #-} module Bug where class C a where type a # b infix 4 # }}} I get {{{ Bug.hs:7:11: ‘#’ is not a (visible) method of class ‘C’ }}} But it really should just assign a fixity to the type `#`. It works if the fixity declaration is outside of the class. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3