- ghc-tickets - Haskell.org

[GHC] #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered
by GHC 23 Nov '18

23 Nov '18

#15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered -------------------------------------+------------------------------------- Reporter: davean | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.3 Component: Code Coverage | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When testing coverage of test cases, HPC does not report some instances as receiving coverage even though it seems they are. Particularly, when one hand derives the functions they show full coverage. The specific instances in question appear to be ones derived via DeriveFunctor and GeneralizedNewtypeDeriving. Problems have been observed with at least Functor, Applicative, and Monad. A minimal example is attached, and available as a cabal project at https://code.xkrd.net/davean/minimal-coverage-test. To reproduce, run "cabal v2-test --enable-coverage" and view the resulting coverage HTML files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15932> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15875: Detection of ranlib by binary distribution is broken
by GHC 23 Nov '18

23 Nov '18

#15875: Detection of ranlib by binary distribution is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- The `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1)
by GHC 23 Nov '18

23 Nov '18

#15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCs detection of unused imports used to be very precise. But apparently this changed with GHC 8.0.1. I already noticed for a while that there is something fishy going on and finally came up with a minimal example. == Steps to reproduce: {{{#!hs -- Bar.hs module Bar (bar, module Control.Monad) where import Control.Monad bar :: Integer bar = 23 }}} {{{#!hs -- Foo.hs module Foo where import Bar import Control.Monad (forM_) foo :: Monad m => [a] -> (a -> m ()) -> m () foo = forM_ baz :: Integer baz = bar }}} {{{ $ ghci -Wall -Werror Foo.hs }}} **Expected result:** The program is reject. **Actual result:** The program was reject by GHC < 8.0.1, however later versions of GHC accept the program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15319: Configurable/overridable settings file
by GHC 23 Nov '18

23 Nov '18

#15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | 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: -------------------------------------+------------------------------------- GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C. The problem is that I can't override *everything*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file. What I'd like is something like: {{{ $ ghc -settings /path/to/settings/file }}} that subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15940: Source plugins should be able to opt-out from appearing in dependencies
by GHC 23 Nov '18

23 Nov '18

#15940: Source plugins should be able to opt-out from appearing in dependencies -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: source | Operating System: Unknown/Multiple plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently when ghc build a module M using a source plugin in a package P, P shows up in the interface file of M (`M.hi`). According to `--show-iface`, P shows up in the `package dependencies` section, and in an `addDependentFile` entry. Presumably, this is necessary to recompile M if P ever changes. But unfortunately, including P in the interface file is the wrong thing to do when the plugin does not affect the result of the compilation of M. It is only fair to wonder what the point would be in using a plugin which does not modify the compilation. I hit this case when using the upcoming haskell-indexer-plugin, which extracts source code information for later examination. If the indexer plugin changes, there is no point in rebuilding M, unless the user really wants to reindex the source code. Can we change the plugin interface to opt-out of tracking dependencies? Or would it work better to provide a ghc flag to control this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15940> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #602: Warning Suppression
by GHC 23 Nov '18

23 Nov '18

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Design/LocalWarningPragmas | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15859: Dependent quantification, GHC panic
by GHC 22 Nov '18

22 Nov '18

#15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While exploring [https://gist.github.com/RyanGlScott/ded669b5ae3db1ce38c4b6021f144776 Ryan's gist for term-level] `f :: forall a -> a -> Type`. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeApplications #-} {-# Language ImpredicativeTypes #-} import Data.Kind data A k :: k -> Type f :: KindOf A f a = undefined type KindOf (a :: k) = k a = f @Int }}} gives {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci 630_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 630_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! KindOf A forall k -> k -> * k_a1xQ[sk:0] k_a1xQ[sk:0] -> * k_a1xQ[sk:0] [req] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcExpr.hs:1336:94 in ghc:TcExpr Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15859> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15715: problematic openFile with named pipes
by GHC 22 Nov '18

22 Nov '18

#15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.4.3 libraries/base | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- - while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the process hearing on the other side didn't hear anything). - `writeFile` and `appendFile` works though. - using stack `resolver: lts-12.4`, on ubuntu 16.04 LTS -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH
by GHC 22 Nov '18

22 Nov '18

#15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------------+---------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199) I've attached a minimal program that uses the GHC API and exhibits the same problem. {{{ $ ghc-8.4.2 -package ghc -package containers -package ghc-paths Prog.hs [1 of 1] Compiling Main ( Prog.hs, Prog.o ) Linking Prog ... $ ./Prog Main-no-TH.hs -package template-haskell $ ./Prog Main-TH.hs -package template-haskell Prog: lookupSymbol failed in relocateSection (RELOC_GOT) /usr/local/lib/ghc-8.4.2/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands' Prog: Prog: unable to load package `integer-gmp-1.0.2.0' }}} In case it isn't clear, I do not expect `Main-TH.hs` to crash `Prog`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory
by GHC 22 Nov '18

22 Nov '18

#15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: None | Version: Keywords: | Operating System: MacOS X Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path. See the offending `LC_LOAD_DYLIB` command here: {{{ $ jtool -l libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal) Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs) Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal) Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals) Mem: 0x0004df760-0x0004e0f40 __TEXT.__const Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info LC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs) Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs) Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs) Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs) Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill) LC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT LC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 04: LC_DYLD_INFO LC 05: LC_SYMTAB Symbol table is at offset 0x6a5348 (6968136), 118090 entries String table is at offset 0x873d78 (8863096), 3241616 bytes LC 06: LC_DYSYMTAB 81438 local symbols at index 0 35948 external symbols at index 81438 704 undefined symbols at index 117386 No TOC No modtab 1380 Indirect symbols at offset 0x8727e8 LC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA LC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0 LC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0 LC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib LC 11: LC_LOAD_DYLIB @rpath/libHSinteger- gmp-1.0.2.0-ghc8.6.0.20180714.dylib LC 12: LC_LOAD_DYLIB @rpath/libHSghc- prim-0.5.3-ghc8.6.0.20180714.dylib LC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib LC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib LC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0 LC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3 LC 17: LC_RPATH @loader_path/../rts LC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions LC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348) }}} The other offenders are `libHSbinary` and `libHSinteger-gmp`. Without changing these load commands, you'll get the following error: {{{ $ ./configure --prefix=... $ make install <snip> dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: ./libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} I tried passing the `--with-gmp-libraries` option to `configure`, but that did not help. I guess this is just a packaging problem, but figured you should be aware before the official release... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14