- ghc-tickets - Haskell.org

[GHC] #16216: readHexRational missing from Numeric
by GHC 01 Feb '19

01 Feb '19

#16216: readHexRational missing from Numeric -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- The HexFloatLiterals extension was merged as result of https://github.com /ghc-proposals/ghc-proposals/blob/master/proposals/0004-hexFloats.rst As part of this proposal `showHFloat` was added to Numeric to output floating points in hexFloat format, unfortunately, no one seems to have remembered to add `readHexRational` or a similar function to parse hexFloats to Numeric. This leads to the awkward scenario that I can easily produce hexFloat values, but have no way to parse them from `String`/`Text` data... All the code already exists in `compiler/util/Utils.hs`, someone just needs to cherry pick the implementation add add it to Numeric in base. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16268: Potential race condition in Hadrian?
by GHC 01 Feb '19

01 Feb '19

#16268: Potential race condition in Hadrian? -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- It seems that sometimes CI jobs fail because of a race condition in Hadrian. https://gitlab.haskell.org/ghc/ghc/-/jobs/20254 Here, array finishes before `deepseq` starts to be built but the configure step for `deepseq` fails to find the library. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16152: Core lint error from PartialTypeSignatures
by GHC 01 Feb '19

01 Feb '19

#16152: Core lint error from PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language PartialTypeSignatures #-} {-# Language PolyKinds #-} {-# Language ScopedTypeVariables #-} {-# Options_GHC -dcore-lint #-} top :: forall f. _ top = undefined where x :: forall a. f a x = undefined }}} causes Core lint errors: {{{ $ ~/../inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 922_bug.hs GHCi, version 8.7.20181230: https://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 922_bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** <no location info>: warning: In the type ‘forall (f :: k_a1z6 -> *) w. w’ @ k_a1z6 is out of scope *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) top :: forall (f :: k_a1z6 -> *) w. w [LclIdX] top = \ (@ (f_a2BY :: k_a1z6 -> *)) (@ w_a2BZ) -> (\ (@ k_a1z6) (@ (f_a1yV :: k_a1z6 -> *)) (@ w_a1yN) -> let { $dIP_a2BO :: ?callStack::CallStack [LclId] $dIP_a2BO = emptyCallStack `cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N) :: CallStack ~R# (?callStack::CallStack)) } in let { $dIP_a2BD :: HasCallStack [LclId] $dIP_a2BD = (pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "922_bug.hs"#) (I# 8#) (I# 7#) (I# 8#) (I# 16#)) ($dIP_a2BO `cast` (N:IP[0] <"callStack">_N <CallStack>_N :: (?callStack::CallStack) ~R# CallStack))) `cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N) :: CallStack ~R# (?callStack::CallStack)) } in letrec { top_a1yW :: w_a1yN [LclId] top_a1yW = letrec { x_a1yv :: forall (a :: k_a1z6). f_a1yV a [LclId] x_a1yv = \ (@ (a_a1zd :: k_a1z6)) -> let { $dIP_a2BP :: ?callStack::CallStack [LclId] $dIP_a2BP = emptyCallStack `cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N) :: CallStack ~R# (?callStack::CallStack)) } in let { $dIP_a2Bz :: HasCallStack [LclId] $dIP_a2Bz = (pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "922_bug.hs"#) (I# 11#) (I# 7#) (I# 11#) (I# 16#)) ($dIP_a2BP `cast` (N:IP[0] <"callStack">_N <CallStack>_N :: (?callStack::CallStack) ~R# CallStack))) `cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N) :: CallStack ~R# (?callStack::CallStack)) } in break<0>() undefined @ 'LiftedRep @ (f_a1yV a_a1zd) $dIP_a2Bz; } in break<1>() undefined @ 'LiftedRep @ w_a1yN $dIP_a2BD; } in top_a1yW) @ Any @ Any @ w_a2BZ end Rec } *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16267: EXTRA_HC_OPTS workflow under hadrian.
by GHC 01 Feb '19

01 Feb '19

