June 2015 - ghc-tickets

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 26 Jun '15

26 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): Indeed. I for one think it should be changed to use an empty case. This ticket might not be the right place to discuss it though, since in any case standalone deriving and ordinary deriving should not produce two different instances. I only skimmed over the patch on Phab, but I assume the same code is used to actually generate the instances in those two cases, right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 26 Jun '15

26 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by osa1): So what do you think about current StandaloneDeriving implementation? It's already doing what you're complaining. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10574: «the 'impossible' happened» when compiling singletons
by GHC 26 Jun '15

26 Jun '15

#10574: «the 'impossible' happened» when compiling singletons -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When building the «singletons» package (v1.1.2.1 from hackage) in a fresh sandbox, GHC panics. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10550: Drop truncated package name prefix from package keys
by GHC 26 Jun '15

26 Jun '15

#10550: Drop truncated package name prefix from package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Package | Version: 7.11 system | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Early on when we moved to package keys, we decided it would be useful for documentation purposes to have a package key be something like `ghcpr_8TmvWUcS1U1IKHT0levwg3` rather than just `8TmvWUcS1U1IKHT0levwg3`, which would leave a user with no idea what the key is. I now think that this is more trouble than its worth: 1. We have fixed library *paths* so that the full package name, version, key is in the path, e.g. libraries are installed to `/home/ezyang/Dev/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3` instead of `/home/ezyang/Dev/ghc-7.10.1/usr/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3`. This means that the biggest case where users might care about package keys is no longer relevant; a user will always be able to get the real package key. 2. The other case where package keys show up is in symbol names. However, symbol names already contain *modules names*, so today we have `procezu0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` but `0hwN3CTKynhHQqQkChnSdH_SystemziProcess_rawSystem1_info` seems just about as clear (in particular, five letters just doesn't seem like enough to adequately describe long package names.) 3. Now, the reason why we don't want to truncate the prefix name is because it makes it more difficult to reliably, deterministically generate a package key based on a few parameters about a package: namely, any algorithm needs to know that `take 5 (filter (/= '-') packageName)` and prefix that onto the key. Really, we only care about the hash, but for most equality tests the prefix matters too! So it would be much nicer if we didn't have to care about the hash as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10550> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8144: Interface hashes include time stamp of included .h file when CPP is used
by GHC 25 Jun '15

25 Jun '15

#8144: Interface hashes include time stamp of included .h file when CPP is used -------------------------+------------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- See https://github.com/nh2/ghc-bug-time-dependent-interface-hashes for a fast test case. Having '''Test.hs''': {{{ {-# LANGUAGE CPP #-} module Test () where }}} and an empty '''cabal_macros.h''', {{{ touch cabal_macros.h ghc -c Test.hs -optP-include -optPcabal_macros.h }}} will generate you a different interface hash ''most of the time'' in '''ghc --show-iface Test.hi'''. It looks like the modification time of the .h file makes it into the interface hash, but only at second resolution, and you get ''compilation IS NOT required'' if you manage to run it twice per second. I think the interface hash should be independent from the time stamp of the header file. This bug can trigger unnecessary recompilation and makes compilations with identical inputs non-deterministic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

Re: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so.
by GHC 25 Jun '15

25 Jun '15

#7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, Operating System: Unknown/Multiple | newcomer Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D978 -------------------------------------+------------------------------------- Comment (by rwbarton): I agree with jpbernardy that generating an empty case on (or equivalently forcing) the first argument would be more correct than producing a new error. However, it seems that in this case the "blame" could be assigned to jpbernardy, who wrote the original report with `instance Eq D where (==) = undefined` :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10552: round on negative fractionals causes a segfault
by GHC 25 Jun '15

25 Jun '15

#10552: round on negative fractionals causes a segfault -----------------------------------+---------------------------------- Reporter: mmirman | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- "round (-1.5)" causes a segfault. Causes a runtime crash as well as a ghci crash. OS X 10.6.8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10559: the 'impossible' happened while building stack
by GHC 25 Jun '15

25 Jun '15

