October 2013 - ghc-tickets

Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell
by GHC 13 Oct '13

13 Oct '13

#1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: TH_import_loop | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by goldfire): I just got bitten by this, and I don't see a clean reorganization. While I agree that this should be "lowest" priority, I thought I'd document my real-life use case: The singletons library generates a fair amount of code using TH. In particular, it produces instances for classes, type families, and data families. Accordingly, the TH code needs to know the names of these classes and families, and the names of the class members. In the main module of the library, I want to use the TH code to produce lots of instances for datatypes exported from base (`Bool`, `Maybe`, `()`, ...). I don't want these instances to be orphans. So, I'm stuck. I'll illustrate further with some code: Module `Data.Singletons` (boot): {{{ data family Sing (a :: k) }}} Module `Data.Singletons.Singletons`: {{{ import {-# SOURCE #-} Data.Singletons singName :: Name singName = ''Sing genSingletons :: [Name] -> Q [Dec] genSingletons = ... }}} Module `Data.Singletons`: {{{ import Data.Singletons.Singletons data family Sing (a :: k) $(genSingletons [''Bool, ''Maybe, ''Either, ''[]]) }}} This all seems quite sensible to me, yet GHC can't do it. It seems I have several bad options: 1) allow orphans, defining the `Sing` family in a different module than its instances; 2) hand-write the instances I want, avoiding the loop; or 3) use `mkName` to create the names. I'm going to do (3), but it feels dirty and fragile. Note: I do see why calling a function at compile time that is defined in a module in a mutually-recursive group with the calling module could be very bad. But, I'm not quite doing that here. That said, I don't see an easy way to allow what I want, prohibit the bad behavior, and not pollute the syntax and implementation of it all. The reason for this comment is just to document a case where I'm a little hamstrung by this missing behavior, not that I really want resources dedicated to finding a fix here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1012#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8412: TH allows negative type-level integers
by GHC 12 Oct '13

12 Oct '13

#8412: TH allows negative type-level integers -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Easy (less than 1 | invalid program hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Similar to #8306, it is possible to create type-level -1 via {{{ type T = $(return $ LitT $ NumTyLit (-1)) }}} Easy to fix with new TH by moving the check from parser to renamer. I'm preparing a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8436: Stack overflow when masked should still throw at interruptible operations or inner unmask
by GHC 11 Oct '13

11 Oct '13

#8436: Stack overflow when masked should still throw at interruptible operations or inner unmask -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Currently, to deal with #767, stack overflow exceptions are never emitted when exceptions are masked; e.g. if the thread unmasks and it is back under the stack limit, it will be as if the thread never stack-overflowed. However, it seems that we can be a bit more proactive about throwing the exception, in a way similar to asynchronous exceptions, wherein we add the stack overflow to the blocked exceptions list and let it be thrown at an interruptible point or if the exceptions get unmasked. Patch would be pretty simple, I'd like to check if people think this is a better idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8436> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3722: Haskeline Iconv needs HAVE_LANGINFO_H
by GHC 10 Oct '13

10 Oct '13

#3722: Haskeline Iconv needs HAVE_LANGINFO_H ----------------------------------------+------------------------------ Reporter: donn | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: libraries (other) | Version: 6.12.1 RC1 Resolution: fixed | Keywords: Operating System: Other | Architecture: x86 Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------------+------------------------------ Changes (by judahj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This has been fixed in haskeline, which tests for HAVE_LIBCHARSET before HAVE_LANGINFO_H: https://github.com/ghc/packages- base/commit/b56d2e60a1141e9fc23d795b5b7222921670a285 If that does not resolve the issue for you, please let us know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3722#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7774: T5313 fails
by GHC 10 Oct '13

10 Oct '13

