March 2017 - ghc-tickets

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 26 Mar '17

26 Mar '17

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3382 Phab:D3383 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13484: Incorrect Exhaustivity Checking
by GHC 26 Mar '17

26 Mar '17

#13484: Incorrect Exhaustivity Checking -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- Small example: {{{ {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# OPTIONS_GHC -Werror -fwarn-incomplete-patterns #-} data Chunk (f :: k -> *) (xs :: [k]) where ChunkCons :: f a -> f b -> f c -> f d -> Chunk f xs -> Chunk f (a ': b ': c ': d ': xs) ChunkNil :: Chunk f '[] impossibleChunk01 :: Chunk f as -> Chunk f (a ': as) -> b impossibleChunk01 (ChunkCons _ _ _ _ c1) (ChunkCons _ _ _ _ c2) = impossibleChunk01 c1 c2 }}} This fails with: {{{ fast_records.hs:32:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘impossibleChunk01’: Patterns not matched: ChunkNil _ }}} Obviously a Chunk and a Chunk that's one element bigger cannot both exist. They must each be a multiple of 4. The impossibleChunk01 function is supposed to prove this. However, GHC doesn't currently figure out that neither data constructor can pair up with ChunkNil. This may be a moot point. The EmptyCase extension is currently sort of broken (because it currently never warns), but in GHC 8.2, it does some exhaustivity checking to ensure that you aren't shooting yourself in the foot. So, I might be able to write: {{{ impossibleChunk01 :: Chunk f as -> Chunk f (a ': as) -> b impossibleChunk01 (ChunkCons _ _ _ _ c1) (ChunkCons _ _ _ _ c2) = impossibleChunk01 c1 c2 impossibleChunk01 ChunkNill x = case x of {} }}} If that's the case (no pun intended), then I don't mind having to manually help out the exhaustivity checker in that way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13485: Doesn't warn about variable not in scope
by GHC 25 Mar '17

25 Mar '17

#13485: Doesn't warn about variable not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running this works fine {{{#!hs {-# Language GADTs, TypeFamilies, InstanceSigs #-} data FunC a where (:$) :: FunC (a -> b) -> FunC a -> FunC b Lam :: (FunC a -> FunC b) -> FunC (a -> b) Add :: Num a => FunC (a -> a -> a) class Syntactic a where type Internal a toFunC :: a -> FunC (Internal a) fromFunC :: FunC (Internal a) -> a instance Syntactic (FunC a) where type Internal (FunC a) = a toFunC, fromFunC :: FunC a -> FunC a toFunC ast = ast fromFunC ast = ast instance (Syntactic a, Syntactic b) => Syntactic (a -> b) where type Internal (a -> b) = Internal a -> Internal b toFunC :: (a -> b) -> FunC (Internal a -> Internal b) toFunC f = Lam (toFunC . f . fromFunC) fromFunC :: FunC (Internal a -> Internal b) -> (a -> b) fromFunC f = fromFunC . (f :$) . toFunC add :: Num a => FunC a -> FunC a -> FunC a add = fromFunC Add }}} A folklore for infix expressions is writing `expr a b` as `a &expr$ b`, if I try that '''without''' importing `(Data.Function.&)` I get {{{#!hs -- tghl.hs:29:23-25: error: … -- • Couldn't match type ‘Internal t0’ with ‘a0 -> a0 -> a0’ -- Expected type: FunC (Internal t0) -- Actual type: FunC (a0 -> a0 -> a0) -- The type variables ‘t0’, ‘a0’ are ambiguous -- • In the first argument of ‘fromFunC’, namely ‘Add’ -- In the second argument of ‘(&)’, namely ‘fromFunC Add’ -- In the expression: (&) a fromFunC Add add :: Num a => FunC a -> FunC a -> FunC a add a b = a &fromFunC Add$ b }}} I would expect a `Variable not in scope: (&)` error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13485> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13483: Can't allocate thunk for wcslen
by GHC 25 Mar '17

25 Mar '17

