December 2015 - ghc-tickets

[GHC] #11227: Interaction between ORF and record pattern synonyms needs to be resolved.
by GHC 15 Dec '15

15 Dec '15

#11227: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, orf | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the two extensions do not work well together. When defining a record pattern synonym all field names must be distinct even with the extension turned on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10636: Clear up difference between `WayDyn` and `Opt_Static`
by GHC 15 Dec '15

15 Dec '15

#10636: Clear up difference between `WayDyn` and `Opt_Static` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | 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: | -------------------------------------+------------------------------------- There are currently 2 different ways to test for a static or dynamic build: 1. Test if `WayDyn` is in `ways` 2. Test if `Opt_Static` is set Unless there's a use-case for setting `WayDyn`/`Opt_Static` inconsistently (if so, please add a `Note` somewhere), it should be possible to replace all queries of `Opt_Static` with an equivalent query of `WayDyn`. That would have prevented bug #8294. See the comments in Phab:D1017. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind
by GHC 15 Dec '15

15 Dec '15

#11207: GHC cannot infer injectivity on type family operating on GHC.TypeLits' Nat, but can for equivalent type family operating on user-defined Nat kind -------------------------------------+------------------------------------- Reporter: duairc | 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 following does not work: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} import GHC.TypeLits (Nat, type (-)) type family Replicate (n :: Nat) (a :: k) = (r :: [k]) | r -> n where Replicate 0 a = '[] Replicate n a = a ': Replicate (n - 1) a }}} It fails to compile with the following error: {{{ error: • Type family equation violates injectivity annotation. Type variable ‘n’ cannot be inferred from the right-hand side. In the type family equation: forall (k :: BOX) (n :: Nat) (a :: k). Replicate n a = a : Replicate (n - 1) a • In the equations for closed type family ‘Replicate’ In the type family declaration for ‘Replicate’ Failed, modules loaded: none. }}} However, the following does: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} data Nat = Zero | Succ Nat type family Replicate (n :: Nat) (a :: k) = (r :: [k]) | r -> n where Replicate Zero a = '[] Replicate (Succ n) a = a ': Replicate n a }}} Sure GHC.TypeLits' built-in Nat type is isomorphic to the one defined above, and thus GHC should be able to infer injectivity for Replicate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 15 Dec '15

15 Dec '15

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes yes yes this would be wonderful. Would you like to design and implement it? :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 15 Dec '15

15 Dec '15

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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: | -------------------------------------+------------------------------------- Comment (by osa1): If we could come up with a nice syntax for function definitions with or- patterns this would be really useful for GHC's own code too. Often we have to re-compile GHC many times and test on some programs to discover all the places we need to update after adding a new data constructor, because of "catch-all" code like this: {{{#!haskell f A = ... f B = ... f unexpected = pprTrace "f" (ppr unexpected) }}} With or patterns, we could do this instead: {{{#!haskell f A = ... f B = ... f unexpected@(C{} | D{} | E{}) = pprTrace "f" (ppr unexpected) }}} (just made up a syntax) This would be very convenient, because now I get a warning after adding data constructor D - instead of discovering this code after a runtime failure. And what happens if I couldn't discover this code because I couldn't come up with an example program that makes GHC run this function? So it's a bit tricky and annoying right now, and it's costing us time because of recompilations and tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 15 Dec '15

15 Dec '15

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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 osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD
by GHC 15 Dec '15

15 Dec '15

#7273: Binary size increase in nofib/grep between 7.6.1 and HEAD -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.0.1 => 8.2.1 Comment: Lowering in priority and bumping to 8.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7273#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 15 Dec '15

15 Dec '15

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7880 | Differential Rev(s): Phab:D211, Wiki Page: | Phab:D1615 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I've opened #11221 to ensure that the last traces of this flag are removed next release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11185: runghc can't find ghc-stage2 on a Windows build
by GHC 15 Dec '15

