January 2019 - ghc-tickets

[GHC] #16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc
by GHC 02 Jan '19

02 Jan '19

#16119: Hide the gnarly levity polymorphism stuff in the signatures of `undefined`, `throw`, etc -------------------------------------+------------------------------------- Reporter: jberryman | 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: -------------------------------------+------------------------------------- In base-4.12, `throw` goes from {{{#!hs throw :: Exception e => e -> a }}} to {{{#!hs throw :: forall (r :: RuntimeRep). forall (a :: TYPE r). forall e. Exception e => e -> a }}} http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Exception- Base.html#v:throw Similar story for `undefined`. Even as a fairly experienced haskell programmer I find the signature difficult to parse, leaving aside the meaning of `RuntimeRep` and `TYPE`. The amount of research an expert in Haskell 98 would have to do to thoroughly understand that signature is unreasonable (the various meanings of `forall`, `DataKinds`, as well as the levity polymorphism stuff). I don't have a proposed solution, but a constraint synonym or something that hid `RuntimeRep` and `TYPE`, and which could be documented with "This means a type with any runtime representation; everything is fine" would be okay. Relevant: https://ghc.haskell.org/trac/ghc/ticket/12030 https://ghc.haskell.org/trac/ghc/ticket/11549 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16121: testsuite: only_ways(llvm_ways) behaves strangely
by GHC 02 Jan '19

02 Jan '19

#16121: testsuite: only_ways(llvm_ways) behaves strangely -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- It appears that specifying `only_ways(llvm_ways)` for tests is not sufficient. E.g. when looking for the test T8131 in the llvm-CI-runner's logs, you won't find it. It is written like this: {{{#!python test('T8131', [cmm_src, only_ways(llvm_ways)], compile_fail, ['']) }}} The only `optllvm`-way tests are on `validate-aarch64-linux-deb9` {{{ =====> T5681(optllvm) 2409 of 6747 [0, 83, 8] cd "llvm/should_compile/T5681.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T5681.hs -dcore-lint -dstg-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 -O -fllvm =====> T6158(optllvm) 2410 of 6747 [0, 83, 8] cd "llvm/should_compile/T6158.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T6158.hs -dcore-lint -dstg-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 -O -fllvm -package vector -package primitive =====> T7571(optllvm) 2411 of 6747 [0, 83, 8] cd "llvm/should_compile/T7571.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T7571.cmm -dcore-lint -dstg-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 -O -fllvm -no-hs-main =====> T8131b(optllvm) 2413 of 6747 [0, 83, 8] cd "llvm/should_compile/T8131b.run" && "/builds/ghc/ghc/inplace/bin/ghc- stage2" -c T8131b.hs -dcore-lint -dstg-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 -O -fllvm =====> T11649(optllvm) 2414 of 6747 [0, 83, 8] }}} These are triggered by the magic incantation: {{{#!python def f( name, opts ): opts.only_ways = ['optllvm', 'llvm', 'debugllvm'] setTestOpts(f) }}} `validate-x86_64-linux-deb9-llvm` won't even test those... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15914: haddock-library-1.7.0 fails to build on ppc64 BE
by GHC 02 Jan '19

02 Jan '19