#13483: Can't allocate thunk for wcslen -------------------------------------+------------------------------------- Reporter: NickSeagull | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (FFI) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I'm trying to use the [https://sourceforge.net/projects/tinyfiledialogs tinyfiledialogs] library through the FFI, I've put the .h and .c files in a folder called "foreign" in the root of my project and configured cabal so it looks in this folder. The code for calling this function is as: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Escri where import Foreign.C.String foreign import ccall "tinyfiledialogs.h tinyfd_messageBox" c_messageBox :: CString -> CString -> CString -> CString -> Int -> IO Int messageBox :: String -> String -> String -> String -> Int -> IO Bool messageBox title message dialogType iconType defaultButton = do cTitle <- newCString title cMessage <- newCString message cDialogType <- newCString dialogType cIconType <- newCString iconType result <- c_messageBox cTitle cMessage cDialogType cIconType defaultButton return (result == 1) }}} When trying to run GHCi for this project, I get the following error {{{ Configuring GHCi with the following packages: escri GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc.EXE: internal error: Can't allocate thunk for wcslen (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} This only happens in Windows. In OSX I just get a linker error. If I try to make a call with stdcall, it tells: {{{ C:\Users\Nick\Development\escri\src\Escri.hs:6:1: warning: [-Wunsupported- calling-conventions] * the 'stdcall' calling convention is unsupported on this platform, treating as ccall * When checking declaration: foreign import stdcall safe "static tinyfiledialogs.h tinyfd_messageBox" c_messageBox :: CString -> CString -> CString -> CString -> Int -> IO Int }}} Which is strange, because I'm on Windows. Thanks in advance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13476: Coercion maching in RULES is fragile
by GHC 25 Mar '17

25 Mar '17

#13476: Coercion maching in RULES is fragile -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- If we have a cast or coercion in the LHS of a rule, matching against is is very fragile. This came up in #13474. Consider the `map/coerce` rule in `GHC.Base`. (There is a similar one in `containers:Data.Map.Internal`.) Initially it looks like this: {{{ RULE "map/coerce" forall a b (x::a) (c::a~b) (xs::[a]). map (\x. x |> c) xs = xs |> [c] }}} In typechecking and desugaring rules we are careful only to use coercion ''variables'' in a cast on the LHS, so that matching is more likely to succeed. After all, we never want to match on ''the way a proof is done'', only on the ''result of the proof''. However, suppose some target expression (to which we would like to apply the rule) looks like {{{ map (\(y::ty). y |> ec) exs }}} The simplifier (see `Note [Casts and lambdas]` in `SimplUtils`) swizzles the cast outside the lambda, thus {{{ map ((\ (y::ty). y) |> (<ty> -> ec)) exs }}} Now it's not so easy to match the rule, becuase in one the cast is outside the lambda and in the other it is inside. The casts are making matching fragile. What to do? == Plan A (current) == Currently, we run the simplifier on the rule LHS, so that the same simplifications apply. But now we get {{{ RULE "map/coerce" forall a b (x::a) (c::a~b) (xs::[a]). map ((\x. x) |> (<a> -> c) xs = xs |> [c] }}} And now the coercion on the LHS has structure; ''and'' we must decompose that structure to bind the `c` to use it on the RHS. So `Rules.match_co` actually matches the structure of coercions (sigh); but is only partially implemented (a) because it is tedious and (b) because it should not be necessary. Pragmatic but unsatisfactory. == Plan B (possible) == Do not simplify the LHS of rules, so that casts always have a simple coercion variable. But make matching work "modulo casts". Something like this: {{{ match :: PatternExpr -> TargetExpr -> Coercion -> ...result... -- Invariant: match pat e c == match pat (e |> c) Refl -- That is, the coercion wraps the TargetExpr }}} Now when we find a cast in the target expr we can push it into the coercion {{{ match pat (Cast e c1) c2 = match pat e1 (c1 ; c2) }}} And a cast in the pattern just binds the variable {{{ match (Cast p v) e c = match p e Refl + {v :-> c} }}} This isn't quite right because we must make sure the types match, but it's close. The decomposition rules become more interesting: {{{ match (\x.p) (\x.e) c = match p e[x -> x |> arg_co] res_co where (arg_co, res_co) = decomposeFunCo c }}} or something like that. In effect we do the swizzling on the fly. This is all similar to the coercion swizzling in `Unify` when unifying types. I cannot fathom all the details and I'm not sure it's worth the work. But somehow it ought to be possible to make casts NOT impede matching in a systematic way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13476> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13425: Semantically-equivalent expressions evaluating at different values with -O1
by GHC 24 Mar '17

24 Mar '17

#13425: Semantically-equivalent expressions evaluating at different values with -O1 -------------------------------------+------------------------------------- Reporter: rbasso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- The following code shows inconsistent results when compiled with -O1: {{{#!hs import Data.Bits ((.&.)) flags :: Int -> [Int] flags x = filter (\y -> x .&. y > 0) [1, 128, 129, 255] main :: IO () main = do putStrLn $ show $ flags $ 255 -- These lines should display putStrLn (show (flags 255)) -- the same value, right? -- It appears that this is related to something that started -- with GHC 7.10, but was also changed in GHC 8.0, as we can -- see from the following tests: -- -- Stack snapshot lts-0.7 (GHC 7.8.3), with -O2 -- [1,128,129,255] -- [1,128,129,255] -- -- Stack snapshot lts-2.22 (GHC 7.8.4) with -O2 -- [1,128,129,255] -- [1,128,129,255] -- -- Stack snapshot lts-3.22 (GHC 7.10.2) with -O2 -- [1] -- [1] -- -- Stack snapshot lts-6.30 (GHC 7.10.3) with -O2 -- [1] -- [1] -- -- Stack snapshot lts-7.20 (GHC 8.0.1) with -O2 -- [1] -- [1,128,129,255] -- -- Stack snapshot lts-8.5 (GHC 8.0.2) with -O2 -- [1] -- [1,128,129,255] -- -- In GHC 8.0.2, compiling with any of the following... -- -O0 -- -O2 -fno-cmm-sink -- -O2 -fno-enable-rewrite-rules -- -- ...we get the expected results: -- [1,128,129,255] -- [1,128,129,255] -- -- Using only -O1, we get the abnormal behavior again: -- [1] -- [1,128,129,255] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13425> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13444: Disable diagnostic coloring by default
by GHC 24 Mar '17

