- ghc-tickets - Haskell.org

Re: [GHC] #7747: debug_p RTS is buggy (debugging and profiled)
by GHC 03 Oct '13

03 Oct '13

#7747: debug_p RTS is buggy (debugging and profiled) -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by akio): * difficulty: => Unknown Comment: I think the fix is causing #8402. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7747#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8334: unexpected type inference failure in main
by GHC 03 Oct '13

03 Oct '13

#8334: unexpected type inference failure in main ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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'm not sure if this is a failure of me understanding the semantics of type families, or something where inference should work! Or maybe its just me failing to understand the rules / convention for main. {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module PrefetchTest where import GHC.Prim import Data.Vector.Storable.Mutable -- import Foreign.ForeignPtr -- (unsafeForeignPtrToPtr) import Foreign.Ptr import GHC.ST import Data.Primitive.ByteArray import Control.Monad.Primitive -- newByteArray :: PrimMonad m => Int -> m (MutableByteArray (PrimState m)) -- sameMutableByteArray :: MutableByteArray s -> MutableByteArray s -> Bool --unsafeFreezeByteArray :: PrimMonad m => MutableByteArray (PrimState m) -> m ByteArray -- unsafeThawByteArray :: PrimMonad m => ByteArray -> m (MutableByteArray (PrimState m)) --main :: IO () main = do mv1 <- newByteArray 17 v1 <- unsafeFreezeByteArray mv1 return () }}} i get {{{ refetch.hs:42:5: No instance for (Monad m0) arising from a do statement The type variable ‛m0’ is ambiguous Relevant bindings include main :: m0 () (bound at prefetch.hs:41:1) Note: there are several potential instances: instance Monad (ST s) -- Defined in ‛GHC.ST’ instance Monad ((->) r) -- Defined in ‛GHC.Base’ instance Monad IO -- Defined in ‛GHC.Base’ ...plus one other In a stmt of a 'do' block: mv1 <- newByteArray 17 In the expression: do { mv1 <- newByteArray 17; v1 <- unsafeFreezeByteArray mv1; return () } In an equation for ‛main’: main = do { mv1 <- newByteArray 17; v1 <- unsafeFreezeByteArray mv1; return () } prefetch.hs:42:12: No instance for (PrimMonad m0) arising from a use of ‛newByteArray’ The type variable ‛m0’ is ambiguous Relevant bindings include main :: m0 () (bound at prefetch.hs:41:1) Note: there are several potential instances: instance PrimMonad IO -- Defined in ‛Control.Monad.Primitive’ instance PrimMonad (ST s) -- Defined in ‛Control.Monad.Primitive’ In a stmt of a 'do' block: mv1 <- newByteArray 17 In the expression: do { mv1 <- newByteArray 17; v1 <- unsafeFreezeByteArray mv1; return () } In an equation for ‛main’: main = do { mv1 <- newByteArray 17; v1 <- unsafeFreezeByt }}} this is because main seems to not be assumed to have type IO () If i add that type ascription to main, or I comment out the name, type inference succeeds. I understand and know we have special treatment for whats the main module, but this is an example of that special treatment changing the type inference! Is that a known issue? (its obvious to me now, but is it reasonable?) this is pretty much a nonissue, but i think its still worth noting. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8334> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8392: Suggest AllowAmbiguousTypes
by GHC 03 Oct '13

03 Oct '13

#8392: Suggest AllowAmbiguousTypes -------------------------------------------+------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- The error message I get with GHC HEAD on the example program in #8390: {{{ tf.hs:38:10: Could not deduce (Fun g a b0) arising from the ambiguity check for an instance declaration from the context (Fun f b c, Fun g a b) bound by an instance declaration: (Fun f b c, Fun g a b) => Fun (Compose f g) a c at tf.hs:38:10-56 The type variable ‛b0’ is ambiguous In the ambiguity check for: forall f g a c b. (Fun f b c, Fun g a b) => Fun (Compose f g) a c In the instance declaration for ‛Fun (Compose f g) a c’ }}} could perhaps benefit from an appended line: {{{ (To defer this ambiguity check to use sites, enable AllowAmbiguousTypes) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #3725: Annotations not written to interface files
by GHC 03 Oct '13

03 Oct '13

