January 2019 - ghc-tickets

[GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0
by GHC 07 Feb '19

07 Feb '19

#15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all- packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package- id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64 -linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc- std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc- Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion- file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe Exit code: 1 Stderr: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180617 for x86_64-unknown-linux): Can't use Natural in base }}} We noticed this in hadrian land (in [https://github.com/snowleopard/hadrian/issues/499 this PR] and [https://github.com/snowleopard/hadrian/issues/629] and noticed that this happens: - with 8.4.2 as the boot compiler but not 8.2.2 - with integer-simple as the integer library - only with the quickest flavour (or more generally when we build GHC.Natural with -O0) Some optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef. The full build log is available [https://travis- ci.org/snowleopard/hadrian/jobs/393259151#L4209 here], anchored to where the error appears. An example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer- simple -j4`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16082: Sort out treatment of underscores in types
by GHC 06 Feb '19

06 Feb '19

#16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- I can count 4 different meanings for underscores in Haskell programs: 1. A pattern for which we don't care to write a name. (This dates back to antiquity.) Example: {{{#!hs const x _ = x }}} 2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.) Example: {{{#!hs plus x y = x + _ }}} 3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.) Example: {{{#!hs plus :: forall a. Num a => a -> a -> _ plus x y = x + y }}} 4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.) Example: {{{#!hs x = const @_ @Bool 'x' -- the _ is inferred to mean Char }}} Problems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types). This is a mess, for at least three reasons: A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this. B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy. C. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad. This ticket is to track resolutions to these problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType
by GHC 06 Feb '19

06 Feb '19

#14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 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: -------------------------------------+------------------------------------- `IOErrorType` has a "`ResourceVanished`" constructor: https://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.IO.Exception… But there is no way to detect this for an `IOException` or `IOErrorType`. Here is some real-world code I found, where the author wants to catch "`ResourceVanished`", but resorts to catching all `IOException`: https://hackage.haskell.org/package/http-client-tls-0.3.5.1/docs/src /Network-HTTP-Client-TLS.html#convertConnection Docs for `hPutBuf` also mention the public existence of "`ResourceVanished`": https://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-IO- Handle.html#v:hPutBuf Suggestion: We need to add functions: {{{#!haskell isResourceVanished :: IOError -> Bool resourceVanishedErrorType :: IOErrorType isResourceVanishedErrorType :: IOErrorType -> Bool }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16264: Install reqlib'd libraries during CI
by GHC 06 Feb '19

06 Feb '19

#16264: Install reqlib'd libraries during CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | 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: -------------------------------------+------------------------------------- Currently tests requiring external libraries are hardly ever run. We likely don't want to run them in every job but we should have at least one job that makes a point of doing so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16106: Remove PowerPC OS X (Darwin) support
by GHC 06 Feb '19

06 Feb '19

#16106: Remove PowerPC OS X (Darwin) support --------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: powerpc | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- OS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin. The following components contain PowerPC Darwin specific code: * native code generator * RTS * driver * build system -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled
by GHC 06 Feb '19

06 Feb '19

#15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when retainer profiling is enabled. Here is an example taken from https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 {{{ {-# OPTIONS_GHC -fprof-auto #-} import Control.Monad import Data.IORef import System.Environment main = do [n] <- getArgs replicateM (read n) (newIORef [1,2,3]) }}} {{{ % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) Linking repro ... % ./repro 10000000 +RTS -s -h 3,053,080,472 bytes allocated in the heap 5,538,404,848 bytes copied during GC 1,013,615,328 bytes maximum residency (16 sample(s)) 36,422,944 bytes maximum slop 966 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s 0.0019s Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s 1.0136s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( -0.833s elapsed) GC time 4.016s ( 4.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 1.715s ( 1.715s elapsed) EXIT time 1.715s ( 1.715s elapsed) Total time 6.612s ( 6.612s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 0 bytes per MUT second Productivity -12.6% of total user, -12.6% of total elapsed }}} Here is what I found so far: * GHC 8.6.1, 8.6.2, and yesterday's HEAD have the same issue. GHC 8.4.4 doesn't have this issue. * `-hr` has the same issue. `-hT` is fine. * Without heap profiling the numbers this doesn't happen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs
by GHC 05 Feb '19

05 Feb '19

#16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Suppose we have {{{#!hs data G a where G1 :: G Char G2 :: G Bool }}} If I now write {{{#!hs foo x = case x of G1 -> 'z' G2 -> True }}} I rightly get an error around untouchable variables. If I add the type signature {{{#!hs foo :: G a -> a }}} all is well again. So far, so good. Now, I write {{{#!hs foo :: forall a. G a -> a foo x = ((case x of G1 -> 'z' G2 -> True) :: _) }}} and I get those untouchable errors again. Untouchable-variable errors usually arise when there are multiple possible answers to the type inference problem. Yet, that isn't the case here: `_` must stand for `a`. Solution: mumble mumble bidirectional type inference mumble mumble. Part of the problem comes from Note [Partial expression signatures] in TcExpr, which states {{{ here is a guiding principile e :: ty should behave like let x :: ty x = e in x }}} Indeed, if we behave like that, the untouchable-variable errors are to be expected. But I also think that it would be a nice principle to say that `:: _` is always a no-op. This is not an idle nice-to-have: if we fix this, `singletons` will continue to work with GHC. Right now, it doesn't: https://github.com/goldfirere/singletons/issues/357 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16146> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16134: Continuous integration on FreeBSD
by GHC 05 Feb '19

05 Feb '19

#16134: Continuous integration on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Arrowd has been looking at introducing CI for FreeBSD/amd64. He has a build script using poudriere [[http://arrowd.name/ghc-ci|here]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15558: Locally handling an empty constraint
by GHC 05 Feb '19

05 Feb '19

#15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | 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 need something like `\case {}` for constraints. See the code below. There's nothing I can replace the `undefined` with that will satisfy the type checker. The dead code warning also bubbled up out of the field incorrectly. I think this will require new language features tangentially related to Lambdas for `forall`. (Both `forall _.` and `=>` are invisible quantifiers.) I will link this ticket in that GHC proposal, but am making it's own issue in the first place in case this is a genuine bug that can be fixed by less intrusive means. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ScopedTypeVariables #-} module Asdf where import Data.Kind import Data.Type.Equality data Sing a where X :: Sing Int Y :: Sing [Bool] data Foo a = Foo a (forall b. [b] :~: a -> b) data Bar a = Bar a (forall b. [b] ~ a => b) f, f' :: forall a. Sing a -> Foo a f s = Foo a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] :~: a -> b b = case s of X -> \case {} Y -> \Refl -> False f' = \case X -> Foo 0 (\case {}) Y -> Foo [] (\Refl -> False) g, g' :: forall a. Sing a -> Bar a g s = Bar a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] ~ a => b b = case s of Y -> False g' = \case X -> Bar 0 undefined -- can't make this happy Y -> Bar [] False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #16178: Brackets and splices should be overloaded like the static keyword
by GHC 05 Feb '19

05 Feb '19

#16178: Brackets and splices should be overloaded like the static keyword -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 Haskell | Keywords: | Operating System: Unknown/Multiple TypedTemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's quite convenient that the `static` keyword is rebindable. To recap, if `e :: T` then `static e :: (IsStatic p) => p t`. It should also be possible rebind brackets and splices in the same manner. So we introduce two type classes `IsBracket` and `IsSplice`. Now quoting a term `e :: T` has type `e :: IsBracket p => p T` and the argument to a splice must have type `e :: IsSplice p => p T` which results in a value of type `T`. {{{ class IsBracket p where fromBracket :: Code t -> p t class IsSplice p where toBracket :: p t -> Code t foo :: IsBracket p => p Int foo = [|| 5 ||] qux :: (IsSplice p, IsBracket p) => Int qux = $$(foo) }}} As an aside, arguably the `static` form should only be rebindable when `RebindableSyntax` is enabled but that boat seems to have sailed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16178> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3