February 2019 - ghc-tickets

[GHC] #14671: Make the Template Haskell class Lift work over typed expressions
by GHC 04 Mar '19

04 Mar '19

#14671: Make the Template Haskell class Lift work over typed expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment we have the `Lift` class in TH: {{{ class Lift t where lift :: t -> Q Exp }}} But that loses type information. What we want is this: {{{ Lift t where typedLift :: t -> Q (TExp t) lift :: Lift t => t -> Q Exp lift = fmap unType . typedLift }}} Otherwise, when you want the typed version, people resort to unsafe-coerce operations, which are entirely unnecessary. See [https://mail.haskell.org/pipermail/libraries/2018-January/028409.html this thread on the libraries list]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15840: Inline data constructor wrappers very late
by GHC 04 Mar '19

04 Mar '19

#15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach. Currently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1). I want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own. The proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor: In {{{#!hs case $WK u of { K x -> e; … } }}} `$WK` wouldn't unfold until very late. But we don't want the `case` expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable. Fortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls `exprIsConApp_maybe`. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with `K`). So what we can do is make `exprIsConApp_maybe` a bit smarter and teach it to see through data constructor wrappers. Let's take an unpacking wrapper as an example: {{{#!hs data T = MkT {-# UNPACK #-} !(Int, Bool) $WMkT p = case p of (i,b) -> MkT i b }}} We have to see that `$WMkT u` is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of `exprIsConApp_maybe` would change from {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr]) }}} to {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr]) }}} Where `Float`-s are lets or cases with a single alternative (much like in the FloatOut pass). We then need to change case-of-known-constructor to also perform case-of- lets and case-of-cases when such floats are found. In summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately. Does anyone sees something which could go wrong with this plan? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15840> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16303: checkStack sanity check fails
by GHC 04 Mar '19

04 Mar '19

#16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- checkStackChunk() currently has a commented-out assertion: {{{ void checkStackChunk( StgPtr sp, StgPtr stack_end ) { StgPtr p; p = sp; while (p < stack_end) { p += checkStackFrame( p ); } // ASSERT( p == stack_end ); -- HWL } }}} I realized a while ago that if I enable it, it fails in some cases, so I asked Simon Marlow about this. Quoting: > I don't know, but blame says it was disabled by Hans-Wolfgang Loidl as part of > the GUM merge 18 years ago. I suggest just enabling it and debug whatever goes > wrong. This ticket is to enable the assertion and fix bugs. To reproduce, run the test suite: {{{ $ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity }}} Tests that trigger the assertion: - annrun01 - T10508_api - dynCompileExpr Tried with GHC HEAD -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16190: Speed up handling of large String literals
by GHC 04 Mar '19

04 Mar '19

#16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- The idea would to try the following optimization for literal strings by adding a pass in the simplifier that does: 1. detect large string literals (> 2KB maybe? we would need to find a threshold) 2. append large strings into a temporary binary file, remember their offset and size 3. include the binary file into the compilation chain using ".incbin" in an assembler file (see the details here: https://hsyl20.fr/home/posts/2019-01-15-fast-file-embedding-with- ghc.html); add a fresh global module-specific symbol for the file, say "largestrings" 4. replace `Lit (Literal (LitString LARGE_BYTESTRING))` expressions with `unpackNBytes# (plusAddr (CLabel "largestrings") offset) size` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16190> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16271: Building stage1:lib:text target is not robust
by GHC 04 Mar '19

04 Mar '19

