June 2018 - ghc-tickets

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

22 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 22 Aug '18

22 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] #15279: CPP #includes may result in nonsensical SrcSpans
by GHC 22 Aug '18

22 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 22 Aug '18

22 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

[GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded
by GHC 22 Aug '18

22 Aug '18

#15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: T8089 | Blocked By: Blocking: | Related Tickets: #8089 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ =====> T8089(ghci) 17 of 17 [2, 16, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" T8089.hs -dcore-lint -dcmm- lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < T8089.genscript Wrong exit code for T8089(ghci) (expected 99 , actual 0 ) *** unexpected failure for T8089(ghci) =====> T8089(threaded1) 17 of 17 [2, 17, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -threaded -debug cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 Wrong exit code for T8089(threaded1)(expected 99 , actual 0 ) *** unexpected failure for T8089(threaded1) =====> T8089(threaded2) 17 of 17 [2, 18, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -threaded -eventlog cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -N2 -ls -RTS Wrong exit code for T8089(threaded2)(expected 99 , actual 0 ) *** unexpected failure for T8089(threaded2) =====> T8089(profthreaded) 17 of 17 [2, 19, 0] cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow- validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto -threaded cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -p -RTS Wrong exit code for T8089(profthreaded)(expected 99 , actual 0 ) *** unexpected failure for T8089(profthreaded) }}} I'm going to write a patch to expect the test to be broken in these ways, but it seems really wrong that the exit code we get is not the same accross all ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9854: Literal overflow check is too aggressive
by GHC 21 Aug '18

21 Aug '18

#9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The literal overflow check is too aggressive. Sometimes you want to give a literal as a hexadecimal value that does fit inside e.g. an `Int`, like so: {{{ Prelude> 0xdc36d1615b7400a4 :: Int <interactive>:2:1: Warning: Literal 15868100553162883236 is out of the Int range -9223372036854775808..9223372036854775807 -2578643520546668380 }}} However the compiler complains because of the wrap-around. I feel this is common enough and practice (and perfectly well-defined) that the compiler shouldn't warn. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12467: distclean does not clean 'compact' library
by GHC 21 Aug '18

21 Aug '18

#12467: distclean does not clean 'compact' library -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- {{{ > ghc_2 git:(master) make distclean 2>&1 | grep compact > ghc_2 git:(master) }}} I think we should see something like {{{ "rm" -rf libraries/compact/dist-install }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12467> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15295: Haddock options should be concatened
by GHC 21 Aug '18

21 Aug '18

#15295: Haddock options should be concatened -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: haddock | 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 we have the following situation: 1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock- opts` are ignored 2. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered. Instead all options should be concatenated (with `, `), with the CLI options at the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12482: Infinite compilation time when using wrongly ordered constraints
by GHC 20 Aug '18

20 Aug '18

#12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! I've seen today a very strange bug in GHC 8. Namely I've got an instance: {{{ instance {-# OVERLAPPABLE #-} (PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g) => DynamicM t (HMGraph s rels) m a where addM el = nested (prop2' @t . wrapped') $ (swap ∘ fmap Ptr) <∘> ixed Cont.addM (unsafeCoerce el) }}} and I'm using it indirectly in Main.hs. It compiles fast and works fine. The problem is that when I change the above constraint to: {{{ (PrimMonad m, HasProperty2' t g, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m) }}} Which is basically the same but with different order, the file with this constraint compiles fast and fine, but Main.hs compiles infinite amount of time (I've killed it after 10 minutes). The problem is reproducible, but it is hard right now to make minimal example out of it (we are going to a conference with a product release and we cannot track it right now). I post it here because maybe the bug is known, if not, after the release I'll try to provide more info. If you've got any questions I'd love to assist. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15220: ScopedTypeVariables binds a non-existent variable
by GHC 20 Aug '18

20 Aug '18

#15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- GHC accepts this definition: {{{#!hs f :: (forall a. a -> a) -> () f (x :: b -> b) = x (undefined :: b) `seq` () }}} If a scoped type variable is bound always to a variable, then what variable is `b` bound to? In the desugared Core, it looks like `b` is bound to `Any`. Note that I couldn't find any valid argument for `x` here other than `undefined`. I think this definition should be rejected. In terms of implementation, the `zonkTcTypeToType` function should never encounter a unfilled-in `SigTv`. If it does, error. I don't like putting the error there, but I'm not sure I know another place to do it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13