July 2018 - ghc-tickets

[GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers
by GHC 22 Aug '18

22 Aug '18

#15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tested with version 8.2.2 and 8.0.2 (stack lts-11.5, lts-9.21, nightly-2018-04-14) with GHC and GHCi on archlinux amd64. **Code that produces wrong results** {{{ map (/2) [9007199254740990..9007199254740991] }}} **Expected behaviour** same as with low values: {{{ map (/2) [5..6] }}} resulting in: {{{ [2.5,3.0] }}} **Actual behaviour** resulting in an infinite list: {{{ [4.503599627370495e15,4.5035996273704955e15,4.503599627370496e15..] }}} **Similar code that produces expected results** multiplication works: {{{ map (*2) [9007199254740990..9007199254740991] }}} slightly smaller number work: {{{ map (/2) [9007199254740989..9007199254740990] }}} using a comma to produce the same list works: {{{ map (/2) [9007199254740990,9007199254740991] }}} **Similar code that also produces unexpected results** more elements in the list: {{{ map (/2) [9007199254740990..9007199254740999] map (/2) [9007199254740990..9007199354740999] }}} substituting the number and doing calculations: {{{ map (/2) [9007199254740990..9007199254740990+1] let a = 9007199254740990 map (/2) [a..a+1] }}} using scan and fold: {{{ foldl1 (/) [9007199254740990..9007199254740991] scanl1 (/) [9007199254740990..9007199254740991] }}} **Notes** This somehow only happens with high numbers when using fractional operations and using .. to construct the list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12674: GHC doesn't handle ./ prefixed paths correctly
by GHC 22 Aug '18

22 Aug '18

#12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- GHC doesn't correctly handle paths preceded by `./` on the command line, if their first character (after any number of `./`s) is a `-`. For instance, `ghc ./-a.hs` fails, even if `a.hs` exists. Somewhere, `./-a.hs` is being converted to `-a.hs`. I have not been able to figure out where this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11409: Cannot instantiate literals using TypeApplications
by GHC 22 Aug '18

22 Aug '18

#11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int <interactive>:3:1: error: • Cannot not apply expression of type ‘a0’ to a visible type argument ‘Int’ • In the expression: 42 @Int In an equation for ‘it’: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings
by GHC 21 Aug '18

21 Aug '18

#13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 }}} This compiles with no warnings with `-Wall`. But if you tweak `catchAll` to add a catch-all case at the end: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 catchAll _ = error "impossible" }}} Then if you compile it with `-Wall`, you'll get a very misleading warning: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -Wall GHCi, version 8.1.20170228: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘catchAll’: catchAll TooGoodToBeTrue = ... | 17 | catchAll TooGoodToBeTrue = 1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I would have expected the warning to be on the `catchAll _ = error "impossible"` case! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10869: Option to dump preprocessed source
by GHC 21 Aug '18

21 Aug '18

#10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Driver | 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 Revisions: | -------------------------------------+------------------------------------- It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway. Use case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15189: Avoid word "transformer" in the documentation of ST
by GHC 21 Aug '18

21 Aug '18

#15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.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'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why. Some time ago, as a novice, I struggled to get the difference between three monad-related concepts: 1. The State monad. 2. The StateT monad transformer. 3. The ST monad. Current [http://hackage.haskell.org/package/base-4.11.1.0/docs/Control- Monad-ST.html documentation for ST] says that "ST" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper "Lazy Functional State Threads", I find this confusing after the adoption of term "(monad) transformer" due to 1995 paper "Functional Programming with Overloading and Higher-Order Polymorphism". Note that ST paper predates MT one. At the same time, the 1994 paper itself (in the title) and some current tutorials, [https://wiki.haskell.org/Monad/ST like the one at HaskelWiki], use the word "thread" to describe what's going on, avoiding discussion of spelling of ST. As the bottom line, I think, it would be helpful, especially for a novice, to avoid the word "transformer" in the documentation of ST module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15261: Show -with-rtsopts options in runtime's --info
by GHC 21 Aug '18

21 Aug '18

#15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases: - When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging. - Sometimes we instruct users saying "compile with this and run with that". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say "look at the info, you should see this and that". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15426: `elemIndex` and `findIndex` still can't fuse
by GHC 21 Aug '18

21 Aug '18

#15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.4.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: -------------------------------------+------------------------------------- Ticket #14387 introduced a change to the implementation of `listToMaybe` to allow: {{{#!hs findIndex p = listToMaybe . findIndices p }}} to fuse. However, to take advantage of this, it looks like we also need `findIndex` (and `elemIndex`) to be marked inlinable (or some similar step). As a concrete example, the module: {{{#!hs module Foo where import Data.List (findIndex) foo :: Maybe Int foo = findIndex (==999999) [1..1000000] }}} compiled with GHC 8.4.3 using `-O2` produces the following unfused core: {{{#!hs foo_go = \ ds1_a2ws eta_a2wt -> case ds1_a2ws of { [] -> Nothing; : y_a2wx ys_a2wy -> case eqInteger# y_a2wx ds_r2we of { __DEFAULT -> foo_go ys_a2wy (+# eta_a2wt 1#); 1# -> Just (I# eta_a2wt) } } foo = foo_go (enumDeltaToInteger1 foo2 foo1) 0# }}} but if the definition of `findIndex` from `Data.OldList` is copied into the module or imported from another module with an `INLINABLE` pragma, then it fuses fine: {{{#!hs foo_go = \ x_a2Du eta_B1 -> case gtInteger# x_a2Du lim_r2Ey of { __DEFAULT -> case eqInteger# x_a2Du ds_r2Cv of { __DEFAULT -> foo_go (plusInteger x_a2Du foo1) (+# eta_B1 1#); 1# -> Just (I# eta_B1) }; 1# -> Nothing } foo = foo_go foo1 0# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15279: CPP #includes may result in nonsensical SrcSpans
by GHC 21 Aug '18

21 Aug '18

#15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code in `compiler/prelude/PrimOp.hs` {{{#!hs primOpInfo :: PrimOp -> PrimOpInfo #include "primop-primop-info.hs-incl" primOpInfo _ = error "primOpInfo: unknown primop" -- line 175 in PrimOp.hs }}} The MatchGroup for primOpInfo includes the `SrcSpan` `compiler/stage2/build/primop-primop-info.hs-incl:(1,1)-(175,49)` Here is line 175 in `primop-primop-info.hs-incl` {{{#!hs primOpInfo IndexSmallArrayOp = mkGenPrimOp (fsLit "indexSmallArray#") [alphaTyVar] [mkSmallArrayPrimTy alphaTy, intPrimTy] ((mkTupleTy Unboxed [alphaTy])) }}} The `SrcSpan`s end is somewhere in the middle of that line. I guess this occurs because `combineSrcSpans` doesn't take the file into account. I can think of multiple ways to fix this: 1. Make `combineSrcSpans` output an `UnhelpfulSrcSpan` if the files don't match(quick and easy) 2. Extend SrcSpan to properly support things spanning multiple files 3. Don't fix: People who use CPP get what they deserve. Option 3 is not unreasonable as options 1 and 2 will incur some performance penalty. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15051: -split-objs generates excessively many files on Windows
by GHC 21 Aug '18

21 Aug '18

#15051: -split-objs generates excessively many files on Windows --------------------------------------+--------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- A BuildFlavour = perf build generated ~18k .S files for ghc- prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17