October 2018 - ghc-tickets

[GHC] #13773: Types are not normalized in instance declarations
by GHC 25 Nov '18

25 Nov '18

#13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider the example below. It does not compile, but replacing 5*2 by 10 makes it compile. This is quite annoying since it forces me to do the normalization that the computer is really much better at doing. {{{#!hs module NatInstance where import GHC.TypeLits type N = 5 * 2 data D (n :: Nat) = D instance Show (D N) where show _ = "" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15085: :type-at/:all-types and :r don't mix
by GHC 25 Nov '18

25 Nov '18

#15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Put `x = ()` in test.hs. 2. Start ghci. 3. Turn on collection with :set +c. 4. Load the file with :l test.hs. 5. Observe the following output from :all-types {{{ test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () }}} 6. While ghci is still open, modify the file to say `x = True`. 7. In the same ghci session as before, reload with :r, or load the file again with :l test.hs, chef's choice. 8. Run :all-types again. After step 8, ghci prints the exact same thing as before, indicating that both sides of the equation have type `()`. It should instead update the source spans and types to match the file, reporting `Bool` instead of `()` and `(1,5)-(1,9)` for the second span. Manually exiting and restarting ghci appears to be the only way to freshen the collected type information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15495: Handling Source Locations via TTG
by GHC 24 Nov '18

24 Nov '18

#15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | 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: -------------------------------------+------------------------------------- == Problem == The current implementation of [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG HsSyn AST] in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style. Besides the indirection and the resulting complications of the ping-pong style, there are two key problems with it: a. It bakes-in the source locations in the base TTG AST, forcing all instances to store source locations, even if they don't need them.For example, TH AST does not carry source locations, or even within GHC, there are generated terms without source locations. b. It results in a form of conceptual redundancy: source locations are tree decorations and they belong in the extension points. (see https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG Guidance]) == Solution == We can move the source location decorations to a wrapper constructor and remove the ping-pong style. This can be done smoothly, mechanically, and gradually by using a getter/setter methods for source locations. More details can be found at [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… the related wiki page]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #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

[GHC] #15633: Type-checker plugins aren't loaded in 8.6.1
by GHC 22 Nov '18

22 Nov '18

#15633: Type-checker plugins aren't loaded in 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- Type-Checker plugins seem to work in GHCi-8.4.3 https://gist.github.com/phadej/f2040eba327a88d3652cda021403f97f However with GHC-8.6.1 The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180907 76a233143f1ec940f342ce3ce3afaf306923b392 (which seems to be the last commit in 8.6 branch atm) the plugins aren't loaded. {{{ % ghci-8.6.1 -fplugin=ThereIsNoPlugin GHCi, version 8.6.0.20180907: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ogre/.ghci λ> }}} starts a session without a warning. 8.4.3 however fails: {{{ % ghci-8.4.3 -fplugin=ThereIsNoPlugin GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help <command line>: Could not find module ‘ThereIsNoPlugin’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15796: Core Lint error
by GHC 22 Nov '18

22 Nov '18

#15796: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This gives a Core Lint error {{{#!hs {-# Language QuantifiedConstraints #-} {-# Language TypeApplications #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language FlexibleInstances #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language MultiParamTypeClasses #-} {-# Language ConstraintKinds #-} {-# Language UndecidableInstances #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind type Cat ob = ob -> ob -> Type class Ríki (obj :: Type) where type (-->) :: Cat obj class Varpi (f :: dom -> cod) newtype (··>) :: Cat (a -> b) where Natu :: Varpi f => (forall xx. f xx --> f' xx) -> (f ··> f') instance Ríki cod => ------------- Ríki (dom -> cod) where type (-->) = (··>) @dom @cod }}} {{{ $ ghci -ignore-dot-ghci 568_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 568_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): Core Lint error <no location info>: warning: In the type ‘(··>)’ Found TcTyCon: ··>[tc] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :q Leaving GHCi. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15796> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10