#16267: EXTRA_HC_OPTS workflow under hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- This allows passing of arbitrary flags to ghc from the command line. The main use case for me so far is to generate dumps for an arbitrary combination of dump flags. Sometimes I wanted to look at the simplifier output for a certain file. Sometimes I wanted to dump the asm code for all files to see how common certain patterns are. Sometimes the same for Cmm. Sometimes I want to dump two passes to be able to cross reference between them. These are usually on-off things and the exact flags often differ. So imo custom build profiles are not a good solution for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13834: Error cascade with type applications
by GHC 01 Feb '19

01 Feb '19

#13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer, | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using type applications with an out of scope identifier causes an unfortunate error cascade. {{{ foo = notInScope @Bool }}} Leads to the right out of scope error but also an error about using type application when `notInScope` is not a polytype. I think the second error should be suppressed. {{{ t.hs:4:7: error: Variable not in scope: notInScope | 4 | foo = notInScope @Bool | ^^^^^^^^^^ t.hs:4:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Bool’ notInScope • In the expression: notInScope @Bool In an equation for ‘foo’: foo = notInScope @Bool | 4 | foo = notInScope @Bool | ^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16261: Mysterious rule shadowing warning
by GHC 01 Feb '19

01 Feb '19

#16261: Mysterious rule shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- Compiling `Data.Set.Internal` produces the following: {{{ Data/Set/Internal.hs:958:11: warning: [-Winline-rule-shadowing] Rule "Set.toAscListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 958 | {-# RULES "Set.toAscListBack" [1] foldrFB (:) [] = toAscList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Data/Set/Internal.hs:960:11: warning: [-Winline-rule-shadowing] Rule "Set.toDescListBack" may never fire because rule "Class op fromListN" for ‘GHCExts.fromListN’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 960 | {-# RULES "Set.toDescListBack" [1] foldlFB (\xs x -> x : xs) [] = toDescList #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} What the heck does the class op rule for `fromListN` have to do with anything anywhere near here? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16266: Allow definition of functions with absurd contexts
by GHC 01 Feb '19

01 Feb '19

#16266: Allow definition of functions with absurd contexts -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature | Status: new request | Priority: low | 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: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} type family Head xxs where Head (x ': xs) = x type family Tail xxs where Tail (x ': xs) = xs class IsList xs where isList :: (xs ~ '[] => r) -> ((xs ~ (Head xs ': Tail xs), IsList (Tail xs)) => r) -> r instance IsList '[] where isList r _ = r instance IsList xs => IsList (x ': xs) where isList _ r = r nonEmptyListsAreNotEmpty :: (xs ~ '[], xs ~ (Head xs ': Tail xs)) => r nonEmptyListsAreNotEmpty = error "you convinced GHC that '[] ~ (_ ': _)!" sillyExample :: forall x xs. IsList (x ': xs) => () sillyExample = isList @(x ': xs) nonEmptyListsAreNotEmpty () }}} In this code, we define a class IsList which serves as a proof that something is a type-level list, via the function isList. When using this, we may occasionally get into a situation where the types guarantee that we're working with a non-empty list, but we're asked to handle the empty- list case anyway. Suppose we want to define a nice little "absurd" function that serves as a reminder to readers that this code branch is impossible, in a way that GHC can verify. This function is named "nonEmptyListsAreNonEmpty" above. Unfortunately, this code fails with {{{ Main.hs:25:34: error: • Couldn't match type ‘'[]’ with ‘Head '[] : Tail '[]’ arising from a use of ‘nonEmptyListsAreNotEmpty’ • In the second argument of ‘isList’, namely ‘nonEmptyListsAreNotEmpty’ In the expression: isList @(x : xs) nonEmptyListsAreNotEmpty () In an equation for ‘sillyExample’: sillyExample = isList @(x : xs) nonEmptyListsAreNotEmpty () | 25 | sillyExample = isList @(x ': xs) nonEmptyListsAreNotEmpty () | ^^^^^^^^^^^^^^^^^^^^^^^^ }}} And indeed, the fact that [] can't be matched against (_ : _) is in some sense the point. More generally, whenever I'm fooling around with this sort of Haskell code (in which classes are being used to provide runtime witnesses of type-level structure), I relatively regularly find myself in a branch of code where the context is obviously inconsistent, wishing that I had some way to say "search your heart, GHC; you know this case to be impossible". The fact that I can't even factor out this dead code into a function like nonEmptyListsAreNonEmpty just seems like insult added to injury. This is a minor concern, to be sure. Nevertheless, it seems to me that we should be able to write this function somehow, especially given that there are various ways to trick GHC into accepting something analogous (by clever use of GADTs such as :~:, perhaps). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16262: Hadrian: respect dynamicGhcPrograms
by GHC 31 Jan '19