#7774: T5313 fails -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHC API | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by gmainland): Yes it is, but the error is slightly different: {{{ =====> T5313(normal) 2009 of 3799 [0, 0, 0] cd ./driver && '/home/mainland/ghc/ghc-working-build/inplace/bin/ghc- stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -fno-ghci-history -o T5313 T5313.hs -package ghc >T5313.comp.stderr 2>&1 cd ./driver && ./T5313 "/home/mainland/ghc/ghc-working-build/inplace/lib" </dev/null >T5313.run.stdout 2>T5313.run.stderr Wrong exit code (expected 0 , actual 1 ) Stdout: Stderr: T5313: <command line>: can't load .so/.DLL for: /home/mainland/ghc/ghc- working-build/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20131010.so (/home/mainland/ghc/ghc-working- build/libraries/ghc-prim/dist-install/build/libHSghc- prim-0.3.1.0-ghc7.7.20131010.so: undefined symbol: stg_forkOnzh) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7774#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8434: dynflag dependency addition in TcRnDriver is not needed anymore
by GHC 10 Oct '13

10 Oct '13

#8434: dynflag dependency addition in TcRnDriver is not needed anymore -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- The removed parts of the tcRnImports function in the attached patch says that there is a check in LoadIface.loadInterface and this is why it's needed to add the plugin dependencies to the EPS. But actually [[GhcFile(compiler/iface/LoadIface.lhs#L227)]] says that the check is no longer there. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8432: clarify throwTo documentation
by GHC 10 Oct '13

10 Oct '13

#8432: clarify throwTo documentation -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- As discussed in the thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23889 the documentation of {{{GHC.Conc.throwTo}}} is not 100% clear on the provided atomicity guarantees. In http://article.gmane.org/gmane.comp.lang.haskell.libraries/20218 I proposed a patch for said documentation but it seems to have slipped through the cracks. Can somebody please have a look and - hopefully - apply it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8421: ghc build failure with template haskell on ghc head
by GHC 10 Oct '13

10 Oct '13

#8421: ghc build failure with template haskell on ghc head ----------------------------------+---------------------------------------- Reporter: schell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- It seems that it failed while building template haskell with this output: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name ghc-7.7.20131008 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP- DGHCI -optP-include -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1 -package array-0.4.0.2 -package base-4.7.0.0 -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0 -package containers-0.5.3.1 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1 -package process-1.2.0.0 -package template-haskell-2.9.0.0 -package time-1.4.1 -package transformers-0.3.0.0 -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRankNTypes -XScopedTypeVariables -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -O2 -no-user-package-db -rtsopts -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/typecheck/TcSplice.lhs -o compiler/stage2/build/TcSplice.o -dyno compiler/stage2/build/TcSplice.dyn_o compiler/typecheck/TcSplice.lhs:1068:3: ‛qAddTopDecls’ is not a (visible) method of class ‛TH.Quasi’ compiler/typecheck/TcSplice.lhs:1099:3: ‛qAddModFinalizer’ is not a (visible) method of class ‛TH.Quasi’ compiler/typecheck/TcSplice.lhs:1103:3: ‛qGetQ’ is not a (visible) method of class ‛TH.Quasi’ compiler/typecheck/TcSplice.lhs:1109:3: ‛qPutQ’ is not a (visible) method of class ‛TH.Quasi’ make[1]: *** [compiler/stage2/build/TcSplice.o] Error 1 make: *** [all] Error 2 }}} Here is my gcc -v: {{{ schell@localhost:~/C/ghc:master$ gcc -v 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) }}} I'm on Mac OS X 10.8.5. Before fast forwarding to HEAD I was encountering #8276 though I don't know if this build got further or less far :(. I'm attaching what I hope is the ghc fingerprint I got using ./utils/fingerprint/fingerprint.py create -o fingerprint.log... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8431: ghci freezes in multiline when passed a closing paren
by GHC 10 Oct '13

10 Oct '13

#8431: ghci freezes in multiline when passed a closing paren -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- {{{ Prelude> :set +m Prelude> ) }}} Never returns. Patch attached. John's code was buggy and reachable, apparently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8430: Literate haskell accepts spurious \end{code} lines
by GHC 10 Oct '13

10 Oct '13

#8430: Literate haskell accepts spurious \end{code} lines -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Easy (less than 1 | invalid program hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- In #8428 klao removed a spurious \end{code} from `TypeRep.lhs`. This made it clear that GHC has accepts spurious \end{code} lines in literate haskell code. This patch fixes the literate haskell preprocessor to issue an error in this case. Interestingly though, after this change nothing breaks except for klao's already merged patch, so this issue was not found in other .lhs files through GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1