April 2018 - ghc-tickets

[GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error
by GHC 18 May '18

18 May '18

#11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Type checker) | 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: -------------------------------------+------------------------------------- The following variation on [[GhcFile(testsuite/tests/typecheck/should_compile/T10009.hs)]] compiles cleanly: {{{#!hs {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-} {-# OPTIONS_GHC -fno-warn-redundant-constraints #-} module T10009WithClass where type family F a type family UnF a class (UnF (F b) ~ b) => C b where f :: F b -> () g :: forall a. (C a) => a -> () g _ = f (undefined :: F a) }}} But compiling it with the dummy typechecker plugin [[GhcFile(testsuite/tests/typecheck/should_compile/T11462_Plugin.hs)]] yields {{{ $ ghc -dynamic -c T11462_Plugin.hs $ ghc -fplugin=T11462_Plugin -dynamic -c T10009WithClass.hs T10009WithClass.hs:10:5: error: - Could not deduce: F b0 ~ F b from the context: C b bound by the type signature for: f :: C b => F b -> () at T10009WithClass.hs:10:5-18 NB: 'F' is a type function, and may not be injective The type variable 'b0' is ambiguous Expected type: F b -> () Actual type: F b0 -> () - In the ambiguity check for 'f' To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall b. C b => F b -> () In the class declaration for 'C' }}} Superficially, the problem is that the presence of the plugin causes `runTcPluginsWanted` to zonk the pending superclass constraint, changing it to a `CNonCanonical`. This in turn prevents `solveWanteds` from making any further progress (which ultimately leads to the error): {{{ getUnsolvedInerts tv eqs = {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} fun eqs = {[W] hole{aIM} :: F b_aIu[tau:3] GHC.Prim.~# s_aIL[fuv:2] (CFunEqCan)} insols = {} others = {[W] $dC_aIv :: C b_aIu[tau:3] (CDictCan(psc))} <===== BEFORE plugin implics = {} Unflattening {Funeqs = [W] hole{aIM} :: F b_aIu[tau:3] GHC.Prim.~# s_aIL[fuv:2] (CFunEqCan) Tv eqs = [W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} Filling coercion hole aIM := <F b_aIu[tau:3]>_N unflattenFmv s_aIL[fuv:2] := F b_aIu[tau:3] writeMetaTyVar s_aIL[fuv:2] :: * := F b_aIu[tau:3] Unflattening 1 {} Unflattening 2 {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} Unflattening 3 {} Unflattening done {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CNonCanonical)} zonkSimples done: {[W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} zonkSimples done: {[W] $dC_aIv :: C b_aIu[tau:3] (CNonCanonical), <===== AFTER plugin [W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} solveSimples end } iterations = 1 residual = WC {wc_simple = [W] $dC_aIv :: C b_aIu[tau:3] (CNonCanonical) [W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} solveWanteds } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #11457: Run type-checker plugins before GHC's solver
by GHC 18 May '18

18 May '18

#11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (Type checker) | Keywords: plugin | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an odd use-case for type-checker plugins: rejecting ''valid'' programs that the user doesn't like, for example, programs that use a class instance with confusing behavior (like the functor/traversable instances on tuples). Unfortunately, we can't write such a plugin at the moment because GHC runs its own solver first, and will (I think) discharge any dictionary constraints before the plugin can run. If instead we run the plugins first, a plugin could mark undesired instances as insoluble. See the discussion at http://mail.haskell.org/pipermail/libraries/2016-January/026602.html for the original motivation. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10077: Providing type checker plugin on command line results in false cyclic import error
by GHC 18 May '18

18 May '18

#10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Linux Keywords: | Type of failure: Incorrect typechecker plugin cycle imports | warning at compile-time Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am playing around with the new type checker plugins using the current development branch of GHC. When I supply the plugin module to GHC through the command line I get a cyclic import error message, which I think is false. If I supply the same plugin module using a pragma I do not get an error message. === Minimal Example (Command Line) `MyPlugin.hs`: {{{#!hs module MyPlugin ( plugin ) where import Plugins ( Plugin, defaultPlugin ) plugin :: Plugin plugin = defaultPlugin }}} `Test.hs`: {{{#!hs module Test where main :: IO () main = return () }}} Command line call of GHC: {{{ ~/ghc/inplace/bin/ghc-stage2 \ --make -package ghc-7.11.20150209 \ -fplugin=MyPlugin \ Test.hs }}} Results in the following error {{{ Module imports form a cycle: module ‘MyPlugin’ (./MyPlugin.hs) imports itself }}} which does not seem reasonable to me understand. === Minimal example (pragma) On the other hand, if I change `Test.hs` to the following {{{#!hs {-# OPTIONS_GHC -fplugin MyPlugin #-} module Test where main :: IO () main = return () }}} and calling GHC like this {{{ ~/ghc/inplace/bin/ghc-stage2 \ --make \ -package ghc-7.11.20150209 \ -dynamic \ Test.hs }}} it works. I did not change `MyPlugin.hs`. === Note 1. Using `-fplugin=MyPlugin` vs. `-fplugin MyPlugin` does not make a difference. 1. The command line example behaves the same independent of whether I supply the `-dynamic` flag or not. 1. I had to add the `-dynamic` flag, because otherwise GHC will complain that: {{{ <no location info>: cannot find normal object file ‘./MyPlugin.dyn_o’ while linking an interpreted expression }}} This might be a long shot, but maybe using the `-fplugin` option should imply the `-dynamic` flag? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11435: Evidence from TC Plugin triggers core-lint warning
by GHC 18 May '18

18 May '18

#11435: Evidence from TC Plugin triggers core-lint warning -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: core-lint | Operating System: Linux warning evidence type-checker | plugin | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached plugin and program produce a core-lint warning that refers to evidence the plugin did not produce. == High-Level description of what the plugin does and what happens 'flatFilter' produces the following ambiguous wanted constraints: {{{ Polymonad (Reader '["thres" :-> Int]) n (Reader '["thres" :-> Int]) (CNonCanonical) Polymonad (Reader '["thres" :-> Int]) m n (CNonCanonical) Polymonad Identity Identity m }}} To solve these the plugin does the following: 1. It produces two type equality constraints: {{{ n ~ Identity (CNonCanonical) m ~ Reader '["thres" :-> Int] (CNonCanonical) }}} 2. As a result of these equality constraints the GHC constraint solver creates the following wanted constraint: {{{ Polymonad (Reader '["thres" :-> Int]) Identity (Reader '["thres" :-> Int]) (CNonCanonical) }}} GHCs constraint solver can not pick an instance because several instances overlap: {{{ P.Monad f => Polymonad f Identity f ( Effect m, E.Inv m f (Unit m), f ~ Plus m f (Unit m)) => Polymonad (m (f :: [*])) Identity (m (f :: [*])) }}} By trying to produce evidence for either of these instances the plugin determines that only the second instance is actually applicable and therefore selects it and produces evidence. With this the constraints are solved and the type checking/constraint solving stage is done. During core linting we get the following error: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: Warning: [RHS of ds_a66V :: (Set '["thres" :-> Int], Set (Unit Reader))] Bad getNth: Nth:0 (Nth:2 (Sub (Sym (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <'[]>_N)) ; (Inv <Reader>_N <'["thres" :-> Int]>_N (Sym TFCo:R:Unit[]Reader[0]))_R ; Sub (TFCo:R:Inv[]Readerfg[0] <'["thres" :-> Int]>_N <Unit Reader>_N))) Split '["thres" :-> Int] '[] (Union '["thres" :-> Int] '[]) Split '["thres" :-> Int] (Unit Reader) (Union '["thres" :-> Int] (Unit Reader)) }}} As can be seen in the plugin [Check for 'Nth' constructor] the evidence produced by the plugin does not contain the 'Nth' constructor for coercions/evidence anywhere. Thus, the produced evidence seems to trigger GHC to produce these 'bad' coercions/evidence somewhere. == Building the Example The example should be self-contained and reproduces the error whenever you try to build it. You can find it here or in the attachment: https://github.com/jbracker/polymonad-plugin/tree/master/examples/core- error You just have to download the three files and run "cabal install" to reproduce the error. There is a high-level explanation of what is going on above and in the 'Main.hs' from line 83. The plugin 'MinimalPlugin.hs' is still around 600 lines long, but I have added a lot of comments to make it comprehensible. I suppose the most interesting part is the production of evidence in 'MinimalPlugin.hs' from line 198. I have added checks to see if the evidence I produce contains the 'Nth' constructors the core-lint warning refers to in line 130 and 556 of the plugin, but the evidence produced does not contain them. So somehow the evidence triggers GHC to produce evidence that the core-linter warns about. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11435> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking
by GHC 18 May '18

18 May '18

#15016: Referencing a do-bound variable in a rec block with ApplicativeDo results in variable not in scope during type checking -------------------------------------+------------------------------------- Reporter: rjmk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | 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: -------------------------------------+------------------------------------- I searched + hope this isn't a dupe. When using both ApplicativeDo and RecursiveDo, referring to a do-bound variable from outside of a rec block causes a GHC internal error. Here's a minimal example: {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE RecursiveDo #-} module Lib where import Control.Monad.Fix f :: MonadFix m => m () f = do a <- return () rec let b = a return () }}} The error message I get is {{{ src/Lib.hs:12:13: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1pF :-> Type variable ‘m’ = m :: * -> *, r1mX :-> Identifier[f::forall (m :: * -> *). MonadFix m => m (), TopLevelLet [] True]] • In the expression: a In an equation for ‘b’: b = a In a stmt of a 'do' block: rec let b = a | 12 | let b = a | ^ }}} I have reproduced it in 8.2.2 and 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble
by GHC 17 May '18

17 May '18

#14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- 64 bit GHC has 64 bit Unique values, but they don't fit in a `template- haskell` `NameU` when cross-compiling to a 32 bit target. In theory we can support Template Haskell in this situation with `-fexternal-interpreter` (and the earlier GHCJS implementation), but when the target cannot represent GHC's uniques in an `Int`, things go wrong: from `Language.Haskell.TH.Syntax`: {{{#!hs type Uniq = Int }}} I think we can fix this for now by changing the synonym to `type Uniq = Int64` (or even `type Uniq = Integer`), making the `template-haskell` `Uniq` at least as big as the GHC `Unique` in practice. This requires a change in `DsMeta`. the uses of `Int` below should really be changed to `Uniq` {{{#!hs data NameFlavour = NameS -- ^ An unqualified name; dynamically bound | NameQ ModName -- ^ A qualified name; dynamically bound | NameU !Int -- ^ A unique local name | NameL !Int -- ^ Local name bound outside of the TH AST | NameG NameSpace PkgName ModName -- ^ Global name bound outside of the TH AST: -- An original name (occurrences only, not binders) -- Need the namespace too to be sure which -- thing we are naming deriving ( Data, Eq, Ord, Show, Generic ) }}} {{{#!hs -- Global variable to generate unique symbols counter :: IORef Int {-# NOINLINE counter #-} counter = unsafePerformIO (newIORef 0) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH
by GHC 17 May '18

17 May '18

#11774: Regression on GHC 8 branch (vs 7.10.3) when using the GHC API to parse code that uses TH ----------------------------------------+--------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- If you use the GHC API to parse code that uses TH, the code does not work after a {{{:reload}}} in {{{ghci}}} anymore. = Steps to reproduce Given the following three modules {{{#!hs module Extract where import Prelude hiding (mod) import Data.Generics import DynFlags import FastString import GHC import GHC.Paths import Control.Monad import Digraph (flattenSCCs) extractDocStrings :: IO [String] extractDocStrings = do concatMap (extract . pm_parsed_source . tm_parsed_module) <$> do runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags . setHaddockMode guessTarget "Foo.hs" Nothing >>= setTargets . return mods <- depanal [] False >>= enableCompilation let sortedMods = flattenSCCs (topSortModuleGraph False mods Nothing) mapM (parseModule >=> typecheckModule >=> loadModule) sortedMods where setHaddockMode :: DynFlags -> DynFlags setHaddockMode dynflags = (gopt_set dynflags Opt_Haddock) extract :: ParsedSource -> [String] extract m = [unpackFS s | HsDocString s <- everything (++) ([] `mkQ` return) m] enableCompilation :: ModuleGraph -> Ghc ModuleGraph enableCompilation modGraph = do let enableComp d = let platform = targetPlatform d in d { hscTarget = defaultObjectTarget platform } modifySessionDynFlags enableComp let upd m = m { ms_hspp_opts = enableComp (ms_hspp_opts m) } let modGraph' = map upd modGraph return modGraph' modifySessionDynFlags :: (DynFlags -> DynFlags) -> Ghc () modifySessionDynFlags f = do dflags <- getSessionDynFlags let dflags' = case lookup "GHC Dynamic" (compilerInfo dflags) of Just "YES" -> gopt_set dflags Opt_BuildDynamicToo _ -> dflags _ <- setSessionDynFlags (f dflags') return () }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Foo where import Bar -- | some documentation foo :: Int foo = $(bar) }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bar where bar = [|23|] }}} == Expected (GHC 7.10.2 behavior) {{{ $ ghci Extract.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help *Extract> extractDocStrings [" some documentation"] *Extract> :reload *Extract> extractDocStrings [" some documentation"] }}} == Actual (GHC 8.0.0.20160329 behavior) {{{ $ ghci Extract.hs GHCi, version 8.0.0.20160329: http://www.haskell.org/ghc/ :? for help *Extract> extractDocStrings [" some documentation"] *Extract> :reload *Extract> extractDocStrings /tmp/ghc24970_1/libghc_7.so: file not recognized: File truncated collect2: error: ld returned 1 exit status *** Exception: `gcc' failed in phase `Linker'. (Exit code: 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15065: T12903(profasm) produces a heap profile with out of sequence samples
by GHC 17 May '18

17 May '18

#15065: T12903(profasm) produces a heap profile with out of sequence samples -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: T12903(profasm) | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cd testsuite && make TEST="T12903" WAY="profasm" CLEANUP=0 ; cd .. [...] =====> T12903(profasm) 1 of 1 [0, 0, 0] cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/ghc-stage2" -o T12903 T12903.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto cd "./rts/T12903.run" && ./T12903 +RTS -hc -p -RTS cd "./rts/T12903.run" && "/home/alp/WT/ghc-slow-validate/inplace/test spaces/hp2ps" T12903 hp2ps error when processing heap profile for T12903 *** unexpected failure for T12903(profasm) [...] $ inplace/test\ \ \ spaces/hp2ps testsuite/tests/rts/T12903.run/T12903 hp2ps: testsuite/tests/rts/T12903.run/T12903.hp, line 9, samples out of sequence $ cat testsuite/tests/rts/T12903.run/T12903.hp JOB "T12903 +RTS -hc -p" DATE "Wed Apr 18 11:59 2018" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.004175 END_SAMPLE 0.004175 BEGIN_SAMPLE 0.000462 END_SAMPLE 0.000462 }}} This seems like an actual problem, completely unrelated to #12903, so I'm opening this ticket to track/fix this issue. I'll also mark T12903 as expected broken for the `profasm` way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature
by GHC 17 May '18

17 May '18

#15039: Bizarre pretty-printing of inferred Coercible constraint in partial type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | 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 GHCi session: {{{ $ ghci GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import Data.Type.Coercion λ> foo :: _ => Coercion a b; foo = Coercion <interactive>:2:8: error: • Found type wildcard ‘_’ standing for ‘Coercible a b :: TYPE ('GHC.Types.TupleRep '[])’ Where: ‘a’, ‘b’ are rigid type variables bound by the inferred type of foo :: Coercible a b => Coercion a b at <interactive>:2:27-40 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: _ => Coercion a b λ> :set -fprint-explicit-kinds λ> foo :: _ => Coercion a b; foo = Coercion <interactive>:4:8: error: • Found type wildcard ‘_’ standing for ‘(a :: *) ~~ (b :: *) :: TYPE ('GHC.Types.TupleRep ('[] GHC.Types.RuntimeRep))’ Where: ‘a’, ‘b’ are rigid type variables bound by the inferred type of foo :: ((a :: *) ~~ (b :: *)) => Coercion * a b at <interactive>:4:27-40 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: _ => Coercion a b }}} There are two things quite strange about this: 1. In both error messages, GHC claims that `Coercible a b`/`a ~~ b` has kind `TYPE (TupleRep '[])`. This is wrong, and should be `Coercible`. 2. For some reason, enabling `-fprint-explicit-kinds` causes the inferred constraint to be `(~~)` instead of `Coercible`, which is just plain wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13167: GC and weak reference finalizers and exceptions
by GHC 16 May '18

16 May '18

#13167: GC and weak reference finalizers and exceptions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: 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: -------------------------------------+------------------------------------- When GC runs a number of finalizers in a row, and the first of them throws an exception, then other finalizers are ignored. The relevant piece of code is [https://github.com/ghc/ghc/blob/fb4092642f057f258d07cd6979925f4e2579eda6/li… here]. The following program reproduces the issue: {{{ import Data.IORef import Control.Monad import Control.Exception import System.Mem main :: IO () main = do run run run run performMajorGC performMajorGC run :: IO () run = do ref <- newIORef () void $ mkWeakIORef ref $ do putStr "." throwIO $ ErrorCall "failed" }}} I expect it to output "....", but I get only "." The issue makes it unsafe to rely on finalizer for resource cleanup because unrelated finalizer (e.g. from some other library) may prevent your finalizer from running. Actually I was sure the issue is known, but today I tried to find a reference to it, and failed. If it is by design, then it should be documented somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9