January 2014 - ghc-tickets

[GHC] #8698: .ctors handling does not work on Windows 64-bit ghci
by GHC 17 Feb '14

17 Feb '14

#8698: .ctors handling does not work on Windows 64-bit ghci ----------------------------------+------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------- When fixing #7134 I've found .ctors section handling does not work on 64-bit Windows ghci. Patch https://ghc.haskell.org/trac/ghc/attachment/ticket/7134/ghc- w64fix.patch now disables .ctor handling for 64-bit Windows ghci. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8706: Kind operators not parsed
by GHC 17 Feb '14

17 Feb '14

#8706: Kind operators not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Take the following module: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies #-} data a + b = Inl a | Inr b type family Foo :: Bool + Bool }}} HEAD produces {{{ /Users/rae/temp/Bug.hs:5:25: parse error on input ‛+’ }}} It seems that type operators promoted to kinds are not parsed correctly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8305: ghci macros override built-ins for command expansion
by GHC 13 Feb '14

13 Feb '14

#8305: ghci macros override built-ins for command expansion ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8113 | ------------------------------------+------------------------------------- I have a ghci macro `:tsu` from the ghc-vis package, which I installed a long time ago. In HEAD ghci (since the patch for #8113) this causes `:t` to expand to `:tsu`, rather than `:type`. That happened to result in a weird error the first time I tried to use `:t` (something like `Prelude.read: no parse`), and it took me a while to diagnose that my `.ghci` file was the issue! I don't like this new behavior because it forces me to either change my ghci habits (start using `:type` instead of `:t`) or avoid macros starting with any letter that I currently use as a single-letter ghci command. I set this ticket priority to highest because in any event this new behavior shouldn't sneak in to a GHC release unnoticed. Below is my proposal for how `:commands` should be interpreted now that built-in commands can be overridden (#8113), copied from a comment I made recently on that ticket. ---- I suppose what I specifically want to happen when I enter a `:command` is an algorithm like this. If the name I entered is an exact match for a macro or built-in, use that name. Otherwise, try to complete the name to the name of a ''built-in'' in the traditional way. If this succeeds, use the resulting name. Otherwise, try to complete the name to the name of a macro, and use the resulting name if that succeeds, otherwise give up. In all cases where we got a name, use the ''macro'' of that name if there is one, and otherwise use the built-in. (Obviously, for `::command`, ignore macros entirely.) In other words, built-ins should take precedence over macros for the purpose of name ''completion'', but macros should take precedence over built-ins for the purpose of name ''lookup''. This is backwards- compatible from the perspective of the user who is not aware of the change—`:t` will always mean `:type`, as long as the user has no macro named `:t`, just like in previous versions of ghci—while still allowing the aware user to redefine exactly what `:type` means. And it's flexible enough in that if the user really wants `:t` to complete to some other macro `:test` that they've written, they can always define another macro `:t` to expand to `:test`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8305> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing
by GHC 12 Feb '14

