November 2018 - ghc-tickets

[GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types
by GHC 11 Nov '18

11 Nov '18

#15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: -------------------------------------+------------------------------------- On our work on the [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow new front-end AST for GHC] based on [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG], we would like to use [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… a pattern synonym] similar to the following: {{{#!hs pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a pattern LL s m <- (decomposeSrcSpan -> (m , s)) where LL s m = composeSrcSpan (m , s) }}} We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total). As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym. I believe we need to enhance COMPLETE pragmas to support such pattern synonyms. This can be done either syntactically, or (preferably) type-directed. For example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`. In the type-directed approach a. the totality checker *may* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and b. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by @carter). For example, in the case of `LL`, `HasSrcSpan a` is a required type constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15611: scope errors lie about what modules are imported
by GHC 11 Nov '18

11 Nov '18

#15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Here's Test.hs: {{{ module Test where }}} And here's a ghci session: {{{ % ghci Test.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help *Test> Test.foo <interactive>:1:1: error: Not in scope: ‘Test.foo’ No module named ‘Test’ is imported. }}} That "No module named ‘Test’ is imported." part seems blatantly wrong (and persists even if I explicitly `import Test` rather than using the implicit loading of the module). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s
by GHC 11 Nov '18

11 Nov '18

#11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.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: -------------------------------------+------------------------------------- Haskell2010 states: > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`. Consider the following two modules: {{{#!hs -- module Main (main) where import Main2 (main) }}} {{{#!hs module Main2 (main) where main :: IO () main = return () }}} A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with {{{ $ ghci Main.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 2] Compiling Main2 ( Main2.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:1:1: The IO action ‘main’ is not exported by module ‘Main’ Failed, modules loaded: Main2. }}} For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15820: Document the proposals process in the GHC manual
by GHC 10 Nov '18

10 Nov '18

#15820: Document the proposals process in the GHC manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 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 ghc-proposals process has proved robust, in my opinion. We should explicitly state that such a process exists and point users to it from the manual. This came up as I was documenting the solution to #15743 in the manual. The end result there is very much a free design decision, and I wanted to invite readers to propose changes if they disagree with the design. But there's no good way to do so, currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15884: Completeness of View Patterns With a Complete Set of Output Patterns
by GHC 10 Nov '18

10 Nov '18

#15884: Completeness of View Patterns With a Complete Set of Output Patterns -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- For example, the code {{{#!hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ViewPatterns #-} f :: Maybe a -> Bool f (id->Nothing) = False f (id->(Just _)) = True }}} mistakenly returns the warning {{{ warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: _ | 4 | f (id->Nothing) = False | ^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15884> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 09 Nov '18

09 Nov '18

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Matthew. If anyone wants to pick this up I'd be happy to help. But I'm too swamped to lead on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:83> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 09 Nov '18

09 Nov '18

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Sebastian says that this patch got parked because of a few reasons. Anyone interested in picking up this ticket can see a source of ideas in the linked differential. https://phabricator.haskell.org/D4244 He says: * I wasn't sure I understood everything that was going in that patch * There were several 'improvements' that were independent of nested CPR that we wanted to test in isolation (#15001, D4563, D4565) * I felt strongly against complicating demand analysis any further. I remember there was this horrible special case for `case` expressions ([https://phabricator.haskell.org/D4244#inline-35408 klick]) that IMO shows that CPR analysis, as opposed to Usage/Strictness analysis, is a forward analysis. Also there's this 'virgin run', which basically means we run the demand analyser twice anyway, because CPR relies on strictness info being available. That's why I strongly argue that we should split off CPR analysis first before implementing nested CPR. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:82> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h"
by GHC 09 Nov '18

09 Nov '18

#8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 (make) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) Comment: Just noting that this issue prevents me from build ghc-8.6 on s390x Linux. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8040#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15867: STG scope error
by GHC 08 Nov '18

08 Nov '18

#15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | 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: -------------------------------------+------------------------------------- StgRhsClosure can contain duplicated names in its free variable and argument list. Example bug: libraries/integer-gmp/src/GHC/Integer/Type.hs GHC HEAD and 8.2.2 has this issue. I have not checked with other versions. I've extended the STG linter to do scope checking. See the patch attached. To reproduce: * patch GHC head: `git apply StgScopeCheck.patch` * make sure every compiled stg is linted: add `-dstg-lint` to GhcStage2HcOpts GhcLibHcOpts GhcRtsHcOpts config vars * compile GHC HEAD Background info: I've found this issue because I'm using GHC as a Haskell fronted for my whole program compiler project. I work on The GRIN Compiler (https://github.com/grin-tech) where GHC/GRIN compiles STG to GRIN. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15867> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator
by GHC 08 Nov '18

08 Nov '18

#15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 (LLVM) | 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: -------------------------------------+------------------------------------- Unfortunately it looks like LLVM doesn't like that we use `bitcast` to narrow integers. E.g. `CmpWord8` currently fails with: {{{ =====> CmpWord8(llvm) 18 of 23 [0, 6, 0] cd "primops/should_run/CmpWord8.run" && "/mnt/work/ghc/ghc- compare-1/inplace/test spaces/ghc-stage2" -o CmpWord8 CmpWord8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -fllvm Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( CmpInt8.hs, CmpInt8.o ) opt: /run/user/1000/ghc32287_0/ghc_2.ll:14549:20: error: invalid cast opcode for cast from 'i64' to 'i8' %ln6uE = bitcast i64 %ln6uD to i8 ^ `opt' failed in phase `LLVM Optimiser'. (Exit code: 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15864> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3