March 2019 - ghc-tickets

[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] #16375: TypeApplications obscure "Variable not in scope" error message
by GHC 01 Mar '19

01 Mar '19

#16375: TypeApplications obscure "Variable not in scope" error message -------------------------------------+------------------------------------- Reporter: roland | 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: -------------------------------------+------------------------------------- Compiling {{{#!hs {-# LANGUAGE TypeApplications #-} module Foo where foo = bar @Int }}} gives {{{ Foo.hs:5:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Int’ • In the expression: bar @Int In an equation for ‘foo’: foo = bar @Int }}} instead of: {{{ Foo.hs:5:7: error: Variable not in scope: bar }}} This makes a potential typo appear like a typing error (no pun intended). If we delete `@Int`, the second message is given. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[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

[GHC] #15800: Overlapping instances error with single instance
by GHC 01 Mar '19

01 Mar '19

#15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts, FlexibleInstances #-} module Bug where class C a b instance C a Int x :: () x = undefined :: C a Int => () }}} {{{ ghc -c Bug.hs Bug.hs:10:18: error: • Overlapping instances for C a0 Int Matching givens (or their superclasses): C a Int bound by an expression type signature: forall a. C a Int => () at Bug.hs:10:18-30 Matching instances: instance C a Int -- Defined at Bug.hs:7:10 (The choice depends on the instantiation of ‘a0’) • In the ambiguity check for an expression type signature To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In an expression type signature: C a Int => () In the expression: undefined :: C a Int => () | 10 | x = undefined :: C a Int => () | ^^^^^^^^^^^^^ }}} The "matching instances" bit of the error messages only lists a single instance. Doesn't it take at least two instances for something to overlap? Also, following the algorithm laid out in the user guide (section "Overlapping Instances"), it appears this program should be accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16020: Hadrian: correctly Install libffi shared object files
by GHC 01 Mar '19

01 Mar '19

#16020: Hadrian: correctly Install libffi shared object files -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (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 Phab:D5423 a hack to correctly install the libffi .so files is implemented. This is a quick and dirty solution to fix the hadrian build. Note [Hadrian: install libffi hack] from that patch and also issue #15837 have more details, but ultimately hadrian should not have a special case for libffi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2