January 2019 - ghc-tickets

[GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values
by GHC 02 Feb '19

02 Feb '19

#16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | 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: -------------------------------------+------------------------------------- currently the way we write haskell code to handle multiple platforms or configurations use the C preprocessor (CPP) in traditional mode. there are several challenges with this 1) tooling dependency 2) not actually designed for haskell code 3) no compiler support for checking the syntax / name / type well- formedness of each alternative code fragment under the associated environment assumptions. Abstractly, CPP uses a mapping from Names to Maybe (Either String Integer) or something to that effect. theres two ways we could then treat a "HPP" design: 1) just like CPP traditional mode, its just splicing tokens together. a) One implication of this design choice would be that to be able to check/ parse the different combinations of compilation, you'd need to be able to enumerate the set of maps of key value pairs of interest, and then you'd roughly want to have each Module be actually a {{{ Map (Map String (Maybe (Either String Integer))) Module) }}} this would have some pretty obvious code blowup issues, at least if you wanted to full on type check each combination in full. 2) only allow "HPP" to work on valid syntactic units, eg expressions, right hand sides, patterns, top level definition, etc, and provide a magic primop or several that would look roughly like NOTE: it could also just be at the Haskell post type inference phase, not necessarily at core level {{{ DefinitionDispatchTermLevel :: [(Map String (Maybe (Either String Integer)) , CoreTerm)] -> --- set of all #if/else/ifdef etc conditionals? Map (String) (Maybe (Either String Integer)) -> -- actual CPP flag combination used CoreTerm -> --- actual term ghc / optimizer works with and manipulates CoreTerm }}} this sketched out constructor representation overlooks a few things, eg the ability to do interval predicates and various boolean algebra operations, which WOULD be expressible in a fully fleshed out approch to this, but i'm elliding to keep simple. i think approach (1) or something like it would have the benefit of mostly working "today" wrt how we use CPP, and checking/coverage could be done via some package level or module level enumeration of cpp value mappings that you wnat to be checked or even generated approach (2) adds a funny looking operation to core/haskell terms/types representation where you could carry around "alternative expressions" plus the "selected expression". and thus you could do some amount of syntax/type checking for those altnerative platforms? either way, this is just me jotting down some thoughts on this because its been discussed on and off for a while now as an eventual nice to have for ghc. Also quite a complicated design space! :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16255: Visible kind application defeats type family with higher-rank result kind
by GHC 02 Feb '19

02 Feb '19

#16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: #15740 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After #15740, GHC now (correctly) rejects this program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind data SBool :: Bool -> Type type family F :: forall k. k -> Type where F = SBool }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:7: error: • Expected kind ‘forall k. k -> *’, but ‘SBool’ has kind ‘Bool -> *’ • In the type ‘SBool’ In the type family declaration for ‘F’ | 12 | F = SBool | ^^^^^ }}} However, there's a very simple way to circumvent this: add a visible kind application to `F`'s equation. {{{#!hs type family F :: forall k. k -> Type where F @Bool = SBool }}} If I understand things correctly, GHC shouldn't allow this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16255> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11004: hsc2hs does not handle single quotes properly
by GHC 01 Feb '19

01 Feb '19

#11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.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 tool gets confused by quotes for promoted constructors (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/promotion.h… #promotion-syntax). Here's an example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} gets translated into {{{#!hs {-# LINE 1 "Test.hsc" #-} {-# LANGUAGE DataKinds #-} {-# LINE 2 "Test.hsc" #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} Then GHC complains about `#size`: {{{ Test.hsc:10:16: parse error on input ‘#’ }}} Judging from the source of utils/hsc2hs/HSCParser.hs, the tool treats single quotes the same way as double quotes. I.e. it looks for balanced, possibly multiline, strings delimited by '. At least, it seems unnecessary to expect newlines in that string-like structure, because character literals cannot contain newlines, AFAIK. It's interesting to note that this problem looks like a bit of an edge case, since highlighting in the ticket seems to be confused as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket
by GHC 01 Feb '19

01 Feb '19

#15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- == Current behavior == An old ticket link is redirected to this new site, just not to the actual ticket, so some form of redirection is configured: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || == Desired outcome == An old ticket link should redirect to the actual ticket: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15514> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #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] #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] #16262: Hadrian: respect dynamicGhcPrograms
by GHC 01 Feb '19

01 Feb '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