February 2019 - ghc-tickets

[GHC] #13002: :set -O does not work in .ghci file
by GHC 03 Mar '19

03 Mar '19

#13002: :set -O does not work in .ghci file --------------------------------------+---------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround that isn't feasible as far as I know when using emacs thus setting priority to normal rather than low. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2
by GHC 03 Mar '19

03 Mar '19

#12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From IRC: I have a module that takes around 10 seconds to compile on ghc --make -O2, but only around 3 seconds on ghci -fobject-code -O2. > bgamari: that is surprising I've put the -v timing output of the two cases into https://gist.github.com/nh2/e9bc4732111bfe422d8e606c10f8f0ac I'm comparing the 2 files with `meld` for spotting differences easily. Check e.g. `Result size of Tidy Core` which seems to have 3x as many terms for ghc, and `Simplifier [Mymodule]` doesn't seem to run in ghci The first time terms are different is at `Desugar, the first time a factor 3 comes in is after `Specialize`. > bgamari: wow, it sounds like the simplifier isn't getting run as aggressively in GHCi I'm running this on Ubuntu 16.04 inside nix (but happens the same way outside nix). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15857: Need for better warnings arising from StarIsType extension
by GHC 02 Mar '19

02 Mar '19

#15857: Need for better warnings arising from StarIsType extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.1 Keywords: StarIsType | Operating System: Unknown/Multiple NoStarIsType | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I redefine `type (*) = (,)` I am given not given a warning that it doesn't do what I expect, when building with cabal new-repl or cabal new- build, because the `StarIsType` extension is now enabled by default. Instead or a warning, I get (correct but confusing) error messages. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14069: RTS linker maps code as writable
by GHC 01 Mar '19

01 Mar '19

#14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.0.1 System (Linker) | 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's RTS linker maps executable code in writable pages, representing a significant potential exploit point for arbitrary code execution. OpenBSD disallows running program that do this by default. Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #11503: TypeError woes (incl. pattern match checker)
by GHC 01 Mar '19

01 Mar '19

#11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds, GADTs, KindSignatures, TypeFamilies, UndecidableInstances #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} module Bug where import GHC.TypeLits import GHC.Exts ( Constraint ) type family NotInt a where NotInt Int = TypeError (Text "That's Int, silly.") NotInt _ = (() :: Constraint) data T a where MkT1 :: a -> T a MkT2 :: NotInt a => T a foo :: T Int -> Int foo (MkT1 x) = x }}} I get {{{ Bug.hs:19:1: warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: MkT2 }}} But I shouldn't. Even worse, perhaps, GHC accepts my pattern-match against `MkT2` if I add it. If I change the `TypeError` to `False ~ True`, I get the correct behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release
by GHC 01 Mar '19

01 Mar '19

#16199: GHC 8.6's bundled version of transformers doesn't correspond to a Hackage release -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14678 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.6 claims to be bundled with `transformers-0.5.5.0`, but this isn't true. That's because it's using transformers commit https://gitlab.haskell.org/ghc/packages/transformers/tree/80557845cdc0e72bc05cec19cf7a1bf5495e9e69, which happened //after// the commit corresponding to the Hackage release of 0.5.5.0 (https://gitlab.haskell.org/ghc/packages/transformers/commit/33b3c8a71778ae3…) This is not the first time this has happened: see #14678. While we were able to catch #14678 before a major release was shipped, but unfortunately, that didn't happen this time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15641: Git repositories have several problems
by GHC 01 Mar '19

01 Mar '19