#3725: Annotations not written to interface files -------------------------------+------------------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: fixed | 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: 7867 | -------------------------------+------------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:7996d8f45866ac8bdf1da189ca6ef1bc38bfe3eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7996d8f45866ac8bdf1da189ca6ef1bc38bfe3eb" Tidy up the commit for Trac #3725 In particular, the mi_ann_fn field in ModIface was only being used totally locally in MkIface, so I made it local. Other than that I just refactored data types slightly, * Adding synonym Annotations.AnnPayload for the cryptic Serialized * Adding MkIface.IfaceIdExtras to common up some of the identical code }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3725#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8399: Of Bird tacks and non-blank blank lines
by GHC 02 Oct '13

02 Oct '13

#8399: Of Bird tacks and non-blank blank lines --------------------------+------------------------------------------------ Reporter: | Owner: tinctorius | Status: new Type: bug | Milestone: Priority: low | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: GHC accepts invalid program Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ {{{ > main :: IO () \begin{code} \end{code} > main = print "Hello world!" }}} According to the Haskell 1.2 report, code in Bird tacks must be hugged by blank lines (or file borders), to catch unintended use. The above should be _rejected_ during the unlit phase. However, because GHC's `unlit` thinks lines with `\begin{code}` and `\end{code}` are blank lines, the above is _accepted_. I believe this is an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7867: Allow template-haskell to communicate with itself between compilation units through the interface file
by GHC 02 Oct '13

02 Oct '13

#7867: Allow template-haskell to communicate with itself between compilation units through the interface file --------------------------+------------------------------------------------ Reporter: errge | Owner: Type: | Status: patch feature request | Milestone: 7.8.1 Priority: | Version: 7.6.3 normal | Keywords: Component: | Architecture: Unknown/Multiple Template Haskell | Difficulty: Easy (less than 1 hour) Resolution: | Blocked By: 3725, 8337, 8340, 8397, 8398 Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | --------------------------+------------------------------------------------ Changes (by errge): * status: new => patch * difficulty: Unknown => Easy (less than 1 hour) * milestone: => 7.8.1 Comment: 2 of 5 of the patches is already merged and the functionality in the rest of the 3 covers this ticket fully. Changing milestone to 7.8.1 and difficulty to easy, action to patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7867#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7783: MultiWayIf should start a new layout
by GHC 02 Oct '13

02 Oct '13

#7783: MultiWayIf should start a new layout --------------------------------------+------------------------------------ Reporter: exbb2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (Parser) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #4359 --------------------------------------+------------------------------------ Changes (by simonpj): * cc: simonmar (added) * status: closed => new * resolution: fixed => Comment: Simon, would it be possible to document the design in the user manual? For example, is it now possible to explain it by saying that a multi-way 'if' is a layout herald, so that your example behaves thus? {{{ x = if { | False -> if { | False -> 1 ; | False -> 2 } ; | True -> 3 } }}} Am I allowed to put the braces and semicolons in myself? Does the close brace get put in just before the first token to the left of the initial "|"? Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7783#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable
by GHC 02 Oct '13

02 Oct '13

#2184: if findExecutable finds a file that matchs the argument, check if it is an executable -------------------------------------+------------------------------------- Reporter: iago | Owner: leroux Type: bug | Status: patch Priority: normal | Milestone: 7.6.2 Component: | Version: 6.8.2 libraries/directory | Keywords: findExecutable Resolution: | check executable Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by leroux): * priority: lowest => normal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2184#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7971: doesDirectoryExist description differs from its behavior
by GHC 02 Oct '13

02 Oct '13

#7971: doesDirectoryExist description differs from its behavior ------------------------------------------------+-------------------------- Reporter: dsf | Owner: Type: bug | bgamari Priority: normal | Status: closed Component: libraries/directory | Milestone: Resolution: fixed | Version: 7.6.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7971#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8393: hsc2hs copies #define/#undef directives to generated .hs file when cross-compiling
by GHC 02 Oct '13

02 Oct '13

#8393: hsc2hs copies #define/#undef directives to generated .hs file when cross- compiling ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | 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: | ------------------------------------+------------------------------------- See summary. This causes a cross-compilation of ghc to fail while building GHC/Stack.hsc from libraries/base, because base.cabal no longer specifies `extensions: CPP` as of dfb52c3d5. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6