July 2017 - ghc-tickets

[GHC] #14016: broken link to associated type family instances?
by GHC 23 Jul '17

23 Jul '17

#14016: broken link to associated type family instances? -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/8.2.1-notes… contains this: > See the section on `associated type family instances <assoc-data-inst>` for more information. This looks like it was meant to be a link but got mangled somehow. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14020: grammar in RTS release notes
by GHC 23 Jul '17

23 Jul '17

#14020: grammar in RTS release notes -------------------------------------+------------------------------------- Reporter: mauke | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/8.2.1-notes… #runtime-system says: > Output of ''[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_con… #rts-eventlog Event log data]'' can now be configured. Enabling external tools to collect and analyze the event log data while the application is still running. I'm pretty sure that's supposed to be one sentence (with a comma in the middle): Output of ''[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_con… #rts-eventlog Event log data]'' can now be configured, enabling external tools to collect and analyze the event log data while the application is still running. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite
by GHC 23 Jul '17

23 Jul '17

#13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the merge of the package database locking business, `ghc-pkg dump` spews a message on `stderr` on Windows, {{{ $ "C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" dump WARNING: cache is out of date: C:\msys64\home\ben\ghc\inplace\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. name: xhtml version: 3000.2.1 id: xhtml-3000.2.1 ... }}} When the testsuite driver sees this it (namely `testutil.getStdout`) assumes something has gone terribly wrong and aborts. From a cursory look it's not clear how we got into this situation; the file indeed exists and was certainly touched during the build. However, running `ghc-pkg recache` indeed seems to fix the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #13354: Package database locking patch broke ghc-pkg with non-existent database
by GHC 23 Jul '17

23 Jul '17

#13354: Package database locking patch broke ghc-pkg with non-existent database -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- It seems that Phab:D3090 (#13194) broke `ghc-pkg`'s behavior in the face of non-existent package databases. Namely, `cabal install` fails during registration with, {{{ Creating package registration file: /tmp/pkgConf- compact-0.1.0.1-13684/pkgConf ("/opt/exp/ghc/roots/master/bin/ghc-pkg",["update","-","--global","-- user","-v2"]) /opt/exp/ghc/roots/master/bin/ghc-pkg returned ExitFailure 1 with error message: ghc-pkg: Couldn't open database /home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d for modification: /home/ben/.ghc/x86_64-linux-8.1.20170227/package.conf.d.lock: openBinaryFile: does not exist (No such file or directory) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14014: trac guest account doesn't work
by GHC 23 Jul '17

23 Jul '17

#14014: trac guest account doesn't work -------------------------------------+------------------------------------- Reporter: mauke | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- The bug reporting instructions at https://ghc.haskell.org/trac/ghc/wiki/ReportABug say > To submit an anonymous bug: use login "guest", password "guest" Doing so just results in > Error > > Invalid username or password -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8
by GHC 23 Jul '17

23 Jul '17

#13974: Official FreeBSD 10.3 distribution should link against libutil.so.9, not libutitl.so.8 -------------------------------------+------------------------------------- Reporter: mqudsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.3 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The official distribution of GHC for FreeBSD, as retrieved from [0] attempts to link against libutil.so.8 FreeBSD 10.3 is actually built against libutil.so.9, and there is no /lib/libutil.so.8 (and no version 8 of the library available via the package manager/ports). Symlinking /lib/libutil.so.9 to /lib/libutil.so.8 appears to allow GHC to run without issue, but I can't guarantee the results. Since the distributed GHC tarball is specific to FreeBSD 10.3, it should probably link against libutil.so.9 as well. (I am completely new to Haskell/GHC and have no clue what "component" to tag this as. I was looking for a 'distribution' or 'packages' component, but can find none. My apologies in advance for tagging it as 'None') [0]: https://www.haskell.org/ghc/download_ghc_7_10_3.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #11375: Type aliases twice as slow to compile as closed type families.
by GHC 23 Jul '17

23 Jul '17