24 Mar '17

#13444: Disable diagnostic coloring by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- TO my suprise, GHC 8.2.1 enables colors by default which is rather annoying to me as it looks rather ugly with my terminal coloring scheme. This should follow GCC's model instead which defaults them off and allows to customize the coloring scheme via `GCC_COLORS`. Quoting the GCC man- page: > `-fdiagnostics-color[=WHEN]` > `-fno-diagnostics-color` > > Use color in diagnostics. WHEN is never, always, or auto. The default depends on how > the compiler has been configured, it can be any of the above WHEN options or also never > if GCC_COLORS environment variable isn't present in the environment, and auto > otherwise. auto means to use color only when the standard error is a terminal. The > forms -fdiagnostics-color and -fno-diagnostics-color are aliases for > `-fdiagnostics-color=always` and `-fdiagnostics-color=never`, respectively. > > The colors are defined by the environment variable `GCC_COLORS`. Its value is a colon- > separated list of capabilities and Select Graphic Rendition (SGR) substrings. SGR > commands are interpreted by the terminal or terminal emulator. (See the section in the > documentation of your text terminal for permitted values and their meanings as > character attributes.) These substring values are integers in decimal representation > and can be concatenated with semicolons. Common values to concatenate include 1 for > bold, 4 for underline, 5 for blink, 7 for inverse, 39 for default foreground color, 30 > to 37 for foreground colors, 90 to 97 for 16-color mode foreground colors, 38;5;0 to > 38;5;255 for 88-color and 256-color modes foreground colors, 49 for default background > color, 40 to 47 for background colors, 100 to 107 for 16-color mode background colors, > and 48;5;0 to 48;5;255 for 88-color and 256-color modes background colors. > > The default `GCC_COLORS` is > > `error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01` > > where 01;31 is bold red, 01;35 is bold magenta, 01;36 is bold cyan, 01;32 is bold green > and 01 is bold. Setting GCC_COLORS to the empty string disables colors. Supported > capabilities are as follows. > > "error=" > SGR substring for error: markers. > > "warning=" > SGR substring for warning: markers. > > "note=" > SGR substring for note: markers. > > "caret=" > SGR substring for caret line. > > "locus=" > SGR substring for location information, file:line or file:line:column etc. > > "quote=" > SGR substring for information printed within quotes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13457: unsafeInterleaveST is too unsafe
by GHC 24 Mar '17

24 Mar '17

#13457: unsafeInterleaveST is too unsafe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- Several years ago, Edward Kmett wrote a [https://www.schoolofhaskell.com/school/to-infinity-and-beyond/older-but- still-interesting/deamortized-st#newsflash--unsafeinterleavest-is-unsafe- blog post] that (among other things) explains that `unsafeInterleaveST` is not thread-safe; actions may be performed multiple times. The fix that would seem to match everything else best would be to rename `unsafeInterleaveST` to `unsafeDupableInterleaveST` and define `unsafeInterleaveST m = unsafeDupableInterleaveST (noDuplicate >> m)` using an `ST`ish version of `noDuplicate`. As Kmett explains, the dupable version is useful for high performance when the suspended action is known to be idempotent. Actually, the action being idempotent is insufficient, but I believe a sufficient condition is that the action does not both read and write any reference or array element. While we're at it, we need to document all the functions in `Control.Monad.ST.Unsafe`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13445: Fix 32 bit Windows build of GHC 8.2
by GHC 23 Mar '17

23 Mar '17

#13445: Fix 32 bit Windows build of GHC 8.2 --------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: #13431 Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Current head is broken due to some `-Werr` failures and a bug in `x86 mingw-w64` distribution. See #13431 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13475: Possible missing case in ghc-pkg
by GHC 23 Mar '17

23 Mar '17

#13475: Possible missing case in ghc-pkg -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.1 system | 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: -------------------------------------+------------------------------------- I saw this while compiling {{{ utils\ghc-pkg\Main.hs:761:25: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: GhcPkg.DbOpenReadOnly }}} I don't know if this is indicative of a bug in the implementation or not? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0