October 2016 - ghc-tickets

[GHC] #10599: Template Haskell doesn't allow `newName "type"`
by GHC 07 Aug '18

07 Aug '18

#10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using `type` as a name is, of course, forbidden. OTOH, `type_1` is allowed as a name. However, using GHC 7.10.1 and `ghc --make T.hs` on files: {{{#!hs -- T.hs {-# LANGUAGE TemplateHaskell #-} module T where import Q test -- Q.hs module Q where import Language.Haskell.TH test :: Q [Dec] test = do t <- newName "type" return [FunD t [Clause [] (NormalB $ LitE $ CharL 't') []]] }}} Leads to the following error: {{{ $ ghc --make -ddump-splices T.hs [2 of 2] Compiling T ( T.hs, T.o ) T.hs:6:1: Illegal variable name: ‘type’ When splicing a TH declaration: ident_0 type_1 = type_1 }}} The above example works fine for GHC 7.8.4, so it's a regression. Reference: https://github.com/yesodweb/persistent/issues/412 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #10355: Dynamic linker not initialised
by GHC 07 Aug '18

07 Aug '18

#10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- I get this message: [ 3 of 24] Compiling Cable ( src/Cable.hs, dist/build/ui/ui- tmp/Cable.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug when building my code here: https://github.com/dpiponi/Moodler/tree/master/Moodler/src under Yosemite 10.10.2 So I'm reporting it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9868: ghc: panic! Dynamic linker not initialised
by GHC 07 Aug '18

07 Aug '18

#9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was playing around and not expecting cabal build to succeed yet. If if didn't say the impossible had happened I would assumed I was missing something and used the error to drive my next action {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} There had been another error before: {{{ <no location info>: <command line>: can't load .so/.DLL for: /Users/JamesEJ/bindings- cef3/dist/build/libHSbindings-cef3-0.1.0-ghc7.8.3.dylib (dlopen(/Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib, 9): Symbol not found: _cef_add_cross_origin_whitelist_entry Referenced from: /Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib Expected in: flat namespace in /Users/JamesEJ/bindings-cef3/dist/build/libHSbindings- cef3-0.1.0-ghc7.8.3.dylib) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12607: Memory effects in doomed STM transactions
by GHC 07 Aug '18

07 Aug '18

