- ghc-tickets - Haskell.org

Re: [GHC] #5142: stub header files don't work with the MS C compiler
by GHC 08 Aug '18

08 Aug '18

#5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): No, no one is working on this at the moment as far as I know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5142#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15489: TestCoercion should be a superclass of TestEquality
by GHC 08 Aug '18

08 Aug '18

#15489: TestCoercion should be a superclass of TestEquality -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Given that you can implement {{{#!hs testCoercionFromEquality :: TestEquality f => f a -> f b -> Maybe (Coercion a b) testCoercionFromEquality fa fb = fmap repr $ testEquality fa fb }}} that shows the superclass relationship. Are there enough libraries that implement new instances of `TestEquality` that adding this superclass would break? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12421: TestEquality and TestCoercion documentation is confusing
by GHC 08 Aug '18

08 Aug '18

#12421: TestEquality and TestCoercion documentation is confusing -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the documentation for the `TestEquality` class indicates > This class contains types where you can learn the equality of two types from information contained in terms. Typically, only singleton types should inhabit this class. The `TestCoercion` documentation includes a similar caution about singleton types. But this is far too conservative! Length-indexed vectors can be made valid instances of `TestEquality` and `TestCoercion` in exactly one way: {{{#!hs data Nat = Z | S Nat data Vec a n where Nil :: Vec a 'Z Cons :: a -> Vec a n -> Vec a ('S n) instance TestEquality (Vec a) where testEquality Nil Nil = Just Refl testEquality (Cons _ xs) (Cons _ ys) = fmap (\Refl -> Refl) (testEquality xs ys) testEquality _ _ = Nothing instance TestCoercion (Vec a) where testCoercion xs ys = fmap (\Refl -> Coercion) (testEquality xs ys) }}} Polykinded heterogeneous lists are another nice non-singleton example for which each class has a single "most reasonable" instance: {{{#!hs data HList (f :: k -> *) (xs :: [k]) where HNil :: HList f '[] HCons :: f a -> HList f as -> HList f (a ': as) instance TestEquality f => TestEquality (HList f) where testEquality HNil HNil = Just Refl testEquality (HCons x xs) (HCons y ys) = do Refl <- testEquality x y Refl <- testEquality xs ys Just Refl testEquality _ _ = Nothing instance TestCoercion f => TestCoercion (HList f) where testCoercion HNil HNil = Just Coercion testCoercion (HCons x xs) (HCons y ys) = do Coercion <- testCoercion x y Coercion <- testCoercion xs ys Just Coercion testCoercion _ _ = Nothing }}} I don't know just how far the warning should be weakened; it may make sense to go as far as saying the type should generally be a GADT. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12421> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5142: stub header files don't work with the MS C compiler
by GHC 07 Aug '18

07 Aug '18

#5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * owner: simonmar => (none) * cc: Phyx- (added) Comment: Azel: you might want to discuss with @Phyx-, but I don't think anyone is working on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5142#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures.
by GHC 07 Aug '18

07 Aug '18

#15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- This is in context with backpack signatures and their instantiation with concrete implementation. Consider the signature `Abstract` which contains a data `NatType` of kind `Nat`. {{{#!hs {- skipped relevant language extensions -} signature Abstract where import GHC.TypeLits data NatType :: Nat -- comment this out }}} Concrete implementations are unable to instantiate this abstract class during linking {{{#!hs module Concrete where type NatType = 42 }}} This is neither working with explicit .bkp files nor actual cabal package. I have isolated a minimum example into a repository [[https://github.com /piyush-kurur/backpack-nat| a cabal packages]] as well as a [[https://github.com/piyush-kurur/backpack-nat/blob/master/as-bkpfiles /backpack-nat.bkp|single bkp file]]. The urls above also have the associated ghc log messages. The version of ghc I have tested with is 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15468: in ghci -fbreak-on-exception omits exception info
by GHC 07 Aug '18

07 Aug '18

#15468: in ghci -fbreak-on-exception omits exception info -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In ghc 8.4.3 Without -fbreak-on-exception you get a good error message: {{{ ghci -ignore-dot-ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 *** Exception: <interactive>:1:5-13: Non-exhaustive patterns in function + }}} With -fbreak-on-exception there is no info about the exception: {{{ ghci -ignore-dot-ghci -fbreak-on-exception GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 Stopped in <exception thrown>, <unknown> _exception :: e = _ [<unknown>] [<unknown>] Prelude> }}} In addition, contrary to the documentation, it doesn't seem possible to get ghci to print out the value of the exception {{{ <unknown>] [<unknown>] Prelude> :print _exception _exception = (_t1::e) [<unknown>] [<unknown>] Prelude> :info _exception _exception :: e -- Defined in ‘interactive:Ghci3’ [<unknown>] [<unknown>] Prelude> }}} Finally the fact that you get now warning about {{{ let 2 + 2 = 5 }}} or for {{{ 2 = 3 }}} makes me think I should file an ER to add the following to the default warnings for ghci {{{ ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 <interactive>:1:7: warning: [-Wname-shadowing] This binding for ‘+’ shadows the existing binding imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) Prelude> 2 = 3 <interactive>:2:1: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: 2 = 3 Prelude> }}} I noticed the second and when googling to see if it had been reported I came across the following which documented the first: https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- eaadef327146 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #13137: Dynamic linker not initialised.
by GHC 07 Aug '18