#15914: haddock-library-1.7.0 fails to build on ppc64 BE -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was trying to build ghc-8.6.2 for Fedora 28 and it failed on ppc64 (Bigendian) with: {{{ utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:99:25: error: • GHC internal error: ‘TableRow’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [aIy :-> Type variable ‘id’ = id :: k, rHO :-> ATcTyCon Table :: k -> *, rHP :-> APromotionErr RecDataConPE] • In the type ‘[TableRow id]’ In the definition of data constructor ‘Table’ In the data declaration for ‘Table’ | 99 | { tableHeaderRows :: [TableRow id] | ^^^^^^^^ utils/haddock/dist/build/haddock/autogen/Paths_haddock.hs:41:22: error: • Couldn't match type ‘a’ with ‘String’ Expected type: IO a Actual type: IO String • In the first argument of ‘catchIO’, namely ‘(getEnv "haddock_libdir")’ In the expression: catchIO (getEnv "haddock_libdir") (\ _ -> return libdir) In an equation for ‘getLibDir’: getLibDir = catchIO (getEnv "haddock_libdir") (\ _ -> return libdir) | 41 | getLibDir = catchIO (getEnv "haddock_libdir") (\_ -> return libdir) | ^^^^^^^^^^^^^^^^^^^^^^^ make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Paths_haddock.dyn_o] Error 1 utils/haddock/haddock-api/src/Haddock/Syb.hs:22:1: warning: [-Wunused-top- binds] Defined but not used: ‘isType’ | 22 | isType _ = isJust $ eqT @a @b | ^^^^^^ utils/haddock/haddock-api/src/Haddock/Syb.hs:38:1: warning: [-Wunused-top- binds] Defined but not used: ‘everythingBut’ | 38 | everythingBut k f x = let (v, stop) = f x | ^^^^^^^^^^^^^ utils/haddock/haddock-api/src/Haddock/Syb.hs:60:21: warning: [-Wunused- matches] Defined but not used: ‘s’ | 60 | everythingWithState s k f x = | ^ utils/haddock/haddock-api/src/Haddock/Syb.hs:75:1: warning: [-Wunused-top- binds] Defined but not used: ‘everywhereBut’ | 75 | everywhereBut q f x | ^^^^^^^^^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.6.2 for powerpc64-unknown-linux): urk! lookup local fingerprint $fShowTokenType [] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Error 1 make: *** [Makefile:127: all] Error 2 }}} https://koji.fedoraproject.org/koji/taskinfo?taskID=30919315 (the log files are only preserved for 2 weeks) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic
by GHC 01 Jan '19

01 Jan '19

#8611: nofib’s cacheprof’s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <<ghc: 127588752 bytes, 243 GCs, 2261288/6551032 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.12 elapsed), 0.05 GC (0.05 elapsed) :ghc>> ./cacheprof +RTS -t <<ghc: 127392144 bytes, 242 GCs, 2261304/6551576 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (0.11 elapsed), 0.04 GC (0.05 elapsed) :ghc>> }}} The allocations numbers change, when they shoudn’t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #4450: Do stack squeezing before expanding stack
by GHC 01 Jan '19

01 Jan '19

#4450: Do stack squeezing before expanding stack -------------------------------------+--------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Sebastian Graf <sgraf1337@…>): In [changeset:"e2d614e40e8b049ac0bcf3c6ccc6f0009864511e/nofib" e2d614e/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="e2d614e40e8b049ac0bcf3c6ccc6f0009864511e" Disable timer-based context switches Summary: In the past, we repeatedly had problems with non-deterministic allocations due to stack squeezing during context switches (#4450, #8611). This patch adds `+RTS -V0 -RTS` as extra `RUNTEST_OPTS` for every single- threaded benchmark. Is this the right place to add the flags? Should we also do this for all the other benchmarks? Reviewers: simonmar, osa1, nomeata, O26 nofib GHC Trac Issues: #8611 Differential Revision: https://phabricator.haskell.org/D5470 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4450#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16048: Show Instance for IOException discards error code
by GHC 01 Jan '19

01 Jan '19

#16048: Show Instance for IOException discards error code -------------------------------------+------------------------------------- Reporter: andrewthad | 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: -------------------------------------+------------------------------------- The `Show` instance for `IOException` currently looks like this: {{{ instance Show IOException where showsPrec p (IOError hdl iot loc s _ fn) = (case fn of Nothing -> case hdl of Nothing -> id Just h -> showsPrec p h . showString ": " Just name -> showString name . showString ": ") . (case loc of "" -> id _ -> showString loc . showString ": ") . showsPrec p iot . (case s of "" -> id _ -> showString " (" . showString s . showString ")") }}} Notice that it discards the error code (the fifth field in the data constructor). This means that when we call `ioError` to raise an `IOException`, we end up missing out on useful information. For example, in a project I'm working on now, I get this: {{{ *** Exception: Network.Icmp.Ping: ping: permission denied (Permission denied) }}} But I expected to see the original error code in there as well, which would help me diagnose issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4