#16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- It seems the dependency on `cabal_macros.h` is not properly specified in the logic to build the libraries. If I start a build, build a library and then remove the library dir, the target fails to build. {{{ ./hadrian/build.sh stage1:lib:text rm -r _build/stage1/ ./hadrian/build.sh stage1:lib:text }}} {{{ cc1: fatal error: integersimple/stage1/libraries/text/build/autogen/cabal_macros.h: No such file or directory compilation terminated. `cc' failed in phase `C pre-processor'. (Exit code: 1) shakeArgsWith 0.000s 0% Function shake 0.006s 0% Database read 0.831s 23% ======== With database 0.100s 2% Running rules 2.545s 73% ========================= Total 3.482s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: stage1:lib:text at src/Rules/SimpleTargets.hs:31:5-15: * Depends on: integersimple/stage1/lib/package.conf.d/text-1.2.3.1.conf * Depends on: integersimple/stage1/libraries/text/build/libHStext-1.2.3.1.a * Depends on: integersimple/stage1/libraries/text/build/Data/Text/Show.o * Depends on: OracleQ (KeyValues ("integersimple/stage1/libraries/text/.dependencies","integersimple/stage1/libraries/text/build/Data/Text/Show.o")) * Depends on: integersimple/stage1/libraries/text/.dependencies * Depends on: integersimple/stage1/libraries/text/.dependencies.mk * Raised the exception: user error (Development.Shake.cmd, system command failed Command: integersimple/stage0/bin/ghc -M -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db integersimple/stage1/lib/package.conf.d' '-this-unit-id text-1.2.3.1' '-package-id array-0.5.2.0' '-package-id base-4.12.0.0' '-package-id binary-0.8.6.0' '-package-id bytestring-0.10.9.0' '-package-id deepseq-1.4.4.0' '-package-id ghc-prim-0.5.3' '-package-id integer- simple-0.1.1.1' -i -iintegersimple/stage1/libraries/text/build -iintegersimple/stage1/libraries/text/build/autogen -ilibraries/text/. -Iincludes -Iintegersimple/generated -Iintegersimple/stage1/libraries/text/build -I/nix/store /f97ls1qx6vxf75304874843ysdcyimnn-ghc-build-environment/include -Iintegersimple/stage1/libraries/text/build/include -Ilibraries/text/include -I/root/ghc/integersimple/stage1/lib/x86_64 -linux-ghc-8.7.20190124/bytestring-0.10.9.0/include -I/root/ghc/integersimple/stage1/lib/x86_64-linux- ghc-8.7.20190124/base-4.12.0.0/include -I/root/ghc/integersimple/stage1/lib/x86_64-linux- ghc-8.7.20190124/rts-1.0/include -Iintegersimple/generated -optc- Iintegersimple/generated -optP-include -optPintegersimple/stage1/libraries/text/build/autogen/cabal_macros.h -optP-DINTEGER_SIMPLE -outputdir integersimple/stage1/libraries/text/build -include-pkg-deps -dep-makefile integersimple/stage1/libraries/text/.dependencies.mk -dep-suffix '' -dep- suffix dyn_ libraries/text/Data/Text.hs libraries/text/Data/Text/Array.hs libraries/text/Data/Text/Encoding.hs libraries/text/Data/Text/Encoding/Error.hs libraries/text/Data/Text/Foreign.hs libraries/text/Data/Text/IO.hs libraries/text/Data/Text/Internal.hs libraries/text/Data/Text/Internal/Builder.hs libraries/text/Data/Text/Internal/Builder/Functions.hs libraries/text/Data/Text/Internal/Builder/Int/Digits.hs libraries/text/Data/Text/Internal/Builder/RealFloat/Functions.hs libraries/text/Data/Text/Internal/Encoding/Fusion.hs libraries/text/Data/Text/Internal/Encoding/Fusion/Common.hs libraries/text/Data/Text/Internal/Encoding/Utf16.hs libraries/text/Data/Text/Internal/Encoding/Utf32.hs libraries/text/Data/Text/Internal/Encoding/Utf8.hs libraries/text/Data/Text/Internal/Functions.hs libraries/text/Data/Text/Internal/Fusion.hs libraries/text/Data/Text/Internal/Fusion/CaseMapping.hs libraries/text/Data/Text/Internal/Fusion/Common.hs libraries/text/Data/Text/Internal/Fusion/Size.hs libraries/text/Data/Text/Internal/Fusion/Types.hs libraries/text/Data/Text/Internal/IO.hs libraries/text/Data/Text/Internal/Lazy.hs libraries/text/Data/Text/Internal/Lazy/Encoding/Fusion.hs libraries/text/Data/Text/Internal/Lazy/Fusion.hs libraries/text/Data/Text/Internal/Lazy/Search.hs libraries/text/Data/Text/Internal/Private.hs libraries/text/Data/Text/Internal/Read.hs libraries/text/Data/Text/Internal/Search.hs libraries/text/Data/Text/Internal/Unsafe.hs libraries/text/Data/Text/Internal/Unsafe/Char.hs libraries/text/Data/Text/Internal/Unsafe/Shift.hs libraries/text/Data/Text/Lazy.hs libraries/text/Data/Text/Lazy/Builder.hs libraries/text/Data/Text/Lazy/Builder/Int.hs libraries/text/Data/Text/Lazy/Builder/RealFloat.hs libraries/text/Data/Text/Lazy/Encoding.hs libraries/text/Data/Text/Lazy/IO.hs libraries/text/Data/Text/Lazy/Internal.hs libraries/text/Data/Text/Lazy/Read.hs libraries/text/Data/Text/Read.hs libraries/text/Data/Text/Show.hs libraries/text/Data/Text/Unsafe.hs -O0 -H64m -Wall -fwarn-tabs -funbox-strict-fields -O2 -XHaskell98 -ghcversion- file=/root/ghc/integersimple/generated/ghcversion.h -O -Wno-deprecated- flags -Wno-unused-imports -Werror Exit code: 1 Stderr: cc1: fatal error: integersimple/stage1/libraries/text/build/autogen/cabal_macros.h: No such file or directory compilation terminated. `cc' failed in phase `C pre-processor'. (Exit code: 1) ) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16339: Cannot put (.) or (!) into an export list
by GHC 04 Mar '19

