July 2016 - ghc-tickets

[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] #12371: Error message, room for improvement
by GHC 25 Aug '16

25 Aug '16

#12371: Error message, room for improvement -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XPatternSynonyms Prelude> :set -XViewPatterns Prelude> pattern Foo a <- ((\uncons -> Just (a, as) -> a) -> a) <interactive>:3:20: error: Pattern syntax in expression context: \ uncons -> Just (a, as) -> a Did you mean to enable TypeApplications? }}} Let's: {{{ Prelude> :set -XTypeApplications Prelude> pattern Foo a <- ((\uncons -> Just (a, as) -> a) -> a) <interactive>:5:20: error: Pattern syntax in expression context: \ uncons -> Just (a, as) -> a Did you mean to enable TypeApplications? Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12403: Template Haskell boxes tuple types when reifying them
by GHC 25 Aug '16

25 Aug '16

#12403: Template Haskell boxes tuple types when reifying them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Template | Version: 8.0.1 Haskell | 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: -------------------------------------+------------------------------------- Example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE UnboxedTuples #-} module Main where import Language.Haskell.TH data T = T (# Int, Int #) $(return []) main :: IO () main = putStrLn $(reify ''T >>= stringE . pprint) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc -fforce-recomp Constraints.hs [1 of 1] Compiling Main ( Constraints.hs, Constraints.o ) Linking Constraints ... $ ./Constraints data Main.T = Main.T ((,,,) GHC.Types.Int GHC.Types.Int) }}} Patch coming soon. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12403> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[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] #12165: Multiple pattern type signatures accepted
by GHC 25 Aug '16

25 Aug '16

#12165: Multiple pattern type signatures accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This hogwash is accepted: {{{ pattern P :: a -> b -> Maybe (a,b) pattern P :: foo => bar => blah -> urgh pattern P x y = Just (x, y) }}} A little experimentation shows that only the first pattern signature is examined. Others are accepted and ignored. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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