March 2018 - ghc-tickets

[GHC] #14709: Extend the plugin mechanism to access program representation
by GHC 03 Jun '18

03 Jun '18

#14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 8.2.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: https://phabricator.haskell.org/D4342| https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal -------------------------------------+------------------------------------- This would enable development tools to access the GHC representation in the pre-existing build environment. By the inversion of control, the tool developers don't need to decide which Haskell modules have to be processed and with what configuration, because the normal build procedure could be invoked by the user with plugin flags specifying what tools to invoke. The plan is described in more details at [https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Extended Plugins Proposal] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14324: Consider deprecating STM invariant mechanism
by GHC 03 Jun '18

03 Jun '18

#14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- fryguybob and I were recently discussing the STM invariant mechanism. This mechanism is, presumably, intended to expose problems from odd interleavings of transactions. However, fryguybob pointed out that the implementation currently takes so many locks that it very likely prevents these odd interleavings from occurring. In addition, * the implementation doesn't handle nested STM invariants correctly (#7930) * the locking behavior of the implementation was, until very recently, utterly wrong (#14310) * the feature introduces quite a bit of complexity in the RTS * the interface has essentially no users, as evidenced by a Hackage search and the fact that #14310 went unnoticed for years All of this raises the question: Is the STM invariants feature really where we want to spend our complexity budget? Perhaps it is time for this feature to quietly pass (after an appropriate deprecation period, of course). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14310: Assertion triggered by STM invariant.
by GHC 02 Jun '18

02 Jun '18

#14310: Assertion triggered by STM invariant. --------------------------------------+---------------------------------- Reporter: mbw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The program attached depends on the async and stm packages. It will push some numbers through a pipeline, while keeping track of some state. If invoked without arguments, the program will output the state and result of each iteration. If invoked via "./repro check", an STM invariant will be installed when the state is initialized. This invariant will cause the program to a) hangup, presumably due to a livelock, if the program has been compiled without "-debug", b) crash with the following error: "internal error: ASSERTION FAILED: file rts/RaiseAsync.c, line 1001", if the "-debug" flag has been used for compilation. The latter case also happens with GHC 8.0.2: "internal error: ASSERTION FAILED: file rts/RaiseAsync.c, line 997". Furthermore, this problem only occurs if the program is compiled using the additional flags "-rtsopts -threaded -with-rtsopts=-N". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage
by GHC 02 Jun '18

02 Jun '18

#12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This seems to be a build regression from ghc-8.0.1. The ghc.1 manpage was not installed for the 8.0.2 RC1 build. I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12939> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2
by GHC 01 Jun '18

01 Jun '18

