March 2016 - ghc-tickets

[GHC] #11484: Type synonym using -XTypeInType can't be spliced with TH
by GHC 25 Aug '16

25 Aug '16

#11484: Type synonym using -XTypeInType can't be spliced with TH -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc1 Haskell | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -ddump-splices #-} module Foo where import Data.Kind type TySyn (k :: *) (a :: k) = () -- $([d| type TySyn2 (k :: *) (a :: k) = () |]) }}} But uncomment the last line, and it doesn't compile: {{{ $ /opt/ghc/head/bin/ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:10:3-43: Splicing declarations [d| type TySyn2_aBH (k_aBI :: *) (a_aBJ :: k_aBI) = () |] ======> type TySyn2_a4BF (k_a4BG :: Type) (a_a4BH :: k_a4BG) = () Foo.hs:10:3: error: • Couldn't match expected kind ‘GHC.Prim.Any’ with actual kind ‘k1’ • In the type declaration for ‘TySyn2’ Foo.hs:10:3: error: • Kind variable ‘k_a4BG’ is implicitly bound in datatype ‘TySyn2’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: k_a4BG (a_a4BH :: GHC.Prim.Any) • In the type declaration for ‘TySyn2’ }}} There are two issues here: 1. The error message claims that `TySyn2` is a datatype when it is actually a type synonym. This should be easy enough to fix; just change [http://git.haskell.org/ghc.git/blob/89bdac7635e6ed08927d760aa885d3e7ef3edb8… the code] that throws the error message to invoke [http://git.haskell.org/ghc.git/blob/89bdac7635e6ed08927d760aa885d3e7ef3edb8… tyConFlavour]. 2. For some reason, the type variable `a` in `TySyn2` fails to kind-check. Somehow, an `Any` got in there, but I'm not sure where it snuck in. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows
by GHC 25 Aug '16

25 Aug '16

#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is adapted from the comments [https://github.com/bos/text- icu/issues/12#issuecomment-154452774 here].) On Windows, the GHC runtime linker only searches for DLLs that have the same names as the import libraries passed to `-l`. This can sometimes create problems, since a library name could be different from the DLL it needs. `text-icu` provides an example of this, since it needs the extra libraries `icuuc`, `icudt`, and `icuin`. However, if you download the [http://site .icu-project.org/download/56#TOC-ICU4C-Download official ICU 56 binaries], they are distributed with DLLs named `icuuc56.dll`, `icudt56.dll`, and `icuin56.dll`, rather than `icuuc.dll`, `icudt.dll`, and `icuin.dll`. This doesn't create any trouble for the linker at compile-time. In fact, if you compile this program {{{#!hs -- TextICU.hs import Data.Text.ICU.Break main = print Kana }}} with `ghc TextICU.hs` and then run `cygcheck ./TextICU.hs` without having the ICU4C `bin64` folder in your `PATH`, it ''appears'' to search for the right DLLs: {{{ $ cygcheck ./TextICU.hs ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll }}} But actually running the code reveals a different story: {{{ $ runghc TextICU.hs TextICU.hs: icuuc: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc.dll (addDLL: could not load DLL) }}} This demonstrates that the runtime linker behaves differently; it is dependent on what the linked libraries' names are. To confirm this, you can recompile `text-icu` with the following changes to `text-icu.cabal`: {{{ extra-libraries: icuuc56 if os(mingw32) extra-libraries: icuin56 icudt56 }}} Also make symlinks named `icuuc56.lib`, `icuin56.lib`, and `icudt56.lib` that refer to `icuuc.lib`, `icuin.lib`, and `licudt.lib`, respectively, in the ICU4C `lib64` directory. Now `cygcheck` and `ghc` agree on which DLLs to use: {{{ $ ghc TextICU.hs $ cygcheck ./TextICU.exe ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll $ runghc TextICU.hs TextICU.hs: icuuc56: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc56.dll (addDLL: could not load DLL) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11466: Constraint synonym with Implicit Parameter
by GHC 23 Aug '16

23 Aug '16

#11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: {{{ {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module Foo where type Foo = ?foo::() }}} gives {{{ Foo.hs:3:1: error: • Illegal implicit parameter ‘?foo::()’ • In the type synonym declaration for ‘Foo’ }}} in GHC HEAD. It used to work in GHC-7.10. Did not check GHC-8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11466> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11068: Make Generic/Generic1 methods inlinable
by GHC 23 Aug '16