#15641: Git repositories have several problems -------------------------------------+------------------------------------- Reporter: flip101 | Owner: hvr Type: bug | Status: new Priority: high | Milestone: Component: Trac & Git | Version: 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 have some problems with the repositories. When i try to clone from the official repo: {{{ » git clone --single-branch --branch master --depth=1 --recursive git://git.haskell.org/ghc.git ghc-head Cloning into 'ghc-head'... fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed }}} Maybe it's because the git server version is old (1.9.1). Without `--depth=1` it works, but anyway it's an issue. With the github mirror i have another problem: {{{ Cloning into 'libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name Email support(a)github.com for help fatal: clone of 'git://github.com/ghc/packages/Cabal.git' into submodule path 'libraries/Cabal' failed }}} With the phabricator repo the following issue: command: {{{ git clone --depth=1 --single-branch --branch ghc-8.6 --recursive https://phabricator.haskell.org/diffusion/GHC/glasgow-haskell-compiler.git ghc-8.6-head }}} error: {{{ Cloning into '.arc-linters/arcanist-external-json-linter'... error: RPC failed; HTTP 503 curl 22 The requested URL returned error: 503 first byte timeout fatal: The remote end hung up unexpectedly fatal: clone of 'https://phabricator.haskell.org/diffusion/GHC/arcanist- external-json-linter.git' into submodule path '.arc-linters/arcanist- external-json-linter' failed }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15641> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16015: git notes logic breaks CircleCI validation of pull requests
by GHC 01 Mar '19

01 Mar '19

#16015: git notes logic breaks CircleCI validation of pull requests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- Due to missing credentials. David, can you have a look? https://circleci.com/gh/ghc/ghc/12493 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16368: Boot GHC's libffi installation path leaks into stage1 build
by GHC 01 Mar '19

01 Mar '19

#16368: Boot GHC's libffi installation path leaks into stage1 build -------------------------------------+------------------------------------- Reporter: sgraf | 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: -------------------------------------+------------------------------------- Starting yesterday, I'm having problems building GHC from a `nix-shell --pure https://github.com/alpmestan/ghc.nix/archive/master.tar.gz`. Build comes to a halt after/while configuring the RTS, because it can't find libffi.h in a global nix store installation that I can't find anywhere in my `env`. That nix-store path certainly exists and has an installation of `libffi`, but without an include path (probably since recently, haven't had problems before). After some debugging, I figured out that this path leaks in through `ghc- cabal` crawling through the Package DB of the host GHC. These are the libraries it finds out about this way (dumped by inserting `putStrLn (unlines (forDeps Installed.includeDirs))` in line 388 of `utils/ghc- cabal/Main.hs`: {{{ /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0/include /nix/store/5c9pfgazxid22ik3smh8zi805cp1i03y-gmp-6.1.2-dev/include /nix/store/7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3 /integer-gmp-1.0.2.0/include /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/include /nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include }}} They are then passed on to `DEP_INCLUDE_DIRS_SINGLE_QUOTED` and wreak havoc from there. Which of these paths are vital? The `libffi` path at least seems to shadow the local tarballs for me. This concerns Hadrian and the Make-based build system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16368> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16370: Hadrian: test T3807 failure
by GHC 01 Mar '19

01 Mar '19

#16370: Hadrian: test T3807 failure -------------------------------------+------------------------------------- Reporter: davide | 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: -------------------------------------+------------------------------------- When building with hadrian, test T3807 fails with a linker error. The test's Makefile attempts to link with the RTS: {{{ # testsuite/tests/dynlibs/Makefile : 12 '$(TEST_HC)' $(filter-out -rtsopts,$(TEST_HC_OPTS)) -v0 --make -dynamic -fPIC -shared T3807Export.hs T3807-export.c -o T3807test.so -lHSrts- ghc`'$(TEST_HC)' $(TEST_HC_OPTS) --numeric-version` }}} In particular, this will result in the following linker option that causes the failure (assuming ghc version 8.9.0): {{{ -lHSrts-ghc8.9.0 }}} In Hadrian, unlike in make, the RTS library file includes the (dummy) version number, so the required linker option would actually be: {{{ -lHSrts-1.0-ghc8.9.0 }}} While it's possible to try and match makes behavior by removing the dummy version from the file names (I've started on that [https://gitlab.haskell.org/DavidEichmann/ghc/commit/f1106d1302e8d4f42778e3d… here]), a further complication arises. Hadrian tries to copy relevant library files using cabal-install's `cabal copy` command. Cabal expects the "1.0" version number to be present and so will fail. In summary, the naming conventions between Hadrian and Cabal would conflict if Hadrian dropped the "1.0" version number for the RTS library files. Some ideas on how to resolve this: 1. Drop the RTS version number in Hadrian and patch Cabal as well. * Cabal may need a special case for the RTS. * Or is there a better alternative? 2. Keep the RTS version number, but create syslinks of the library files without the RTS version number to allow backwards compatibility. 3. Something else? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2