#12607: Memory effects in doomed STM transactions -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: STM, allocate | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Problem == GHC's STM implementation does "lazy" validation meaning that speculative execution can continue even after observing an inconsistent view of memory. Transactions in the state are called "doomed transactions". While the runtime tries to avoids some effects in doomed transactions, such as entering an infinite loop, it does not successfully control all memory effects. In particular there are many (I do not have an exhaustive list) allocations that eventually end up in the `allocate` function which is nicely documented with the following: > `allocate()` never > fails; if it returns, the returned value is a valid address. If > the nursery is already full, then another block is allocated from > the global block pool. If we need to get memory from the OS and > that operation fails, then the whole process will be killed. https://github.com/ghc/ghc/blob/master/rts/sm/Storage.c#L819 A doomed transaction that demands a large allocation that the OS cannot fulfill will kill the process. Here is a program that reliably fails for me: {{{#!hs -- oom.hs {-# LANGUAGE BangPatterns #-} import GHC.Conc import Control.Concurrent import qualified Data.ByteString as B forever act = act >> forever act check True = return () check False = retry main = do tx <- newTVarIO 0 ty <- newTVarIO 1 tz <- newTVarIO 0 done <- newTVarIO False _ <- forkIO $ forever $ atomically $ do -- Only read tx and ty x <- readTVar tx y <- readTVar ty if x > y -- This should always be False then do -- We only get here in a doomed transaction. Commenting out the next two lines -- but leaving the write to done and the program runs as expected because the -- doomed transaction is detected at commit time. let !big = B.length $ B.replicate maxBound 0 -- The big allocation! writeTVar tz big writeTVar done True else return () let mut = forever $ atomically $ do y <- readTVar ty x <- readTVar tx if x > 1000 then do -- When we get big enough, start over. writeTVar tx 0 writeTVar ty 1 -- Always holds semantically that tx < ty else do -- increment x and y both writeTVar ty (succ y) writeTVar tx (succ x) -- tx < ty -- Give lots of opportunities to witness inconsistent memory. _ <- forkIO mut _ <- forkIO mut _ <- forkIO mut atomically $ readTVar done >>= check putStrLn "Done" }}} Running leads to out of memory: {{{#!bash > ghc oom.hs -fno-omit-yields -threaded [1 of 1] Compiling Main ( oom.hs, oom.o ) Linking oom.exe ... > ./oom.exe +RTS -N oom.exe: out of memory }}} == Fixing == When a potentially bad memory effect is about to happen in some thread, we need to ensure that we validate any running transaction and if it fails have some way to back out of the operation and abort the transaction. This might be tricky on two fronts 1) finding all the critical allocations and 2) finding places where we can both detect (1) and abort the transaction. The places I'm concerned about most are array allocation such as the `ByteString` in the example and maybe `Integer` allocation. Another fix is a different STM implementation altogether that (at a performance cost or trade-off) doesn't allow doomed transactions (to appear Haskell Symposium 2016 :D). I think we can at least address this particular example without going so far. A related issue is more general memory leaks from doomed transactions. Consider a program with a memoized Fibonacci function. The semantics of the transactions written by the programmer may ensure that no value higher then 10 is ever demanded of that function, yet in a doomed transaction the invariant goes wrong and the program demands 100. The program will detect the doomed transaction eventually in this case, but not before it has allocated a large live blob never to be touched again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12625: Bad error message for flags with required but missing arguments
by GHC 06 Aug '18

06 Aug '18

#12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- {{{ $ ghc -I ghc: unrecognised flag: -I did you mean one of: -I -F -v Usage: For basic information, try the `--help' option. }}} Which is confusing (Unrecognized `-I`. Did you mean `-I`?), and not informative (No mention of the missing argument) I expect something like "missing argument for `-I`", or a basic usage info on `-I` instead. It looks similar to #9776 to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10087: DefaultSignatures: error message mentions internal name
by GHC 02 Aug '18

02 Aug '18

#10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: Compiler | Type of failure: Other (Type checker) | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DefaultSignatures #-} class C a where reflexive :: a -> Bool default reflexive :: Eq a => a -> Bool reflexive x = x == x data D instance C D where -- /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: -- No instance for (Eq D) arising from a use of ‘Main.$gdmreflexive’ -- In the expression: Main.$gdmreflexive -- In an equation for ‘reflexive’: reflexive = Main.$gdmreflexive -- In the instance declaration for ‘C D’ }}} Error looks odd: The user has not written $gdmreflexive in his code. TODO: Better error message. Maybe this should just trigger a warning that method {{{reflexive}}} is undefined for instance {{{D}}} of {{{C}}}. Like when I remove the default method. {{{ /home/abel/play/haskell/bugs/DefaultSig.hs:10:10: Warning: No explicit implementation for ‘reflexive’ In the instance declaration for ‘C D’ }}} It seems the semantics of a default signature is that each instance *must* implement this method. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12096: Attach stacktrace information to SomeException
by GHC 02 Aug '18

02 Aug '18

#12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Now (base 4.9.0.0) ErrorCall contain field for stacktrace information and error fills it. If you add field for stacktrace information to SomeException {{{#!hs data SomeException where SomeExceptionWithLocation :: Exception e => String -> e -> SomeException pattern SomeException :: () => Exception e => e -> SomeException pattern SomeException err <- SomeExceptionWithLocation _ err where SomeException err = SomeExceptionWithLocation "" err }}} and will fills it in throw {{{#!hs throw :: (HasCallStack, Exception e) => e -> a throw e = unsafeDupablePerformIO $ do stack <- currentCallStack raise# (CallStackException e $ if stack /= [] then prettyCallStack ?callStack ++ "\n" ++ renderStack stack else prettyCallStack ?callStack) }}} it will be more useful for ghci users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #11759: can't decompose ghc.exe path
by GHC 02 Aug '18

