October 2013 - ghc-tickets

[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 10 Feb '14

10 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 08 Feb '14

08 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] #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] #8453: segfault/assertion failure with multi-threaded profiling
by GHC 28 Jan '14

28 Jan '14

#8453: segfault/assertion failure with multi-threaded profiling ----------------------------------+---------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Steps to reproduce: {{{ ghc-stage2 selector_thunks.hs -rtsopts -fforce-recomp -prof -threaded -debug -O2 ./selector_thunk +RTS -N4 }}} In a few seconds, it either segfaults or dies with the following error message: {{{ selector_thunks: internal error: ASSERTION FAILED: file rts/dist/build/sm/Evac_thr.c, line 778 (GHC version 7.7.20131002 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} selector_thunks.hs: {{{ import Control.Monad import Control.Concurrent import Data.IORef main = do gref <- newIORef [return ()] forM_ [0::Int ..10] $ \_ -> forkIO $ do ref <- newIORef [return ()] forever $ do list <- readIORef gref writeIORef ref $! reverse list acts <- readIORef ref last acts forM_ [1..100000099] $ \i -> writeIORef gref $! reverse $ concatMap (replicate 10) $ mapfst $ foldr (\x y -> seq x (x : y)) [] $ map f [1..10+ (div i 1000000)] mapfst :: [(a, b)] -> [a] mapfst [] = [] mapfst (x:xs) = (case x of (a, _) -> a) : mapfst xs f :: Int -> (IO (), Int) f x = (x `seq` return (), x) }}} I only tested the code with a recent HEAD, but I have seen a similar assertion failure with GHC 7.6.3, in a non-contrived application program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8180: ghc --make uses wrong way with Template Haskell
by GHC 22 Jan '14

22 Jan '14

#8180: ghc --make uses wrong way with Template Haskell ----------------------------------+--------------------------------- Reporter: goldfire | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- I have the following files: {{{ {-# LANGUAGE TemplateHaskell #-} module THSplice where number3 = [| 3 |] }}} {{{ {-# LANGUAGE TemplateHaskell #-} module Main where import THSplice main = putStrLn (show $number3) }}} When I say `ghc Main.hs`, I get this: {{{ [1 of 2] Compiling THSplice ( THSplice.hs, THSplice.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Main.hs:7:23: cannot find normal object file ‛./THSplice.dyn_o’ while linking an interpreted expression }}} It's possible a different collection of flags could get this to work, but I think this behavior goes against the intended "it just works" flavor of `--make`. This is a regression bug -- ghc 7.6.3 does the right thing. I'm on MacOS 10.7.5, Xcode 4.3.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8451: Link problem on FreeBSD
by GHC 18 Jan '14

18 Jan '14

#8451: Link problem on FreeBSD ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: high | Version: 7.7 Component: Compiler | Operating System: FreeBSD Keywords: | Type of failure: GHC doesn't work at all Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- GHC head on FreeBSD causes a link error if -prof and -threaded are specified: {{{ % cat main.hs main = putStrLn "hello" % ghc -prof -threaded main.hs [1 of 1] Compiling Main ( main.hs, main.o ) /usr/local/lib/gcc47/gcc/x86_64-portbld- freebsd9.1/4.7.3/../../../../../x86_64-portbld-freebsd9.1/bin/ld: cannot find -lthr collect2: error: ld returned 1 exit status }}} Note that libHSrts_thr* are certainly installed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8275: Loopification breaks profiling
by GHC 02 Dec '13

02 Dec '13

#8275: Loopification breaks profiling ----------------------------------+---------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Profiling is currently broken in HEAD. Setting `BuildFlavour = prof` in `build.mk` leads to a segfault during build. After reverting d61c3ac186c94021c851f7a2a6d20631e35fc1ba (loopification performed in the code generator) everything builds without problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #8220: Macros / functions for source location
by GHC 01 Dec '13

01 Dec '13

#8220: Macros / functions for source location ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- In GNAT (Ada compiler) there is a special package with functions (evaluated at compile time) that return source location and enclosing entity name. This is very useful for logging and debugging. I'd love to have something similar in GHC. http://www.radford.edu/~nokie/classes/320/std_lib_html/gnat- source_info.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7