31 Jan '19

#16262: Hadrian: respect dynamicGhcPrograms -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian | Operating System: Unknown/Multiple dynamic ghc programs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While `dynamicGhcPrograms` exists in Hadrian, it is not used to the extent that it's make counter part is used (`DYNAMIC_GHC_PROGRAMS`). All relevant logic from make should be implemented in Hadrian as well. A simple search for `DYNAMIC_GHC_PROGRAMS` is a good place to start. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16242: Hadrian is too aggressive in rebuilding
by GHC 31 Jan '19

31 Jan '19

#16242: Hadrian is too aggressive in rebuilding -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- Here's what has happened: 1. `build` (with settings `devel2`). This did its thing successfully. 2. Edit a comment in one file. 3. `build test --only=blahblahblah`. I was expecting to run a test. (It was a new test-case, a change unrelated to the comment I fixed.) What happens though is that stage-1 is rebuilt, and now I'm currently waiting for the entire RTS to be rebuilt. And all I wanted to do is run a test! I understand why Hadrian is doing this; it's technically got the upper hand here. But it's very frustrating. I suppose I could have done `--freeze1`, but it's too late now. And, even if I didn't do `--freeze1`, I'm surprised that the whole RTS needs to be rebuilt. Again, I know why Hadrian wants to. But I miss the old `LAX_DEPENDENCIES` feature of `make`. So, I suppose this boils down to two requests: 1. Restore the `LAX_DEPENDENCIES` feature. I don't know the specification of that feature, but my experience is that it just did the Right Thing, and I always had it enabled (except during validation). 2. Have some way of just running a test, without any rebuilding. Somewhat separately, it might be nice to package up common idioms into smaller command lines. Again, individual devs can do this, but centralized support (especially so that these scripts can be run from a variety of directories) would be nice. For example, I imagine my suggestion (2) above will lead to `build test --no-recompilation --only=xyz`, but that's a long line to write! Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #16252: QuantifiedConstraints: lack of inference really is a problem
by GHC 31 Jan '19

31 Jan '19

#16252: QuantifiedConstraints: lack of inference really is a problem -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- I've been debugging an issue that boils down to: quantified constraints are completely ignored during type inference. For example, in this program: {{{#!hs {-# language QuantifiedConstraints #-} module QC where data A f = A (f Int) eqA :: forall f. (forall x. Eq x => Eq (f x)) => A f -> A f -> Bool eqA (A a) (A b) = a == b eqA' :: (forall x. Eq x => Eq (f x)) => A f -> A f -> Bool eqA' = let g = eqA in g }}} `eqA'` won't compile because `g` gets generalised to `forall f. A f -> A f -> Bool`. I know this has been discussed (and dismissed) in tickets such as #2256 and #14942, but I really think it's a problem. In my example, I can get the code compiling by turning on ScopedTypeVariables and giving `g` an annotation. But I don't always have this liberty. For example, in the `deriving-compat` library there's Template Haskell that generates definitions containing `let`s, and when a quantified constraint is present these splices don't type check for the same reason `eqA'` doesn't. The solution here involves a pull request to `deriving-compat` that uses ScopedTypeVariables to annotate the problematic `let`s. But I really think that none of this should be necessary. The reference implementation of QCs (https://github.com/gkaracha/quantcs-impl) doesn't seem to have this problem. Is there anything I'm missing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6