May 2016 - ghc-tickets

[GHC] #11941: stage restriction mentioned when an identifier is out of scope
by GHC 25 Aug '16

25 Aug '16

#11941: stage restriction mentioned when an identifier is out of scope -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Data.Monoid const (return []) $ mempty { getFrst = Just () } }}} {{{ typeErrBug.hs:5:21: error: • GHC stage restriction: ‘getFrst’ is used in a top-level splice, quasi-quote, or annotation, and must be imported, not defined locally • In the second argument of ‘($)’, namely ‘mempty {getFrst = Just ()}’ In the expression: const (return []) $ mempty {getFrst = Just ()} typeErrBug.hs:5:30: error: Not in scope: ‘getFrst’ Perhaps you meant one of these: ‘getFirst’ (imported from Data.Monoid), ‘getLast’ (imported from Data.Monoid) }}} The stage restriction error shouldn't be mentioned: `getFrst` isn't defined at all while the "not defined locally" phrase says it's defined (in the wrong spot). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11941> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11947: GHC mistakenly warns about type defaulting in the presence of -XTypeApplications
by GHC 25 Aug '16

25 Aug '16

#11947: GHC mistakenly warns about type defaulting in the presence of -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Main (main) where theFloatDigits :: forall a. RealFloat a => Int theFloatDigits = floatDigits (undefined @_ @a) main :: IO () main = print (theFloatDigits @Double, theFloatDigits @Float) }}} erroneously produces this warning: {{{ $ /opt/ghc/8.0.1/bin/runghc -Wall TheFloatDigits.hs TheFloatDigits.hs:6:19: warning: [-Wtype-defaults] • Defaulting the following constraint to type ‘Double’ RealFloat a0 • In the ambiguity check for ‘theFloatDigits’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: theFloatDigits :: forall a. RealFloat a => Int (53,24) }}} GHC's claim that `a0` was defaulted to `Double` is clearly bogus, since `theFloatDigits` outputs different answers for `Double` and `Float`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[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] #12072: GHC panic on type wildcard in left-hand side of data family
by GHC 25 Aug '16

25 Aug '16

#12072: GHC panic on type wildcard in left-hand side of data family -------------------------------------+------------------------------------- Reporter: andreash | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While playing around with data families I received the following output by ghc/ghci: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): rnHsTyKi HsWildcardTy Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I had accidentally left a wildcard `_` on the left-hand side of a data instance definition. To reproduce enter the following code into a file and try to load that file into ghci, or try to compile it with ghc: {{{#!hs data family Bug x data instance Bug _ = Bug }}} The expected behavior would be a (non-panic) error message of some sort. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #12035: hs-boot knot tying insufficient for ghc --make
by GHC 22 Aug '16

22 Aug '16

#12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC in one-shot mode goes through great pains to make sure that if we are typechecking A.hs with an A.hs-boot, any references to A in the interfaces we load in should point to the `TyThing`s from our LOCAL `tcg_type_env` (`_var`), not the declarations from the `hs-boot`. Indeed, it is never right to load the hi-boot file into the EPS (#10182, #10336). Because in one-shot compilation we are loading things into the EPS anew, there is not much risk of having stale `TyThing`s lying around which still refer to the old `hs-boot` ModDetails. `ghc --make` does not do a sufficient job as knot tying. Specifically, any `Id`s/`TyThing`s from the HPT which were built against the `hs-boot` ModDetails will have out-of-date information. We do manage to tie the knot if we use `tcLookupGlobal` directly, which does look in the local type environment (e.g., #12034 affects both `-c` and `--make`), but if we get our hands on a `TyThing` indirectly, we're in trouble. The case where this is most obvious is unfoldings; see #10083 for an example of GHC behaving differently between `-c` and `--make` (although, ironically, `--make`s bad behavior masks the bug). It's not entirely clear how to fix this problem. In analogy to what happens in `-c`, we should clear the stale `TyThing`s from our HPT and retypecheck them after we have setup the type environment for our `hs` file. But presently in `--make` we don't lazily load types from our home package. Maybe we should! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[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