07 Aug '18

#13137: Dynamic linker not initialised. ----------------------------------------+--------------------------------- Reporter: djduke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Attempting to build accelerate-llvm-1.0.0.0 cloned from the repo at https://github.com/AccelerateHS/accelerate-llvm, using: OSX 10.12.2 (Sierra) GHC 8.0.2 Command line tools for Xcode 8.2.1 [25 of 52] Compiling Data.Range.Range ( Data/Range/Range.hs, dist/build/Data/Range/Range.o ) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [26 of 52] Compiling Data.Array.Accelerate.LLVM.Util ( Data/Array/Accelerate/LLVM/Util.hs, dist/build/Data/Array/Accelerate/LLVM/Util.o ) <no location info>: error: <command line>: can't load .so/.DLL for: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib (dlopen(/Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib, 5): Symbol not found: __ZTIN4llvm11InstructionE Referenced from: /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx-ghc-8.0.2 /libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib Expected in: flat namespace in /Users/scsdjd/Library/Haskell/ghc-8.0.2-x86_64/lib/x86_64-osx- ghc-8.0.2/libHSllvm-general-3.8.0.0-KHGbcTTSuxFL0az0gf3S53-ghc8.0.2.dylib) [27 of 52] Compiling Data.Array.Accelerate.LLVM.CodeGen.Ptr ( Data/Array/Accelerate/LLVM/CodeGen/Ptr.hs, dist/build/Data/Array/Accelerate/LLVM/CodeGen/Ptr.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ... so I have. I note previous tickets for "Dynamic linker not initialised", but not clear they are relevant due to different OS etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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] #13607: Panic with profiled compiler: Dynamic linker not initialised
by GHC 07 Aug '18

07 Aug '18

#13607: Panic with profiled compiler: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are several Trac tickets floating around which mention this panic, including: * #9868 (ghc: panic! Dynamic linker not initialised) * #10355 (Dynamic linker not initialised) * #10919 (ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised) * #13137 (Dynamic linker not initialised.) * #13531 (GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file) However, none seem particularly simple to reproduce. I have a (marginally) easier way to trigger this panic. You'll need the following: * A copy of GHC HEAD built with the `prof` flavor. For reference, I am using GHC HEAD built against 1f4fd37efac4795493677d5df81c83d22eac5f74. * A single package built with `cabal-install`. For simplicity, I used `random`: {{{ $ cabal install random-1.1 -w ~/Software/ghc3/inplace/bin/ghc-stage2 }}} Once it's installed, you'll need to learn `random`'s package ID, which can be done with `ghc-pkg`. For instance: {{{ 3$ ~/Software/ghc3/inplace/bin/ghc-pkg describe random name: random version: 1.1 id: random-1.1-Gnn89iTXDuaz90MEyLmyr ... }}} * You'll need these three Haskell files: {{{#!hs -- Foo.hs {-# LANGUAGE TemplateHaskell #-} module Foo where import Language.Haskell.TH foo :: Bool foo = $(conE 'True) }}} {{{#!hs -- Foo2.hs {-# LANGUAGE TemplateHaskell #-} module Foo2 where import Language.Haskell.TH foo2 = $(conE 'False) }}} {{{#!hs -- Bar.hs module Bar where import Foo import Foo2 bar :: () bar = foo `seq` foo2 `seq` () }}} Once you have all of these, you can trigger the bug by invoking GHC like so: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 -fforce-recomp Bar.hs -j2 -package-id random-1.1-Gnn89iTXDuaz90MEyLmyr [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) <no location info>: error: <command line>: can't load .so/.DLL for: libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so (libHSrandom-1.1-Gnn89iTXDuaz90MEyLmyr.so: cannot open shared object file: No such file or directory) [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) <no location info>: error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170423 for x86_64-unknown-linux): Dynamic linker not initialised CallStack (from -prof): Linker.CAF (<entire-module>) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In case it's important, this is using 64-bit Linux. cc'ing angerman, who requested an easier way to reproduce this panic in https://ghc.haskell.org/trac/ghc/ticket/13137#comment:6. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13607> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7