May 2017 - ghc-tickets

[GHC] #8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character)
by GHC 10 Apr '18

10 Apr '18

#8118: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) ----------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: OpenBSD Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I get the following error... {{{ <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) }}} When running following program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import qualified Data.Text.IO as T main = T.putStrLn "čušpajž日本語" }}} Was tested in #haskell and I have all the UTF-8 Settings set and so forth. It compiles just fine, but crashes during runtime. gcc -v: {{{ Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd5.4/4.2.1/specs Target: amd64-unknown-openbsd5.4 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10424: Build path leaks into ABI hashes
by GHC 09 Apr '18

09 Apr '18

#10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The build path of GHC leaks into the ABI hashes, i.e. if you build GHC in /tmp/fooADDF and then in /tmp/fooSDFS, you get different ABI hashes. This is a serious problem for distributions, as it means that we cannot rebuild the GHC package without rebuilding all Haskell packages as well. The (or at least one) problem is include paths. We have {{{ include-dirs: /home/jojo/build/haskell/ghc/rts/dist/build /home/jojo/build/haskell/ghc/includes /home/jojo/build/haskell/ghc/includes/dist- derivedconstants/header }}} in `inplace/lib/package.conf.d/builtin_rts.conf`, so when running the preprocessor, GHC passes this full path to the preprocessor: {{{ /usr/bin/gcc -E -undef -traditional -DOPTIMISE_INTEGER_GCD_LCM -include libraries/base/dist-install/build/autogen/cabal_macros.h -I libraries/base /dist-install/build -I libraries/base/dist-install/build -I libraries/base /dist-install/build/autogen -I libraries/base/include -I /home/jojo/build/haskell/ghc/libraries/integer-gmp/include -I /home/jojo/build/haskell/ghc/rts/dist/build -I /home/jojo/build/haskell/ghc/includes -I /home/jojo/build/haskell/ghc/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=711' -include /home/jojo/build/haskell/ghc/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' '-D__SSE__=1' '-D__SSE2__=1' -x assembler- with-cpp libraries/base/System/Info.hs -o /tmp/ghc14804_0/ghc14804_1.hscpp }}} It then reads the included files from the `hscpp` file : {{{ $ grep home /tmp/ghc14830_0/ghc14830_1.hscpp # 1 "/home/jojo/build/haskell/ghc/includes/ghcversion.h" 1 # 1 "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" 1 }}} and puts it into the interface, where it becomes part of the hash: {{{ $ ./inplace/bin/ghc-stage1 --show-iface ./libraries/base/dist- install/build/System/Info.hi |grep Dep addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcplatform.h" addDependentFile "/home/jojo/build/haskell/ghc/includes/ghcversion.h" addDependentFile "libraries/base/dist- install/build/autogen/cabal_macros.h" addDependentFile "/usr/include/stdc-predef.h" }}} Clearly, the end result is undesirable (changing hashes due to path names) and actually useless, as the build path will not be there later anyways. I’m not sure what the best way to fix this is. Here are a few ideas: * Do not include the path of `addDependentFile` entries in the hash, but only the file hash. Should solve the ABI hash. * Use relative paths in `inplace/lib/package.conf.d/builtin_rts.conf`. Not sure what breaks. This bug appeared in 7.8.4 and is present in both 7.10 and current HEAD. Any other ideas? (Debian bugreport at http://bugs.debian.org/785282) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h
by GHC 07 Apr '18

07 Apr '18

#12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | 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: #12846 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Public symbols that we export in the public headers (rooted from Rts.h) need to be added to the symbols table of the RTS. We currently do this by hand but the list can quickly grow out of sync. Investigate a way to automate either the inclusion or a check during build time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12891> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #11815: Data.List: Add a function to get consecutive elements (mapConsecutives)
by GHC 06 Apr '18

06 Apr '18

#11815: Data.List: Add a function to get consecutive elements (mapConsecutives) -------------------------------------+------------------------------------- Reporter: holmisen | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- A recurring pattern is to get a list of all consecutive elements of a list, for further processing. I propose adding the following function to `Data.List` for this: {{{ mapConsecutives :: (a -> a -> b) -> [a] -> [b] mapConsecutives _ [] = [] mapConsecutives f xs = zipWith f xs (tail xs) }}} Since it requires pattern matching, to separate the empty case, it is not practical to inline at each use site. Sidenote: A similar function `mapAdjacent` is available in the `utility- ht` library (with a partial implementation(!)) [1]. I realise that `Data.List` is often imported unqualified and hence additions may cause trouble. I would have raised this on the libraries mailing list first, but the guidelines for proposals pointed me here. [1] http://hackage.haskell.org/package/utility-ht-0.0.11/docs/Data-List- HT.html#v:mapAdjacent -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11815> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12949: Pattern coverage mistake
by GHC 06 Apr '18

06 Apr '18