#11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: aarch64 | Type of failure: Compile-time | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! This bug is awkard at last to me. So I notiiced today, that using type aliases in my code takes twice as long to copile than using closed type families with just single member. So to be most precise - when I replace the following line: {{{ type XQ1 m a = Targets (Match m a) }}} with {{{ type family XQ1 m a where XQ1 m a = Targets (Match m a) }}} the compilation time drops from 15s to 7s (this type alias is heavily used across the application). I think it could be somehow related to the famous #8095 bug, but I can of course be wrong here. Unfortunetally the codebase is pretty big and its not so easy to make a minimal example, but I'll try to work on it during the upcoming weekend (please notify me if that would not be necessary). And some statistics from `-dshow-passes`: When using type alias: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 66,949, coercions: 16,383,834} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,391, coercions: 16,507,338} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,437, coercions: 16,504,770} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,347, coercions: 16,504,734} Result size of Simplifier = {terms: 10,543, types: 74,347, coercions: 16,504,630} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,522, coercions: 16,504,729} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,430, coercions: 16,504,729} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64965_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} and with type families: {{{ *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 310, types: 867, coercions: 78} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 301, types: 878, coercions: 296} Result size of Simplifier = {terms: 301, types: 878, coercions: 293} *** Tidy Core: Result size of Tidy Core = {terms: 337, types: 1,002, coercions: 293} *** CorePrep: Result size of CorePrep = {terms: 475, types: 1,305, coercions: 293} *** ByteCodeGen: *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_93.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_92.o compile: input file /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_1.hscpp *** Checking old interface for Main: [45 of 45] Compiling Main ( /Users/wdanilo/dev/hs/public/variants/Main.hs, interpreted ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 10,303, types: 67,609, coercions: 162,249} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 10,722, types: 75,721, coercions: 323,027} Result size of Simplifier iteration=2 = {terms: 10,550, types: 74,767, coercions: 320,473} Result size of Simplifier iteration=3 = {terms: 10,543, types: 74,677, coercions: 320,437} Result size of Simplifier = {terms: 10,543, types: 74,677, coercions: 320,333} *** Tidy Core: Result size of Tidy Core = {terms: 10,846, types: 75,852, coercions: 320,432} *** CorePrep: Result size of CorePrep = {terms: 14,823, types: 96,760, coercions: 320,432} *** ByteCodeGen: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_95.c Warning: deleting non-existent /var/folders/y9/km24zv3d4yl711mwv85vwljc0000gp/T/ghc64863_0/ghc_94.o Ok, modules loaded: Prologue, Type.Bool, Type.Container, Type.List, Type.Set, Data.Cata, Type.Promotion, Data.Bits.Mask, Control.Monad.State.Dependent, Control.Monad.Poly, Control.Applicative.Poly, Type.Regex, Type.Either, Data.Reprx, Data.Impossible, Type.Cache.TH, Main, Control.Lens.Utils, Control.Lens.Wrapped.Utils, Data.Text.CodeBuilder, Data.Text.CodeBuilder.Tok, Data.Text.CodeBuilder.Builder, Data.Text.CodeBuilder.Doc, Data.Binary.Instances.Missing, Data.Default.Instances.Missing, Data.String.Class, Data.Text.Class, Data.Convert, Data.Layer, Data.Container.Class, Data.Container.List, Data.Functor.Utils, Type.Operators, Type.Show, Type.Wrapped, Data.Container.Opts, Data.Container.Poly, Data.Convert.Base, Data.Convert.Instances, Data.Convert.Instances.Map, Data.Convert.Instances.Num, Data.Convert.Instances.Text, Data.Convert.Instances.TH, Data.Convert.Bound, Data.Bits.Base. *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: ... }}} As we can see the type aliases produce much more coertions: 16,383,834 vs 78 using type families. This is really interesting thing and it seems related to the linked bug above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14011: T3807 fails to build on FreeBSD
by GHC 22 Jul '17

22 Jul '17

#14011: T3807 fails to build on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- FreeBSD doesn't have a `libdl`; instead it provides `dlopen` and friends in `libc`. Consequently this testcase fails to link. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14011> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14008: NondecreasingIndentation is problematic when the indentation can't be decreased
by GHC 22 Jul '17

22 Jul '17

#14008: NondecreasingIndentation is problematic when the indentation can't be decreased -------------------------------------+------------------------------------- Reporter: allbery_b | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program, which was deliberately mis-indented (someone playing with an exercise with deliberate errors and being confused by the result): {{{#!hs module Print3Broken where printSecond :: IO () printSecond = do putStrLn greeting -- Yarrrrr out of scope main :: IO () main = do putStrLn greeting printSecond where greeting = "Yarrrrr" }}} With `-XNondecreasingIndentation` on by default, this will parse as long as the definition of `main` (or any other definition) is not present after the `do` block. But there is no legal way to have a definition after the `do` because it is not possible to unindent from column 1 --- and the resulting parse error is a bit confusing and gives no hint that `NondecreasingIndentation` applied to the `do` is the cause. I suspect `NondecreasingIndentation` should not be applied when it is impossible to decrease the indentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14008> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14009: ghc-8.2.1_rc3 fails unregisterised build
by GHC 22 Jul '17

22 Jul '17

#14009: ghc-8.2.1_rc3 fails unregisterised build -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed when was building --enable-unregisterised build for x86_64: {{{ /tmp/ghc22931_0/ghc_3.hc:5:9: error: error: '__stginit_ghczmprim_GHCziTypes' redeclared as different kind of symbol StgWord __stginit_ghczmprim_GHCziTypes[]__attribute__((aligned(8)))= { ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 5 | StgWord __stginit_ghczmprim_GHCziTypes[]__attribute__((aligned(8)))= { | ^ In file included from /tmp/ghc22931_0/ghc_3.hc:3:0: error: /tmp/ghc22931_0/ghc_3.hc:4:5: error: note: previous declaration of '__stginit_ghczmprim_GHCziTypes' was here EF_(__stginit_ghczmprim_GHCziTypes); ^ }}} The error here is mismatch in symbol type: EF_ ("external function") It should be EC_ ("external closure"). The same build failure does not happen in HEAD because the __stginit_* is not generated there anymore (see a92ff5d66182d992d02dfaad4c446ad074582368) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4