March 2019 - ghc-tickets

[GHC] #14078: -ddump-json doesn't work well with GHCi
by GHC 04 Mar '19

04 Mar '19

#14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- Currently, `:set -ddump-json` in `GHCi` causes all errors to be gathered to be written out on exit. `ghci -ddump-json` is even worse, only resulting in a `[]` being output on exit. However, I believe this completely defeats the purpose of this flag in GHCi. I expect `ghci -ddump-json` to work like this: for _each_ evaluation typed at the GHCi prompt, one JSON array is output for all messages this evaluation caused. This proposed behavior is consistent with other flags like `-ddump-simpl`, and will allow tooling to interact with GHCi nicely. Reporting this as a bug because this looks half-supported rather than unsupported, and also because of the different behaviors of `ghci -ddump- json` and `:set -ddump-json`. Sorry if it was not warranted. == Steps to reproduce `cmd>` is the shell prompt. {{{#!hs cmd> ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 cmd> type tmp.hs main = print 2 + 2 cmd> ghci -ddump-json tmp.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [] cmd> ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -ddump-json Prelude> :l tmp.hs [1 of 1] Compiling Main ( tmp.hs, interpreted ) tmp.hs:1:8: error: ? No instance for (Num (IO ())) arising from a use of ‘+’ ? In the expression: print 2 + 2 In an equation for ‘main’: main = print 2 + 2 | 1 | main = print 2 + 2 | ^^^^^^^^^^^ Failed, 0 modules loaded. Prelude> :q Leaving GHCi. [ {"span": {"file": "tmp.hs","startLine": 1,"startCol": 8,"endLine": 1,"endCol": 19},"doc": "\u2022 No instance for (Num (IO ())) arising from a use of \u2018+\u2019\n\u2022 In the expression: print 2 + 2\n In an equation for \u2018main\u2019: main = print 2 + 2","severity": "SevError","reason": null}, {"span": null,"doc": "[1 of 1] Compiling Main ( tmp.hs, interpreted )","severity": "SevOutput","reason": null}] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14078> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm
by GHC 04 Mar '19

04 Mar '19

#16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs module Main (main) where import Data.Bits import Data.Word main :: IO () main = print $ toInteger (shiftL 1 hm :: Word64) == toInteger (shiftL 1 hm :: Word64) hm :: Int hm = -1 {-# NOINLINE hm #-} }}} The result of this program depends greatly on what optimization levels are used, and whether `-fllvm` is used: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bug: Bad shift length-1 $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O0 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... True $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O1 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... False $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -O2 -fllvm Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bug: Bad shift length-1 }}} This program manages to return all of `True`, `False`, and `Bad shift length-1` depending on which flags are used! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series
by GHC 04 Mar '19

04 Mar '19

#16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | 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: -------------------------------------+------------------------------------- I'm trying to port a core plugin to GHC 8.6.3, which was last working fine with GHC 8.4 series. Unfortunately, I'm running into issues. Wondering if pluging programming requirements have changed, or is this a regression in GHC itself. I boiled it down to the following example and would like some guidance on how to make this work: I have the following in file `TestPlugin.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TestPlugin (plugin) where import GhcPlugins import Data.Bits plugin :: Plugin plugin = defaultPlugin {installCoreToDos = install} where install _ todos = return (test : todos) test = CoreDoPluginPass "Test" check check :: ModGuts -> CoreM ModGuts check m = do mbN <- thNameToGhcName 'complement case mbN of Just _ -> liftIO $ putStrLn "Found complement!" Nothing -> error "Failed to locate complement" return m }}} And I have a very simple `Test.hs` file: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} main :: IO () main = return () }}} With GHC-8.4.2, I have: {{{ $ ghc-8.4.2 --make -package ghc -c TestPlugin.hs [1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) $ ghc-8.4.2 -package ghc -c Test.hs Found complement! }}} But with GHC 8.6.3, I get: {{{ $ ghc-8.6.3 --make -package ghc -c TestPlugin.hs [1 of 1] Compiling TestPlugin ( TestPlugin.hs, TestPlugin.o ) $ ghc-8.6.3 -package ghc -c Test.hs ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): Failed to locate complement }}} The problem goes away if I change `Test.hs` to: {{{#!hs {-# OPTIONS_GHC -fplugin TestPlugin #-} import Data.Bits -- Should not be required in the client code! main :: IO () main = return () }}} That is, if I explicitly import `Data.Bits`. But this is quite undesirable, since `Test.hs` is client code and the users of the plugin have no reason to import all bunch of modules the plugin might need for its own purposes. (In practice, this would require clients to import a whole bunch of irrelevant modules; quite unworkable and not maintainable.) Should I be coding my plugin differently? Or is this a GHC regression? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16085: ffi018_ghci fails when unregisterised
by GHC 04 Mar '19

