October 2016 - ghc-tickets

Re: [GHC] #5618: TH cannot splice patterns in declaration quotes
by GHC 12 Oct '16

12 Oct '16

#5618: TH cannot splice patterns in declaration quotes -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): It seems to work in GHC v8.2.x: {{{#!haskell Prelude Language.Haskell.TH> runQ ((\p -> [d| $(p) = 1 |] ) [p| hhh|]) >>= print [ValD (VarP hhh_1) (NormalB (LitE (IntegerL 1))) []] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5618#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12615: Record pattern synonyms cause spurious name shadowing warnings
by GHC 12 Oct '16

12 Oct '16

#12615: Record pattern synonyms cause spurious name shadowing warnings -------------------------------------+------------------------------------- Reporter: gelisam | 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: -------------------------------------+------------------------------------- The example given in the [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts… #record-pattern-synonyms documentation] gives a warning when compiled with `-Wall`: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# OPTIONS_GHC -Wall #-} module Test where -- Test.hs:13:24: warning: [-Wname-shadowing] -- This binding for ‘x’ shadows the existing binding -- defined at Test.hs:13:15 -- -- Test.hs:13:27: warning: [-Wname-shadowing] -- This binding for ‘y’ shadows the existing binding -- defined at Test.hs:13:18 pattern Point :: Int -> Int -> (Int, Int) pattern Point{x, y} = (x, y) }}} I don't see anything being shadowed here, so I don't think GHC should produce these warnings. Also, the type signature for that example in the documentation is `pattern Point :: (Int, Int)`, which doesn't compile. Should I file a separate bug for that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12687: Add a flag to control constraint solving trace
by GHC 12 Oct '16

12 Oct '16

#12687: Add a flag to control constraint solving trace -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are flags to control the typechecking and renaming trace (`-dtrace- tc`, `-dtrace-rn`) but the constraint solver trace can't be controlled in this way. It doesn't seem to always be emitted but it the behaviour should be unified with the other tracing functions. `traceTcS` should be implemented in terms of `traceOptTcRn` and a flag added to control the output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?)
by GHC 12 Oct '16

12 Oct '16

#12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I didn't find a ticket with this, but with wiki:CustomTypeErrors you can't define a type synonym without it erroring: {{{#!hs -- error: … -- • onetwothree -- • In the type synonym declaration for ‘ERROR’ -- Compilation failed. type ERROR = TypeError (Text "onetwothree") }}} but I often want to abstract over error messages since they are clunky to write at the type level and I often use a similar message in many different type families, especially when they can be determined by a type family. Here's a hypothetical example: {{{#!hs type family Whoami (ty :: Type) :: Symbol where Whoami Int = "a number" Whoami Float = "a number" Whoami [_] = "a list of things" Whoami _ = "something else" }}} I would like to write {{{#!hs type Error ty = TypeError (Text "Expected a <...> but got ":<>: Text (Whoami ty)) }}} ---- Even when ‘inlined’, it displays `Expected a GRUE but got 'Text (Whoami Int)` and not `• Expected a GRUE but got a number.`: {{{#!hs a :: TypeError (Text "Expected a GRUE but got ":<>: Text (Whoami Int)) a = 'a' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12574: Consistent use of sigs vs signatures in warnings
by GHC 11 Oct '16

11 Oct '16

#12574: Consistent use of sigs vs signatures in warnings -------------------------------------+------------------------------------- Reporter: crockeea | 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: 11583 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I have a polymorphic local binding without a type signature, `-Weverything` complains: {{{ warning: [-Wmissing-local-sigs] Polymorphic local binding with no type signature: ... }}} However, when I add `-Wno-missing-local-sigs`, I immediately get a deprecation warning ` -Wno-missing-local-sigs is deprecated: it is replaced by -Wmissing- local-signatures` First, the warning with `-Weveryting` should use the non-depricated `signatures` version. Second, the deprecation warning should probably respect my use of `no`: `-Wno-missing-local-sigs` is replaced by `-Wno- missing-local-signatures`, not `-Wmissing-local-signatures`. Obviously, check for similar cases with the other "sigs" options mentioned in #11583. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 11 Oct '16

11 Oct '16

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10458: GHCi fails to load shared object (the 'impossible' happened)
by GHC 10 Oct '16

10 Oct '16

#10458: GHCi fails to load shared object (the 'impossible' happened) -----------------------------------------+--------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I have a project that uses two external libraries, namely `-lcrypt` and `-lpcre`. Building with `cabal` and running the resulting executable works as expected, but I'm having trouble starting a REPL in GHCi: {{{ % cabal repl Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help /usr/bin/ld: dist/build/etamoo/etamoo-tmp/src/cbits/crypt.o: relocation R_X86_64_PC32 against undefined symbol `crypt' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status }}} The error suggests I need `-fPIC`, and this seems to help the `-lcrypt` case, but now I get: {{{ % cabal repl --ghc-options="-fPIC" Preprocessing executable 'etamoo' for EtaMOO-0.2.1.0... GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc21539_0/libghc21539_2.so: undefined symbol: pcre_callout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} FYI the C type of `pcre_callout` is a little unusual: {{{ extern int (*pcre_callout)(pcre_callout_block *); }}} In other words it is a global variable (pointer to function), not a function itself. Any advice is welcome, including the proper way to start GHCi given these external dependencies, as well as on this apparent bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10458> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #12684: GHC panic due to bindnow linker flag
by GHC 10 Oct '16

10 Oct '16

#12684: GHC panic due to bindnow linker flag -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: 11238 Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As [https://ghc.haskell.org/trac/ghc/ticket/10458#comment:45 explained in #10458] our `haskell-opencv` library failed to build on NixOS-16.09 due to its recently introduced [https://nixos.org/nixpkgs/manual/#sec-hardening- in-nixpkgs hardening features]. Specifically the problem is that NixOS is setting the `-z bindnow` linker flag which causes the build to fail with: {{{ ... [33 of 64] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o ) <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1001/ghc8697_0/libghc_200.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa }}} Fortunately this flag can be [https://github.com/LumiGuide/haskell- opencv/commit/5ea490af7662fe74b3740619963d37f1fd91e3d4 disabled] so I'm now able to build the library successfully. However, it would be nice if GHC is able to work around this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12559: Don't ignore addTopDecls in addModFinalizer
by GHC 10 Oct '16

10 Oct '16

#12559: Don't ignore addTopDecls in addModFinalizer -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: template- | Operating System: Unknown/Multiple haskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11832 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program fails to compile because `f` is not found. {{{ -- main.hs import M main = print (f 0) }}} {{{ -- M.hs {-# LANGUAGE TemplateHaskell #-} module M where import Language.Haskell.TH.Syntax g :: IO () g = $(do addModFinalizer (do d <- [d| f x = (2 :: Int) |]; addTopDecls d) [| return ()|] ) }}} {{{ $ runghc main.hs main.hs:3:15: Not in scope: ‘f’ }}} This bug is problematic to produce top-level declarations which depend on the output of `reify` for local variables, which can only run in `addModFinalizer`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12672: Missing lambda in third monad law description
by GHC 10 Oct '16

10 Oct '16

#12672: Missing lambda in third monad law description -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Keywords: documentation | Operating System: Unknown/Multiple monad | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Control.Monad` documentation is missing the lambda in the documentation for the third monad law because it is not escaped with an additional `\`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8