#10559: the 'impossible' happened while building stack -------------------------------------+------------------------------------- Reporter: barnaby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I ran stack update; stack install stack:latest It errored out and told me to mail you .. .... stack-0.0.3: build Completed all 122 actions. -- While building package stack-0.0.3 using: /Users/test/.stack/programs/x86_64-osx/ghc-7.10.1/bin/runhaskell -package=Cabal-1.22.2.0 -clear-package-db -global-package-db -package- db=/Users/test/.stack/snapshots/x86_64-osx/nightly-2015-06-21/7.10.1/pkgdb/ /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/stack14231/stack-0.0.3/Setup.hs --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.2.0/ build Process exited with code: ExitFailure 1 Logs have been written to: "/private/var/tmp/haskell/Moodler/Moodler /.stack-work/logs/stack-0.0.3.log" Configuring stack-0.0.3... Building stack-0.0.3... Preprocessing library stack-0.0.3... [ 1 of 53] Compiling Data.Set.Monad ( src/Data/Set/Monad.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Set/Monad.o ) [ 2 of 53] Compiling Network.HTTP.Download.Verified ( src/Network/HTTP/Download/Verified.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Network/HTTP/Download/Verified.o ) [ 3 of 53] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Log.o ) [ 4 of 53] Compiling Data.Attoparsec.Combinators ( src/Data/Attoparsec/Combinators.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Attoparsec/Combinators.o ) [ 5 of 53] Compiling Data.Maybe.Extra ( src/Data/Maybe/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Maybe/Extra.o ) [ 6 of 53] Compiling Stack.New ( src/Stack/New.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/New.o ) [ 7 of 53] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/PagerEditor.o ) [ 8 of 53] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Read.o ) [ 9 of 53] Compiling System.Process.Run ( src/System/Process/Run.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/System/Process/Run.o ) [10 of 53] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Paths_stack.o ) [11 of 53] Compiling Path.IO ( src/Path/IO.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Path/IO.o ) [12 of 53] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Path/Find.o ) [13 of 53] Compiling Data.Aeson.Extended ( src/Data/Aeson/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Aeson/Extended.o ) [14 of 53] Compiling Network.HTTP.Download ( src/Network/HTTP/Download.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Network/HTTP/Download.o ) [15 of 53] Compiling Stack.Types.PackageName ( src/Stack/Types/PackageName.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/PackageName.o ) [16 of 53] Compiling Stack.Types.Docker ( src/Stack/Types/Docker.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Docker.o ) [17 of 53] Compiling Stack.Types.FlagName ( src/Stack/Types/FlagName.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/FlagName.o ) [18 of 53] Compiling Stack.Types.Version ( src/Stack/Types/Version.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Version.o ) [19 of 53] Compiling Data.Binary.VersionTagged ( src/Data/Binary/VersionTagged.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Data/Binary/VersionTagged.o ) [20 of 53] Compiling Stack.Types.PackageIdentifier ( src/Stack/Types/PackageIdentifier.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/PackageIdentifier.o ) [21 of 53] Compiling Stack.Types.GhcPkgId ( src/Stack/Types/GhcPkgId.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/GhcPkgId.o ) [22 of 53] Compiling Stack.Types.BuildPlan ( src/Stack/Types/BuildPlan.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/BuildPlan.o ) [23 of 53] Compiling Stack.Types.Config ( src/Stack/Types/Config.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Config.o ) src/Stack/Types/Config.hs:12:1: Warning: The import of ‘<*>, pure, <$>’ from module ‘Control.Applicative’ is redundant [24 of 53] Compiling Stack.Constants ( src/Stack/Constants.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Constants.o ) [25 of 53] Compiling Stack.Types ( src/Stack/Types.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types.o ) [26 of 53] Compiling Stack.Package ( src/Stack/Package.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Package.o ) [27 of 53] Compiling Stack.Exec ( src/Stack/Exec.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Exec.o ) [28 of 53] Compiling Stack.Build.Types ( src/Stack/Build/Types.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Types.o ) [29 of 53] Compiling Stack.GhcPkg ( src/Stack/GhcPkg.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/GhcPkg.o ) [30 of 53] Compiling Stack.PackageDump ( src/Stack/PackageDump.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/PackageDump.o ) src/Stack/PackageDump.hs:316:22: Warning: In the use of ‘S.breakByte’ (imported from Data.ByteString): Deprecated: "It is an internal function and should never have been exported. Use 'break (== x)' instead. (There are rewrite rules that handle this special case of 'break'.)" [31 of 53] Compiling Stack.Path ( src/Stack/Path.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Path.o ) [32 of 53] Compiling Stack.Build.Cache ( src/Stack/Build/Cache.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Cache.o ) [33 of 53] Compiling Control.Concurrent.Execute ( src/Control/Concurrent/Execute.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Control/Concurrent/Execute.o ) [34 of 53] Compiling Stack.Build.Doc ( src/Stack/Build/Doc.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Build/Doc.o ) [35 of 53] Compiling Stack.Upload ( src/Stack/Upload.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Upload.o ) src/Stack/Upload.hs:29:1: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() [36 of 53] Compiling Stack.Docker.GlobalDB ( src/Stack/Docker/GlobalDB.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Docker/GlobalDB.o ) [37 of 53] Compiling Stack.Types.Internal ( src/Stack/Types/Internal.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/Internal.o ) [38 of 53] Compiling Stack.Types.StackT ( src/Stack/Types/StackT.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/Types/StackT.o ) [39 of 53] Compiling Stack.PackageIndex ( src/Stack/PackageIndex.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.2.0/build/Stack/PackageIndex.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib, 5): Symbol not found: _stackzu7QSuU95iv0I3hQSByROmsn_SystemziProcessziLog_showProcessArgDebug_closure Referenced from: /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib Expected in: flat namespace in /var/folders/gj/0zl8brn57zsb78slcjmjywrw0000gn/T/ghc27479_0/libghc27479_197.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X
by GHC 25 Jun '15