04 Mar '19

#16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 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: -------------------------------------+------------------------------------- {{{#!patch --- /dev/null 2018-12-22 16:25:47.047680317 +0000 +++ ffi/should_run/ffi018_ghci.run/ffi018_ghci.run.stderr.normalised 2018-12-22 17:31:34.178826693 +0000 @@ -0,0 +1,4 @@ + +ffi018_ghci:6:30: + Not in scope: ‘Main.main’ + No module named ‘Main’ is imported. }}} I suspect the testsuite driver is hiding the interesting part of the failure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16217: check-api-annotations should check that an annotation does not precede its span
by GHC 04 Mar '19

04 Mar '19

#16217: check-api-annotations should check that an annotation does not precede its span -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For an API annotation to be useful, it must not occur before the span it is enclosed in. So, for `check-api-annotation` output, a line such as {{{ ((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]), }}} should be flagged as an error, as the `AnnOpenP` location of `3:21` precedes its enclosing span of `3:22-26`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary
by GHC 04 Mar '19

04 Mar '19

#16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- hadrian.cabal specifies alex and happy as build-tools, we should make hadrian pass them to ./configure when hadrian is running with {{{-c}}} (Migrated from https://github.com/snowleopard/hadrian/issues/706) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications
by GHC 04 Mar '19

04 Mar '19

#16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When you compile this file with GHC 8.6.3 and HEAD: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Kind type F = $([t| (Maybe :: Type -> Type) Int |]) }}} You get two different results: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> (Maybe :: Type -> Type) Int $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:12-45: Splicing type [t| (Maybe :: Type -> Type) Int |] ======> Maybe :: Type -> Type Int }}} Notice how in the GHC HEAD output, GHC forgets to put parentheses around `Maybe :: Type -> Type`, leading to the utterly nonsensical type `Maybe :: Type -> Type Int`. The commit that introduced this regression is [https://gitlab.haskell.org/ghc/ghc/commit/ae2c9b40f5b6bf272251d1f4107c60003… ae2c9b40f5b6bf272251d1f4107c60003f541b62]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16210: Hadrian devel2 flavour builds profiling way
by GHC 04 Mar '19

04 Mar '19

#16210: Hadrian devel2 flavour builds profiling way -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- In the make build system `devel2` doesn't build profiled libraries but hadrian does. This makes the build quite a lot slower. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set
by GHC 04 Mar '19

04 Mar '19

#16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I started implementing this in https://gitlab.haskell.org/ghc/ghc/merge_requests/27 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #1: Implicit parameters cause strange behavi
by GHC 04 Mar '19

04 Mar '19

#1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"e29b1ee72d77d5a06ac949f9dcc80108243a25c0/ghc" e29b1ee7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e29b1ee72d77d5a06ac949f9dcc80108243a25c0" Add a RTS option -xp to load PIC object anywhere in address space Summary: This re-applies {D5195} with fixes for i386: * Fix unused label warnings, see {D5230} or {D5273} * Fix a silly bug introduced by moving `#if` {P190} Add a RTS option -xp to load PIC object anywhere in address space. We do this by relaxing the requirement of <0x80000000 result of `mmapForLinker` and implying USE_CONTIGUOUS_MMAP. We also need to change calls to `ocInit` and `ocGetNames` to avoid dangling pointers when the address of `oc->image` is changed by `ocAllocateSymbolExtra`. Test Plan: See {D5195}, also test under i386: ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ cd testsuite/tests/th/ && make test ... ``` will run `./validate` on stacked diff. Reviewers: simonmar, bgamari, alpmestan, trommler, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5289 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0