15 Dec '15

#11185: runghc can't find ghc-stage2 on a Windows build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.11 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally [https://mail.haskell.org/pipermail/ghc- devs/2015-December/010729.html reported] on the ghc-devs mailing list.) After completing a stage-2 GHC build on Windows, `runghc` does not work at all. Calling it on any file will result in the following error: {{{ $ .\ghc\inplace\bin\runghc.exe Z.hs runghc.exe: C:\Users\ryanscot\Documents\Software\ghc\inplace\bin\ghc: rawSystem: does not exist (No such file or directory) }}} A workaround is to make a symlink to `ghc-stage2` with `ln -s ghc- stage2.exe ghc.exe` in MSYS2. This leads me to believe that Windows' `runghc` is always looking for `ghc` even when it ''should'' be looking for `ghc-stage2` in this particular scenario. [http://git.haskell.org/ghc.git/blob/1f1c7c610b0ff26dccaef089e27003497fa25be… This code] in `runghc` looks highly suspect: {{{#!hs let ghc = takeDirectory (normalise path) </> "ghc" in uncurry (doIt ghc) $ getGhcArgs args' }}} It probably shouldn't be hardcoding the name `"ghc"` here. On Unix-like OSes, this doesn't appear to be an issue since `runghc` invokes a [http://git.haskell.org/ghc.git/blob/6d17125dccda76b7aafe33181df822045ff5b9b… shell script] that detects the proper `ghc` name and invokes the `runghc` ''executable''. On the other hand, I believe on Windows calling `runghc` directly invokes the executable, so the proper name detection never happens. What would be a proper fix for this? I'm tempted to just have `runghc` check for `ghc-stage2`'s existence and fall back on `ghc`, but I'd like to get the opinions of people familiar with the build system so that the fix is robust. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld
by GHC 15 Dec '15

15 Dec '15