04 Mar '19

#16339: Cannot put (.) or (!) into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Parser) | 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: -------------------------------------+------------------------------------- Thanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`: {{{#!hs type (f . g) x = f (g x) type x ! f = f x }}} However, I was surprised to discover that it's not possible to put them in an export list! That is to say, this program doesn't parse: {{{ {-# LANGUAGE TypeOperators #-} module Bug (type (.), type (!)) where type (f . g) x = f (g x) type x ! f = f x }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190219: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci Bug.hs:2:19: error: parse error on input ‘.’ | 2 | module Bug (type (.), type (!)) where | ^ }}} This problem appears to be specific to the `(.)` and `(!)` type operators, since any other type operator will work in its place: {{{#!hs {-# LANGUAGE TypeOperators #-} module Works (type (&)) where type (f & g) x = f (g x) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16348: GHC HEAD regression: tyConAppArgs
by GHC 04 Mar '19

04 Mar '19

#16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program compiles (with `-O`) on GHC 7.0.4 through 8.6.3, but panics on HEAD: {{{#!hs {-# LANGUAGE DeriveFunctor #-} module Bug where data V2 a = V2 !a !a deriving Functor (*^) :: (Functor f, Num a) => a -> f a -> f a (*^) a = fmap (a*) (*!!) :: (Functor m, Functor r, Num a) => a -> m (r a) -> m (r a) s *!! m = fmap (s *^) m type M22 a = V2 (V2 a) det22 :: Num a => M22 a -> a det22 (V2 (V2 a b) (V2 c d)) = a * d - b * c inv22 :: Fractional a => M22 a -> M22 a inv22 m@(V2 (V2 a b) (V2 c d)) = (1 / det) *!! V2 (V2 d (-b)) (V2 (-c) a) where det = det22 m }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs -O [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190219 for x86_64-unknown-linux): tyConAppArgs a_a1FK Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1183:50 in ghc:Type }}} Note that this panic does not occur if `V2` is defined without `!`s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15952: Reduce zonking-related invariants in the type checker
by GHC 04 Mar '19

04 Mar '19