#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I notice that buildbots were having a hard-time building GHC 8.2 snapshots... so I investigated... One thing that jumped at me was the memory usage while compiling DynFlags which is the worst memory-offender with 4777MiB of resident size: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.2.0.201 70313 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen - icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompi ler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -pa ckage-id directory-1.3.0.2 -package-id process-1.4.3.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.4.1 -package-id time-1.8.0.1 -package-id containers-0.5.10.2 -package-id array-0.5.1.2 -package-id fil epath-1.4.1.1 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc- boot-8.2.0.20170313 -package-id ghc-boot-th-8.2.0.20170313 -package-id ghci-8.2.0.20170 313 -package-id hoopl-3.10.2.2 -package-id unix-2.7.2.1 -package-id terminfo-0.4.0.2 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-t iming -O2 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/main/DynFlags.hs -o compiler/stage2/build/DynFlags.o -dyno compiler/stage2/build/DynFlags.dyn_o }}} {{{ <<ghc: 63014533832 bytes, 4032 GCs, 395131448/1973969928 avg/max bytes residency (24 samples), 4777M in use, 0.000 INIT (0.000 elapsed), 32.207 MUT (33.221 elapsed), 26.682 GC (26.685 elapsed) :ghc>> }}} Then I did two clean full builds of the `ghc-8.0` and `ghc-8.2` branch, and collected the -Rghc-timings output into simple 3-columns .csv files; Here's are the respective top-12 entries for GHC 8.0 and GHC 8.2 respectively: {{{#!bash $ sort -t, -k2n build.80.csv | tail -n12 "inplace/bin/ghc-stage1",560,compiler/stage2/build/TcRnDriver.o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcRnDriver.p_o "inplace/bin/ghc-stage1",572,compiler/stage2/build/TcSplice.o "inplace/bin/ghc-stage1",847,compiler/stage2/build/OptCoercion.p_o "/opt/ghc/bin/ghc",979,compiler/stage1/build/OptCoercion.o "/opt/ghc/bin/ghc",1036,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1040,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1119,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",1123,compiler/stage2/build/DynFlags.o "inplace/bin/ghc-stage1",1178,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1233,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1282,compiler/stage2/build/X86/CodeGen.p_o }}} {{{#!bash $ sort -t, -k2n build.82.csv | tail -n12 "inplace/bin/ghc-stage1",891,compiler/stage2/build/CmmParse.p_o "/opt/ghc/bin/ghc",1053,compiler/stage1/build/DynFlags.o "/opt/ghc/bin/ghc",1058,compiler/stage1/build/OptCoercion.o "inplace/bin/ghc-stage1",1284,compiler/stage2/build/HsExpr.p_o "inplace/bin/ghc-stage1",1313,compiler/stage2/build/HsExpr.o "/opt/ghc/bin/ghc",1394,compiler/stage1/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1495,compiler/stage2/build/X86/CodeGen.o "inplace/bin/ghc-stage1",1605,compiler/stage2/build/X86/CodeGen.p_o "inplace/bin/ghc-stage1",1620,compiler/stage2/build/OptCoercion.o "inplace/bin/ghc-stage1",1733,compiler/stage2/build/OptCoercion.p_o "inplace/bin/ghc-stage1",3989,compiler/stage2/build/DynFlags.p_o "inplace/bin/ghc-stage1",4777,compiler/stage2/build/DynFlags.o }}} What's apparent from this data: - GHC stage0 (which was GHC 8.0.2) is able to build DynFlags.o for GHC 8.0 and GHC 8.2 w/ roughtly the same amount of max resident memory, i.e. 1 GiB - **GHC 8.2 stage1 however needs 4 times the amount of memory more than GHC 8.0 to build the same `DynFlags.hs` module!** -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 59

[GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2
by GHC 01 Jun '18

01 Jun '18

#13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr [[https://mail.haskell.org/pipermail/ghc- devs/2017-May/014208.html|points out]] that GHC 8.2 takes significantly longer to compile `regex-tdfa-1.2.2` than 8.0.2. Interestingly, it seems that compiler allocations fell dramatically while compilation time rose. {{{ GHC 8.0.2: <<ghc: 89544610040 bytes, 2301 GCs, 189183965/391103872 avg/max bytes residency (29 samples), 1075M in use, 0.001 INIT (0.001 elapsed), 55.747 MUT (61.520 elapsed), 23.276 GC (23.278 elapsed) :ghc>> GHC 8.2.1: <<ghc: 115210990008 bytes, 6383 GCs, 116487828/234031864 avg/max bytes residency (77 samples), 670M in use, 0.001 INIT (0.000 elapsed), 64.154 MUT (68.262 elapsed), 37.114 GC (37.077 elapsed) :ghc>> }}} == Reproducing == {{{ $ cabal unpack regex-tdfa-1.2.2 $ cd regex-tdfa-1.2.2 $ cabal install --only-dependencies $ cabal configure $ cabal build $ time ghc -idist/build/autogen -O2 Text/Regex/TDFA.hs \ -XMagicHash -XFlexibleInstances -XMultiParamTypeClasses \ -XRecursiveDo -XBangPatterns -XRankNTypes -XUnboxedTuples \ -XFlexibleContexts -XUnliftedFFITypes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #9724: reexport IsList class from a trustworthy module
by GHC 01 Jun '18

01 Jun '18

#9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ==== Motivation GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe. This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe. Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well. ==== Proposed Solution (this is one of many possibilities) Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14990: "Valid refinement suggestions" have the wrong types
by GHC 31 May '18

31 May '18

#14990: "Valid refinement suggestions" have the wrong types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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've recently discovered that the "valid suggestions" feature for typed holes is quite powerful. For example, if I say {{{#!hs module Bug where import Prelude (Integer, Num(..)) x :: Integer x = _ 5 }}} and compile it with {{{ > ghc Bug.hs -frefinement-level-substitutions=2 }}} I get {{{ Bug.hs:6:5: error: • Found hole: _ :: Integer -> Integer • In the expression: _ In the expression: _ 5 In an equation for ‘x’: x = _ 5 • Relevant bindings include x :: Integer (bound at Bug.hs:6:1) Valid substitutions include negate :: forall a. Num a => a -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) abs :: forall a. Num a => a -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) signum :: forall a. Num a => a -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) fromInteger :: forall a. Num a => Integer -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) Valid refinement substitutions include (-) _ :: forall a. Num a => a -> a -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) (*) _ :: forall a. Num a => a -> a -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) (+) _ :: forall a. Num a => a -> a -> a (imported from ‘Prelude’ at Bug.hs:3:26-32 (and originally defined in ‘GHC.Num’)) | 6 | x = _ 5 | ^ }}} Note the ''refinement suggestions'', that look not only for single identifiers that fill the hole but for function calls that could, as well. However, the formatting of the refinement suggestions is incorrect, stating, for example, that `(+) _ :: forall a. Num a => a -> a -> a`. This is plain wrong. We ''could'' say `(+) _ :: a0 -> a0` where `Num a0`, and that would be right, but even better would be something like {{{ (+) x1 :: Integer -> Integer where x1 :: Integer }}} Now, I know that the first parameter to `(+)` must be an integer. In a more polymorphic situation, it could be {{{ (+) x1 :: a0 -> a0 where x1 :: a0 (Num a0) holds }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects
by GHC 31 May '18

31 May '18

#14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm opening a fresh ticket as @bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across various projects: [https://github.com/NixOS/nixpkgs/issues/22810] [https://github.com/commercialhaskell/stack/issues/2577] I'm still able to reproduce it with 8.2.1 and git HEAD with a work project: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib, 5): no suitable image found. Did find: /var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib: malformed mach-o: load commands size (34592) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I can't share the sources, but this is a command(generated by stack) that results in this error: `/Users/dr/.stack/setup-exe-cache/x86_64-osx/Cabal- simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack- work/dist/x86_64-osx/Cabal-2.0.0.2 build lib:projectname exe:projectname --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"` We're having a chat about this issue with @bgamari and I'll post some of his input: {{{ bgamari: dredozubov, unfortunately this is pretty much a limitation of OS X's linker bgamari: there's no great solution other than petitioning Apple to lift their arbitrary size limit bgamari: I've been asking people to open tickets with Apple bgamari: As they are really the only ones that can really fix this issue dredozubov: bgamari, do you know if someone did this already? bgamari: dredozubov, No one has said they have dredozubov: the other issue with it, I don't how to do a repro case dredozubov: I can reproduce it on a project with a closed sources and that's it bgamari: essentially you just need to build a project with enough dependencies bgamari: the problem is that Apple's linker sets an artificial cap on the number of shared libraries that an object file can load }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9479: Report required constraints when reporting the type of a hole
by GHC 31 May '18

31 May '18

#9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: dominiquedevriese | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: holes | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For the following code {{{ module Test where test :: String test = show _h }}} GHC currently reports: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} It correctly does not report the lack of a `Show _a` instance as a separate type error. However, it would be useful if the report containing the type of the hole would also contain the constraints that apply to its type. Something like: {{{ Found hole ‘_h’ with type: a0 Where: ‘a0’ is an ambiguous type variable Applicable constraints: Show a0 Relevant bindings include test :: String (bound at /tmp/Test.hs:4:1) In the first argument of ‘show’, namely ‘_h’ In the expression: show _h In an equation for ‘test’: test = show _h }}} I am explicitly *not* suggesting to report a type like `Show a0 => a0` for the hole, because that might mistakenly suggest that we are looking for a value of type `forall a0. Show a0 => a0`, which we are not. A possible alternative is to use an imaginary exists type like `exists a0. Show a0 => a0` but that's probably just even more confusing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11