#12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- I disabled syntax highlighting below; the bugs highlighting single quotes made the code unreadable. {{{ {-# LANGUAGE DataKinds, TypeFamilies, GADTs, TypeOperators, ScopedTypeVariables, ConstraintKinds, StandaloneDeriving #-} {-# OPTIONS_GHC -Wall #-} import Data.Constraint import Data.Type.Bool -- Bool singletons data Boolly b where Falsey :: Boolly 'False Truey :: Boolly 'True deriving instance Show (Boolly b) class KnownBool b where knownBool :: Boolly b instance KnownBool 'False where knownBool = Falsey instance KnownBool 'True where knownBool = Truey -- OrRel a b r expresses all the usual implications inherent -- in the statement that r ~ (a || b). type OrRel (a :: Bool) (b :: Bool) (r :: Bool) :: Constraint = (r ~ (a || b), If r (If (Not a) (b ~ 'True) (() :: Constraint), If (Not b) (a ~ 'True) (() :: Constraint)) (a ~ 'False, b ~ 'False)) -- Given known Bools, their disjunction is also known abr :: forall a b r p1 p2 . (OrRel a b r, KnownBool a, KnownBool b) => p1 a -> p2 b -> Dict (KnownBool r) abr _ _ = case knownBool :: Boolly a of Truey -> Dict Falsey -> case knownBool :: Boolly b of Truey -> Dict -- Problematic match Falsey -> Dict }}} The trouble is that GHC warns that the problematic match is redundant, which it is not. If I remove it, GHC ''fails'' to warn that the patterns are incomplete, which they are. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12938: Polykinded associated type family rejected on false pretenses
by GHC 04 Apr '18

04 Apr '18

#12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: TypeInType | 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 I say {{{ class HasRep a where type Rep a :: TYPE r }}} I get {{{ • Kind variable ‘r’ is implicitly bound in datatype ‘Rep’, 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: a • In the class declaration for ‘HasRep’ }}} This definition should be accepted, though, as `r` is just an invisible parameter to the associated type family. (I don't know how ''useful'' this is, but it's not bogus.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12742: Instantiation of invisible type family arguments is too eager
by GHC 04 Apr '18

04 Apr '18

#12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- This module looks, to me, like it should be accepted: {{{ {-# LANGUAGE TypeInType, RankNTypes, TypeFamilies #-} module Bug where import Data.Kind type family F :: forall k2. (k1, k2) data T :: (forall k2. (Bool, k2)) -> Type type S = T F }}} But it's not. The problem is that `TcHsType.handle_tyfams` eagerly instantiates ''all'' invisible arguments to a type family at every occurrence. Instead, it should instantiate only those that are counted in the TF's arity -- that is, those "before the colon". Will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13330: forkIO has inconsistent behavior under optimization
by GHC 04 Apr '18

04 Apr '18

#13330: forkIO has inconsistent behavior under optimization -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Troubleshooting the T4030 failure in SimonPJ's early-inline branch, Reid and I discovered that the problem showed up when the argument to `forkIO` was obviously bottom. He came up with a tiny test case that fails without Simon's changes: {{{#!hs main = forkIO undefined >> threadDelay 1000000 }}} It looks like the trouble is in the definition of `forkIO`: {{{#!hs forkIO :: IO () -> IO ThreadId forkIO action = IO $ \ s -> case (fork# action_plus s) of (# s1, tid #) -> (# s1, ThreadId tid #) where action_plus = catchException action childHandler }}} This seems to run into the trouble with `catchException` and strictness explained in `GHC.IO`. It would appear that the conservative fix would be to replace `catchException` with `catch`. Personally, I find it a bit surprising that `forkIO` doesn't force its `IO` argument before forking, but changing that behavior could break working code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13330> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10016: UNPACK support for existentials
by GHC 03 Apr '18

03 Apr '18

#10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ data Foo = forall a. Show a => Foo !a !a data Bar = Bar {-# UNPACK #-} !Foo }}} The UNPACK pragma should really be able to unpack the `Foo` field, so that (implementation-wise) it would be as if you'd declared `Bar` thus: {{{ data Bar = forall a. Show a => Bar !a !a }}} But currently we get {{{ Ignoring unusable UNPACK pragma on the first argument of ‘Bar’ }}} Suggested by Nicholas Clarke [https://www.haskell.org/pipermail/glasgow- haskell-users/2015-January/025590.html here]. Vaguely related tickets: #7647, #9214. But unlike those ones, this one looks quite feasible to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11186: Give strong preference to type variable names in scope when reporting hole contexts
by GHC 02 Apr '18

02 Apr '18

#11186: Give strong preference to type variable names in scope when reporting hole contexts -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: typed-holes | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using `ScopedTypeVariables` with typed holes, I want GHC to bend over backwards to preserve the names of type variables that the user has chosen to bring into scope. I can't immediately reproduce the situations I've run into recently where that hasn't happened, but sometimes I've had a signature like {{{#!hs foo :: forall bar . ... foo = ... _ ... }}} and yet the typed hole message shows that `bar` has been lost in unification and replaced by some unrelated name. I would very much prefer if this never happened. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11186> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9