12 Feb '14

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing ------------------------------------+------------------------------------- Reporter: refold | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 1377 | ------------------------------------+------------------------------------- The `GHC.Exts` module exports functions [[http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC- Exts.html#g:6|breakpoint and breakpointCond]]. Right now they are no-ops, but apparently at some point in the past could be used to set breakpoints programmatically. From my reading of the source code, this feature was removed (either accidentally or on purpose) when the implementation of breakpoints [[changeset:cdce647711c0f46f5799b24de087622cb77e647f/ghc|was reworked]]. Relevant commits: * 31751ccacc24ebe5d15a0af84b10dc612d455440 * 3a99fa889bdff0c86df20cb18c71d30e30a79b43 * cdce647711c0f46f5799b24de087622cb77e647f Initially reported [http://stackoverflow.com/questions/19283911/how-do-i -use-ghc-exts-breakpoint here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8469: GHCi reports out-of-scope type family instances with :info
by GHC 09 Feb '14

09 Feb '14

#8469: GHCi reports out-of-scope type family instances with :info ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have {{{ {-# LANGUAGE TypeFamilies #-} module A () where type family F a type instance F Int = Bool }}} {{{ module B where import A }}} In GHCi: {{{ Prelude> :load B [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) Ok, modules loaded: B, A. *B> :i Int data Int = GHC.Types.I# GHC.Prim.Int# -- Defined in ‛GHC.Types’ <snip> type instance A.F Int -- Defined at A.hs:6:1 *B> }}} This last output from `:info` should be suppressed, I would think. (I agree it should be printed with `:info!`.) Note the `()` in module `A`'s export list. This is a regression from 7.6.3, where the out-of-scope type family instance is not printed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8264: Canonical way to prevent manual instances
by GHC 07 Feb '14

07 Feb '14

#8264: Canonical way to prevent manual instances -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- For some classes (Typeable) the user must not provide hand-written instances, for other no hand-written instances in Safe mode (old Typeable) and for others no instances at all (Coercible). Currently the Typeable checks are in tcInstDecls1 in [source:compiler/typecheck/TcInstDcls.lhs]; but a more proper place would be in checkValidInstHead in [source:compiler/typecheck/TcValidity.lhs]. Why file a ticket and not just do it? The latter source location does not know whether the instance is a (stand-alone) deriving instance or a hand- written one, so this needs a bit of refactoring. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8717: Segfault in 64-bit Windows GHCi
by GHC 04 Feb '14

04 Feb '14

#8717: Segfault in 64-bit Windows GHCi ----------------------------------------+------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.8.1-rc1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Difficult (2-5 days) | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------------+------------------------------- This code: {{{ module Bug where import Data.Data c :: Constr c = toConstr False }}} gives segfault when trying to evaluate {{{c}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8270: unknown symbol "atomic_inc" in GHCi when loading package ghc
by GHC 04 Feb '14

04 Feb '14

#8270: unknown symbol "atomic_inc" in GHCi when loading package ghc ----------------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I tried to do a "quick-llvm" build of a distclean-ed tree and got an error when some dph package needed to load the ghc package in Template Haskell. I no longer have that exact error message, but I could reproduce it more simply as follows: {{{ rwbarton@adjunction:~/dist/ghc4$ ./inplace/bin/ghc-stage2 --interactive -package ghc-7.7.20130910 GHCi, version 7.7.20130910: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.2 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.3.0 ... linking ... done. Loading package containers-0.5.3.1 ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.1 ... linking ... done. Loading package unix-2.7.0.0 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package Cabal-1.18.0 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package bin-package-db-0.0.0.0 ... linking ... done. Loading package hoopl-3.10.0.0 ... linking ... done. Loading package hpc-0.6.0.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package ghc-7.7.20130910 ... linking ... ghc-stage2: /home/rwbarton/dist/ghc4/compiler/stage2/build/libHSghc-7.7.20130910.a: unknown symbol `atomic_inc' ghc-stage2: unable to load package `ghc-7.7.20130910' }}} `atomic_inc` is used by `compiler/cbits/genSym.c`. It's defined in libHSrts of course, but apparently not all rts symbols are automatically available in the GHCi linker? I added a {{{ SymI_HasProto(atomic_inc) \ }}} in `RTS_SYMBOLS` in `rts/Linker.c` and the problem seems to be solved. I'm not really sure what the difference between `SymI_` and `SymE_` is, it looks Windows-related. Maybe other stuff like `atomic_dec` should be added too. I'm pretty sure I didn't run into this problem with a "quick" build, though I have no idea how it could be specific to "quick-llvm". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8690: Failed to compile Win32 libraries using 64 bit GHC.
by GHC 04 Feb '14

04 Feb '14

#8690: Failed to compile Win32 libraries using 64 bit GHC. -----------------------------------+--------------------------------------- Reporter: | Owner: andrewrademacher | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Windows Keywords: | Type of failure: Compile-time crash Architecture: x86_64 (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Loading package Win32-2.3.0.0 ... linking ... ghc.exe: internal error: R_X86_64_PC32: High bits are set in 7ffb728ca4d4 for DefDlgProcW (GHC version 7.6.3 for x86_64_unknown_mingw32) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8720: ghc crash
by GHC 01 Feb '14

01 Feb '14

#8720: ghc crash ------------------------------------------------+-------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: ghci crash mvar thread block | Operating System: Architecture: x86_64 (amd64) | Windows Difficulty: Unknown | Type of failure: GHCi Blocked By: | crash Related Tickets: | Test Case: | Blocking: ------------------------------------------------+-------------------------- ghc.exe: panic! (the 'impossible' happened) (GHC version 7.6.3 for i386-unknown-mingw32): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I didn't try to reproduce it, but figured someone might want it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8720> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2