23 Aug '16

#11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D1447 | Wiki Page: -------------------------------------+------------------------------------- Efficient code generation with GHC.Generics relies on the optimizer being able to completely remove the generic representation of a type. Marking these methods as inlinable ensures that this will be possible even for larger types. I'm working on techniques for transforming generically derived lenses and traversals which rely on taking advantage of the Functor and Applicative laws. This patch supports that work. https://github.com/glguy/generic-traverse -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11702: Constant folding on 'mod/Word' - incorrect result
by GHC 23 Aug '16

23 Aug '16

#11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this with GHC 7.10.3 on both MacOS and Linux with '-O' producess results '5 0'. {{{#!hs module Main where testfn :: Word -> IO () testfn wseq = do print $ wseq `mod` 1 main = do testfn 5 print $ (5 :: Word) `mod` 1 }}} Changing type to Int produces correct result. It has probably something to do with compiler/prelude/PrelRules.hs - the rules for Int and Word differ. It seems to me that it should be optimized the same way, but the culprit seems to be the 'rightIdentityDynFlags onew' - that seems to be a clear bug (if it does what I think it does). {{{#!hs primOpRules nm IntRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (intOp2 rem) , leftZero zeroi , do l <- getLiteral 1 dflags <- getDynFlags guard (l == onei dflags) retLit zeroi , equalArgs >> retLit zeroi , equalArgs >> retLit zeroi ] primOpRules nm WordRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (wordOp2 rem) , rightIdentityDynFlags onew ] }}} I found it in different code where lots of inlining reduced some branch of code into this and produced wrong result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8955: Syscall intrinsic
by GHC 18 Aug '16

18 Aug '16

#8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11385: Unify named wildcards in different type applications
by GHC 16 Aug '16

16 Aug '16

#11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple NamedWildCards TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ([https://www.reddit.com/r/haskell/comments/4030lv/unifying_distinct_type_var… motivating post]) I would like to use type application to specialize {{{#!hs Sub :: forall (a :: Constraint) (b :: Constraint). (a => Dict b) -> a :- b Sub @(Ord _a) @(Eq _a) :: forall {a}. (Ord a => Dict (Eq a)) -> Ord a :- Eq a }}} and {{{#!hs map :: forall a b. (a -> b) -> [a] -> [b] map @_a @_a :: forall {a}. (a -> a) -> [a] -> [a] }}} Is there a fundamental reason why named wildcards are not allowed to unify between type applications within the same expression? [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #named-wildcards Documentation]: > These are called named wildcards. All occurrences of the same named wildcard within one type signature will unify to the same type. I don't know if this is intended. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9498: GHC links against unversioned .so files
by GHC 16 Aug '16

16 Aug '16

#9498: GHC links against unversioned .so files ------------------------------------+-------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Keywords: Debian | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+-------------------------------- Greetings, GHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3). This is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones. This means FFI libraries depend on the -dev packages, even though they don't really need them. It would be nice if GHC would try to load the versioned libraries as well. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11646: Make pattern synonym export type mismatch a warning
by GHC 11 Aug '16

11 Aug '16

#11646: Make pattern synonym export type mismatch a warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As I understand it, attempting to associate a pattern synonym with a type constructor that it "obviously" doesn't match is an error. This is strange for two reasons: 1. An "erroneous" association cannot compromise type safety. 2. The test is incomplete. Therefore, I believe such mismatches should lead to warnings instead of errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10106: GHC doesn't warn on typos in language pragmas
by GHC 11 Aug '16

11 Aug '16

#10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In particular, I was struggling with the QuasiQuotes language extension. I had - {{{#!hs {-# LANGAUGE QuasiQuotes #-} site = [shamelet|Hello World!|] }}} Notice the transposed A and U in `LANGUAGE` The error that ghc was emitting was - `Main.hs:23:47: parse error on input ‘]’` It took me a long time and a lot of head-banging to figure out that it was a typo in the language pragma, especially because the language pragma was surrounded by other language pragmas and it was at the top of the file. I would think that this should at least emit a warning when there is a typo in a pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7