02 Aug '18

#11759: can't decompose ghc.exe path --------------------------------------+---------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{ erisco@ERICWIN C:\Users\erisco\haskell-platform-bin $ ghc.exe ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\erisco\\haskell- platform-bin\\ghc.exe" }}} haskell-platform-bin is a symbolic directory link to "C:\Program Files\Haskell Platform\2014.2.0.0\bin". I did this so there would not be spaces in the path because this is causing other issues for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11759> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of *
by GHC 31 Jul '18

31 Jul '18

#12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is premature but what the darn, {{{ >>> :kind Maybe Maybe :: Type -> Type >>> :kind StateT StateT :: Type -> (Type -> Type) -> Type -> Type >>> :kind Eq Eq :: Type -> Constraint >>> :info Functor class Functor (f :: Type -> Type) where ... }}} `*` throws students off and makes it seem scarier than it is. Symbols are harder to search for in general and to understand without documentation, `Type` on the other hand is descriptive. There are valid arguments against displaying `Type`: 1. It's a recent feature subject to change. 2. Although symbols are more difficult to search for, `*` is established in educational materials, logs, blogs and questions. 3. By default `Type` is not in scope so a user cannot ask for information in GHCi. `*` is established and searching for “Haskell asterisk” yields a lot resources but [https://support.google.com/websearch/answer/2466433?hl=en ‘*’ is also a wildcard] in Google and ignored by GitHub. With time `Type` would be a good search term but currently it's chicken-and-the-egg. Previous versions of GHCi error on `:kind *` and `:info *` only shows multiplication so that wouldn't be a huge difference but we can qualify by default: {{{ >>> :kind Maybe Maybe :: Data.Kind.Type -> Data.Kind.Type >>> :kind StateT StateT :: Data.Kind.Type -> (Data.Kind.Type -> Data.Kind.Type) -> Data.Kind.Type -> Data.Kind.Type >>> :kind Eq Eq :: Data.Kind.Type -> Constraint >>> :info Functor class Functor (f :: Data.Kind.Type -> Data.Kind.Type) where ... }}} or display `*` normally and only when `TypeInType` is set do we display `Type`. I don't love it (and love `GHC.Types.Type` slightly less) but there is a precedent for unqualified names, browsing the Prelude for example: {{{#!hs ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b undefined :: forall (r :: GHC.Types.RuntimeRep) (a :: TYPE r). GHC.Stack.Types.HasCallStack => a }}} __If__ the consensus is that this will happen sometime down the line consider that each passing release means many more books and blog posts get written using `*`. I wasn't planning on resulting to scare tactics but [https://www.peoria.com/spaw/spawimages/members/member60763/shoot_this_dog.j… here we are]... ---- If needed a migration plan can be drafted like the Semigroup/FTP/AMP/BBP/MonadFail/expanding Float/... proposals, possibly culminating in `Type` fully replacing `*` and being imported by default. I'm sure there are some further reaching consequences to this and better arguments against. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10056: Inconsistent precedence of ~
by GHC 30 Jul '18

30 Jul '18

#10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following compiles as expected: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family Foo a b f :: (Foo a b ~ Int) => a -> b -> b f = error "" }}} but this fails: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family a \\ b f :: (a \\ b ~ Int) => a -> b -> b f = error "" }}} with the error > "The second argument of `(\\)` should have kind `*`, but `b ~ Int` has kind `Constraint`." Thus the first example is being parsed as `(Foo a b) ~ Int`, while the second is parsed as `a \\ (b ~ Int)`. I believe the second example should compile, i.e. `(\\)` and `Foo` should have the same precedence, both of which are higher than `(~)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42