July 2016 - ghc-tickets

[GHC] #10506: SourceNotes are not applied to all identifiers
by GHC 19 Mar '18

19 Mar '18

#10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 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: | -------------------------------------+------------------------------------- Compiling {{{ module Foo where foo x = x + 1 bar y = foo y }}} with `-g` produces {{{ $ ghc -g -ddump-ticked test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) AbsBinds [a_avC] [$dNum_avD] {Exports: [foo <= foo_amB <>] Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:3:1-13>] foo_amB x_alA = src<test.hs:3:9-13> (+) src<test.hs:3:9> x_alA src<test.hs:3:13> 1} AbsBinds [a_avV] [$dNum_avW] {Exports: [bar <= bar_avN <>] Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:5:1-13>] bar_avN y_amz = src<test.hs:5:9-13> foo (src<test.hs:5:13> y_amz)} }}} Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`). I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source. Would it be reasonable to add a SourceNote to each occurrence of an identifier? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic
by GHC 19 Mar '18

19 Mar '18

#10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently in `base` we have * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule` * `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName. * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName` * `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name. * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too! This is madness! Five different representations for the same information in one package! Let's fix this by defining some shared data types, for * `Module` = `ModuleName` + package * `Entity` = `Module` + unqualified name There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway. Would anyone be willing to lead on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11382: Optimize Data.Char
by GHC 19 Mar '18

19 Mar '18

#11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many of the predicates in `Data.Char` do full Unicode category lookups which turns out to be quite expensive. Ideally we would handle some of the more common ASCII characters with cheaper tests before falling back to the full Unicode treatment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11260: Re-compilation tests fail on powerpc64
by GHC 19 Mar '18

19 Mar '18

#11260: Re-compilation tests fail on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- recomp011: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) [A.hsinc changed] Linking Main ... 4343 +Linking Main ... 4343 }}} recomp015: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1
by GHC 19 Mar '18

19 Mar '18

#11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- `TH_spliceE5_prof` looks like this: {{{ TH_spliceE5_prof:: $(RM) TH_spliceE5_prof*.o TH_spliceE5_prof*.hi TH_spliceE5_prof*.dyn_o TH_spliceE5_prof*.dyn_hi TH_spliceE5_prof '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) $(ghcThWayFlags) --make -v0 TH_spliceE5_prof.hs -c '$(TEST_HC)' $(TEST_HC_OPTS) $(HC_OPTS) --make -v0 TH_spliceE5_prof.hs -prof -auto-all -osuf .p.o -o $@ ./$@ }}} In 4905b83a2d448c65ccced385343d4e8124548a3b, Simon added that `$(ghcThWayFlags)` to the first compilation command. With a release compiler, `ghcThWayFlags` defaults to `-dynamic`. But compiling with `-dynamic` doesn't produce `.dyn_o` files (you need `-dynamic-too` for that, which is enabled by `-XTemplateHaskell`, but **not** when compiling with `-dynamic`), so the second compilation results in: {{{ TH_spliceE5_prof.hs:8:17: fatal: cannot find object file ‘./TH_spliceE5_prof_Lib.dyn_o’ while linking an interpreted expression make[1]: *** [TH_spliceE5_prof] Error 1 *** unexpected failure for TH_spliceE5_prof(normal) }}} Not passing `-dynamic` fixes the test. But in the function `failNonStd` in `compiler/ghci/Linker.hs` Simon suggests that passing `-dynamic`: {{{ Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interprter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. }}} Some ideas for a solution: * change that message to not mention `-dynamic` * always turn on `-dynamic-too` when `-XTemplateHaskell` is on, also when using `-dynamic` * find the place where `.dyn_o` is expected, and teach it that `.o` might also be ok. * make `-fexternal-interpreter` the default. Delete the test and a whole bunch of other stuff. It's all such a mess. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary
by GHC 19 Mar '18

19 Mar '18

#11827: InteractiveEval error handling gets a boot ModSummary instead of normal ModSummary -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given: A.hs {{{#!hs module A where data A = A f :: A -> Bool f C = False }}} A.hs-boot {{{#!hs module A where data A f :: A -> Bool }}} B.hs {{{#!hs module B where import {-# SOURCE #-} A data B = B A g :: B -> Bool g (B a) = f a }}} ghci reports: {{{ $ ghci B.hs GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/ :? for help [1 of 3] Compiling A[boot] ( A.hs-boot, interpreted ) [2 of 3] Compiling A ( A.hs, interpreted ) A.hs:6:3: error: Not in scope: data constructor ‘C’ *** Exception: expectJust showModule CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:48:27 in ghc:Maybes > }}} So instead of a normal error telling me that the C constructor does not exist, I get an additional exception from expectJust because something went wrong in GHCs internal error reporting routine. Looking at https://github.com/ghc/ghc/blob/master/compiler/main/InteractiveEval.hs#L956, the expectJust exception is due to the fact that while reporting an error about A.hs, GHCi somehow got a hold of the ModSummary of A.hs-boot instead of A.hs -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11827> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised
by GHC 19 Mar '18