#8294: T7478 fails on Mac OS X with "unexpected bindingNone" from ld -----------------------------------+--------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: T7478 Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- (Tangentially, the test script was swallowing up relevant output; you need to get rid of the output hook to see any debugging output from GHC proper). Linker step fails: {{{ *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -v -o A -Wl,-no_compact_unwind C.o -L/Users/ezyang/Dev/ghc-init/libraries/base /dist-install/build -L/Users/ezyang/Dev/ghc-init/libraries/integer-gmp /dist-install/build -L/Users/ezyang/Dev/ghc-init/libraries/ghc-prim/dist- install/build -L/Users/ezyang/Dev/ghc-init/rts/dist/build /var/folders/l8/1lth36c11yg8dv_3kz779_th0000gn/T/ghc26290_0/ghc26290_10.o -lHSbase-4.7.0.0-ghc7.7.20130913 -lHSinteger-gmp-0.5.1.0-ghc7.7.20130913 -lHSghc-prim-0.3.1.0-ghc7.7.20130913 -lHSrts-ghc7.7.20130913 -lffi -liconv -lm -ldl -Wl,-u,_ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,_base_GHCziPtr_Ptr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,_base_GHCziInt_I8zh_static_info -Wl,-u,_base_GHCziInt_I16zh_static_info -Wl,-u,_base_GHCziInt_I32zh_static_info -Wl,-u,_base_GHCziInt_I64zh_static_info -Wl,-u,_base_GHCziWord_W8zh_static_info -Wl,-u,_base_GHCziWord_W16zh_static_info -Wl,-u,_base_GHCziWord_W32zh_static_info -Wl,-u,_base_GHCziWord_W64zh_static_info -Wl,-u,_base_GHCziStable_StablePtr_static_info -Wl,-u,_ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,_ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,_base_GHCziPtr_Ptr_con_info -Wl,-u,_base_GHCziPtr_FunPtr_con_info -Wl,-u,_base_GHCziStable_StablePtr_con_info -Wl,-u,_ghczmprim_GHCziTypes_False_closure -Wl,-u,_ghczmprim_GHCziTypes_True_closure -Wl,-u,_base_GHCziPack_unpackCString_closure -Wl,-u,_base_GHCziIOziException_stackOverflow_closure -Wl,-u,_base_GHCziIOziException_heapOverflow_closure -Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,_base_GHCziTopHandler_runIO_closure -Wl,-u,_base_GHCziTopHandler_runNonIO_closure -Wl,-u,_base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,_base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,_base_GHCziConcziSync_runSparks_closure -Wl,-u,_base_GHCziConcziSignal_runHandlers_closure -Wl,-search_paths_first Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable- checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program- prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with- slibdir=/usr/lib --build=i686-apple-darwin11 --enable- llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst- llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.3 -weak_reference_mismatches non-weak -o A -lcrt1.10.6.o -L/Users/ezyang/Dev /ghc-init/libraries/base/dist-install/build -L/Users/ezyang/Dev/ghc- init/libraries/integer-gmp/dist-install/build -L/Users/ezyang/Dev/ghc- init/libraries/ghc-prim/dist-install/build -L/Users/ezyang/Dev/ghc- init/rts/dist/build -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple- darwin11/4.2.1/x86_64 -L/Applications/Xcode.app/Contents/Developer/usr /llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/llvm- gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm- gcc-4.2/bin/../lib/gcc -L/Applications/Xcode.app/Contents/Developer/usr /llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm- gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686 -apple-darwin11/4.2.1/../../.. -no_compact_unwind C.o /var/folders/l8/1lth36c11yg8dv_3kz779_th0000gn/T/ghc26290_0/ghc26290_10.o -lHSbase-4.7.0.0-ghc7.7.20130913 -lHSinteger-gmp-0.5.1.0-ghc7.7.20130913 -lHSghc-prim-0.3.1.0-ghc7.7.20130913 -lHSrts-ghc7.7.20130913 -lffi -liconv -lm -ldl -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _ghczmprim_GHCziTypes_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziTypes_False_closure -u _ghczmprim_GHCziTypes_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u _base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_flushStdHandles_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConcziIO_ensureIOManagerIsRunning_closure -u _base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -u _base_GHCziConcziSync_runSparks_closure -u _base_GHCziConcziSignal_runHandlers_closure -search_paths_first -lSystem -lgcc -lSystem ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in _Main_main_info from C.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie final section layout: __TEXT/__text addr=0x100000D30, size=0x00000218, fileOffset=0x00000D30, type=1 __TEXT/__stubs addr=0x100000F48, size=0x0000001E, fileOffset=0x00000F48, type=27 __TEXT/__stub_helper addr=0x100000F68, size=0x00000042, fileOffset=0x00000F68, type=31 __TEXT/__eh_frame addr=0x100000FB0, size=0x00000048, fileOffset=0x00000FB0, type=18 __DATA/__program_vars addr=0x100001000, size=0x00000028, fileOffset=0x00001000, type=29 __DATA/__got addr=0x100001028, size=0x00000020, fileOffset=0x00001028, type=28 __DATA/__nl_symbol_ptr addr=0x100001048, size=0x00000010, fileOffset=0x00001048, type=28 __DATA/__la_symbol_ptr addr=0x100001058, size=0x00000028, fileOffset=0x00001058, type=26 __DATA/__data addr=0x100001080, size=0x00000040, fileOffset=0x00001080, type=0 __DATA/__const addr=0x1000010C0, size=0x00000018, fileOffset=0x000010C0, type=0 __DATA/__common addr=0x1000010D8, size=0x00000020, fileOffset=0x00000000, type=24 ld: unexpected bindingNone in '_Main_main_info' from C.o for architecture x86_64 collect2: ld returned 1 exit status T7478: T7478: phase `Linker' failed (exitcode = 1) }}} Unfortunately, I don't know what a bindingNone is... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2