25 Jun '15

#10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- joelteon encountered this issue in a rather complicated program, and we worked out the cause over IRC. Suppose that ghci needs to sequentially load three modules A, B and C, where B refers to symbols from A and C refers to symbols from both A and B. (For example modules B, C and another module D all contain Template Haskell that refers to the previous module(s).) The object code linker currently works like this: - Link the module `A.o` into a dylib `ghc_1.dylib` - Link the module `B.o` against `ghc_1.dylib` into a new dylib `ghc_2.dylib` - Link the module `C.o` against `ghc_2.dylib` into a new dylib `ghc_3.dylib` As a result, `ghc_2.dylib` ends up with a NEEDED (or whatever it's called in Mach-O) entry for `ghc_1.dylib`, and `ghc_3.dylib` ends up with a NEEDED entry for `ghc_2.dylib`. However, this apparently does not satisfy the OS X `dlopen` implementation, which complains about a missing symbol `_A_foo` referenced by `ghc_3.dylib` and which is defined in `ghc_1.dylib`. Apparently the dynamic loader only checks the direct dependencies when trying to resolve undefined symbols. (The Linux dynamic loader seems to be perfectly happy to use an indirect dependency to resolve an undefined symbol. But I found out that the linker [https://sourceware.org/bugzilla/show_bug.cgi?id=10238 gold] has the same sort of behavior as the OS X dynamic loader. I don't know whether there is any standard here, but it seems that we cannot rely on the Linux dynamic loader's behavior.) Presumably the fix is to keep track of all the previous temporary dylibs (rather than just one in `last_temp_so`) and link against all of them when building a new temporary dylib. I'm slightly worried about quadratic behavior here, but I think it's unlikely to be an issue in practice. I have a reproducer at http://lpaste.net/808723564239781888 (which I'll add to the test suite next) and oherrala ran the test on an OS X system with the following results: {{{ =====> Last(ghci) 1167 of 4480 [0, 0, 0] cd ./ghci/scripts && HC="/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history " "/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS <Last.script > Last.run.stdout 2> Last.run.stderr Actual stderr output differs from expected: --- /dev/null 2015-04-18 17:23:26.000000000 +0300 +++ ./ghci/scripts/Last.run.stderr 2015-04-18 17:23:34.000000000 +0300 @@ -0,0 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.11.20150418 for x86_64-apple-darwin): + Loading temp shared object failed: dlopen(/var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib, 5): Symbol not found: _LastA_a_closure + Referenced from: /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + Expected in: flat namespace + in /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + Actual stdout output differs from expected: --- ./ghci/scripts/Last.stdout 2015-04-18 16:26:55.000000000 +0300 +++ ./ghci/scripts/Last.run.stdout 2015-04-18 17:23:34.000000000 +0300 @@ -1,3 +1,2 @@ 3 4 -7 *** unexpected failure for Last(ghci) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #7650: can't use combining characters in identifiers
by GHC 24 Jun '15

24 Jun '15

#7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => unicode * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7650#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0