19 Mar '18

#11773: linux/powepc : ghc-stage1 segfaults when building unregisterised --------------------------------+---------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building unregisterised to test code paths that don't get tested in the registerised compile mode. The segfault: {{{ "inplace/bin/ghc-stage1" -static -O -H64m -Wall -Iincludes -Iincludes/dist \ -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header \ -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP \ -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen \ -Irts/dist/build -Irts/dist/build/autogen -O2 -Wnoncanonical-monad- instances \ -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o }}} seems to occur on powerpc, but not on x86_64 or armhf. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11765: Allow documentary type signatures
by GHC 19 Mar '18

19 Mar '18

#11765: Allow documentary type signatures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (Type checker) | 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: -------------------------------------+------------------------------------- In some cases (e.g., `lens`) it's useful to document a binding with a more specific type signature than the true one, to show a useful special case. Unfortunately, this documentation can potentially be wrong or go out of date. I'd like to propose a pragma for this: {{{#!hs {-# Documentary #-} f :: T -> U }}} would ask the type checker to verify that `f :: T -> U`. Specifically, it would have the effect of creating and type checking, but then discarding, a hidden binding {{{#!hs f_doc :: T -> U f_doc t = f t }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11765> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12193: Include target versions of unlit and hsc2hs when cross-compiling
by GHC 19 Mar '18

19 Mar '18

#12193: Include target versions of unlit and hsc2hs when cross-compiling -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Hello! I have been working on getting ghc packaged on Debian for m68k and sh4. While ghc itself works without any major issues on these targets, the performance is a bit too low to just build ghc from sources on the machines itself. It works, but it may take up to three weeks or more. To workaround this problem, I am using a cross-compiled version of ghc on these platforms which works quite well. However, while using the cross- compiled Debian ghc packaged, I noticed that some packages fail to build from source because my cross-compiled version of ghc is missing the "unlit" utility. Looking at the result of the cross-compiled ghc for m68k, it's obvious why unlit is missing: {{{ glaubitz@ikarus:~/debian/ghc/ghc-8.0.1$ file ./inplace/lib/bin/* ./inplace/lib/bin/ghc-iserv: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=39f595d60d0c596714aa0fedcc0bfa3a35921c41, not stripped ./inplace/lib/bin/ghc-iserv-prof: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=f83f10fc7d925f54fb18816384ae91ae6c1b9ac8, not stripped ./inplace/lib/bin/ghc-pkg: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=41d534ca0e83df11274eade67477db1e9667fec5, not stripped ./inplace/lib/bin/ghc-stage1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=089a2121e49e16ea7ba721c350b04a965b19dded, not stripped ./inplace/lib/bin/ghc-stage2: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=589cdca9242bd132e1c80736a79ebf4209eb1c78, not stripped ./inplace/lib/bin/hpc: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=f401ba499a4cf865def36a7dc6d7c3a32385c85f, not stripped ./inplace/lib/bin/hsc2hs: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a532a7cc6f0c1e95e7c66aab2b4c53e1d0b58d88, not stripped ./inplace/lib/bin/unlit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld- linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=30ab37170ddcb09bcb7885ae3c18a353f6d128b7, not stripped glaubitz@ikarus:~/debian/ghc/ghc-8.0.1$ }}} Thus, both "unlit" and "hsc2hs" are not built for the target architecture when cross-compiling. After a quick look at utils/unlit/ghc.mk, it becomes obvious why that's the case: {{{ $(eval $(call build-prog,utils/unlit,dist,0)) }}} Would it be possible to change the build configuration such that "unlit" and "hsc2hs" are built for the target as well when cross-compiling? That would be great :). Adrian [1] [https://buildd.debian.org/status/fetch.php?pkg=haskell- fmlist&arch=m68k&ver=0.9-4&stamp=1465990971] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12038: Shutdown interacts badly with requestSync()
by GHC 19 Mar '18

19 Mar '18

#12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17