#15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The type checker currently maintains two invariants, documented in `Note [The well-kinded type invariant]` in TcType and `Note [The tcType invariant]` in TcHsType. These are a pain to maintain, and Simon and I cooked up a plan not to. Step 1. The tcType invariant is all about `tcInferApps`, at least according to the Note. Previously, we couldn't zonk in `tcInferApps`, because types were knot-tied. But now we can! So, `tcInferApps` could take the type only (not its kind), zonk it, then get the type's (zonked) kind. This might also mean that `tc_infer_hs_type` no longer needs to return a type/kind pair, but could just return a type. After this is done, we can likely remove all the zonks that are in service to the tcType invariant, findable by a search. Step 2. The well-kinded type invariant is also about the need to zonk sometimes. But, instead, we could just always zonk on-the-fly. That is, we introduce new functions like `tcTypeKind` and `tcSubstTy` that zonk as they go. To make sure we're calling the right function at the right time, we introduce `newtype TcType = TcType { unTcType :: Type }`. Then, we're forced to call monadic functions on `TcType`s. This will likely lead to code duplication between `Type` and `TcType`, but we might be able to banish `zonkTcType` (and its many friends) entirely. Also gone would be the `naked` functions, which are all about maintaining the well-kinded type invariant. This step would, as a side effect, fix #15799 and #15918, which is about treating `TcType`s differently from `Type`s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15952> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail
by GHC 04 Mar '19

04 Mar '19

#16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Keywords: Big-endian | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime primops/should_run/ArithInt16, | Blocked By: primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 | Blocking: | Related Tickets: #16222 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The tests were run on a PowerMac G5 running Linux, PowerMacs are big- endian. I reduced the issue to this program where I get the incorrect answer `25132`: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Main where import GHC.Exts main :: IO () main = do putStrLn $ show (apply2 plusInt16# (50) (50)) apply2 :: (Int16# -> Int16# -> Int16#) -> Int -> Int -> Int apply2 op (I# a) (I# b) = let (# sa, sb #) = (# narrowInt16# a, narrowInt16# b #) r = op sa sb in I# (extendInt16# r) {-# NOINLINE apply2 #-} }}} Curiously, when I inline `plusInt16#` and remove the op parameter the result is correct. The test passes on little-endian PowerPC 64-bit. Note: This is bug is different form #16222 that deals with the C calling convention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16077: AvailTC Invariant being violated
by GHC 04 Mar '19

04 Mar '19

#16077: AvailTC Invariant being violated -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- The `AvailTC Invariant` (from `basicTypes/Avail.hs`) states that: {{{ If the type or class is itself to be in scope, it must be *first* in this list. Thus, typically: @AvailTC Eq [Eq, ==, \/=]@ }}} Here is a case where this invariant is not upheld: * `pkgA/pkgA.cabal`: {{{ name: pkgA version: 1.0.0 build-type: Simple cabal-version: >= 1.2 library exposed-modules: A build-depends: base }}} * `pkgA/A.hs` {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeFamilies #-} module A ( C(..) , T(TI) , error ) where class C a where data T a instance C Int where data T Int = TI { ti :: Int } }}} * `pkgB/pkgB.cabal` {{{ name: pkgB version: 1.0.0 build-type: Simple cabal-version: >= 1.2 library exposed-modules: B build-depends: base, pkgA }}} * `pkgB/B.hs` {{{ module B ( module A ) where import A hiding (error) }}} Now, check out the exports for `A` vs. `B`: {{{ $ cabal new-build pkgA pkgB --ghc-options -ddump-rn-trace | grep rnExports Warning: The package list for 'hackage.haskell.org' is 38 days old. Run 'cabal update' to get the latest list of available packages. rnExports: Exports: [error, C{C, T;}, T{T, TI;}] rnExports: Exports: [C{C, T;}, T{TI;}] }}} Why is `T{TI;}` in the second line not `T{T, TI;}`? Shouldn't the exports for `B` be identical to those for `A` (except for `error`)? This is causing a crash in Haddock: https://github.com/haskell/haddock/issues/979. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4