March 2018 - ghc-tickets

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

[GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion
by GHC 16 May '18

16 May '18

#8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------------+------------------------------- Reporter: merijn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: patch | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Due to an unsafe coercion in GHC.Event.Poll.poll the implementation has a bug that on some platforms (.e.g. linux) results in subtly wrong semantics and on other platforms (e.g. OS X) downright crashes the runtime. The offending line is line 95 in GHC/Event/Poll.hsc: {{{ c_poll ptr (fromIntegral len) (fromIntegral (fromTimeout tout)) }}} `fromTimeout` returns a timeout in seconds as a value of type Int. `c_poll` takes a timeout in seconds as a value of type CInt. If the max value of Int is larger than that of CInt, this coercion results in an overflow, producing a negative value. The faulty semantics are in turn caused by passing this negative value as timeout to `c_poll`. This overflow happens on many 64bit platforms where GHC's Int is 64bit, but CInt is often 32bit. The result of passing a negative value to poll() depends on the platform, but is (on all platforms I checked) different from the desired semantics! On linux any negative timeouts are treated as infinite, this means that a poll() with a timeout that should be finite results in an infinitely blocking poll on linux! On OSX any negative timeout other than -1 (which is treated as infinity) is considered an invalid parameter, returning an error and crashing the runtime. A minimal example reproducing the error (on systems where `fromIntegral (maxBound :: Int) > (fromIntegral (maxBound :: CInt) :: Integer)`): {{{ import Control.Concurrent main = threadDelay maxBound }}} Using 64bit GHC on OSX this produces an immediate runtime crash. The attached patch solves the issue by comparing the Int timeout against the max value of CInt and, if necessary, looping multiple `c_poll` calls (with a timeout equal to `maxBound :: CInt`) if they return `0` (which indicates the timeout has expired with no events occurring). See also: https://github.com/merijn/packages- base/commit/6d8ea02a3f6a2cdb82a9ad786a8c4db780b92091 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12012: Socket operations on Windows check errno instead of calling WSAGetLastError()
by GHC 15 May '18

15 May '18

#12012: Socket operations on Windows check errno instead of calling WSAGetLastError() -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: Libraries | Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well. The upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010). Here's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en- us/library/windows/desktop/ms740121%28v=vs.85%29.aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14697: Redundant computation in fingerprintDynFlags when compiling many modules
by GHC 15 May '18

15 May '18

#14697: Redundant computation in fingerprintDynFlags when compiling many modules -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 profiled a build of a production code base with thousands of modules and computing `fingerprintDynFlags` is `7%` of time and `14%` of allocations. Here's a synthetic test case inspired by what I observed: {{{ SIZE=1000 for i in $(seq -w 1 $SIZE); do echo "module A$i where" > A$i.hs echo "data A$i = A$i" >> A$i.hs done }}} This generates a 1000 modules each with one datatype. Compiling them with: {{{ inplace/bin/ghc-stage2 A*.hs -optP-D__F{1..10000}__ }}} results in `fingerprintDynFlags` being the top cost centre in the profile. AFAICT there's only one module dependent piece that goes into computing `fingerprintDynFlags` and the rest is the same between those 1000 modules. Now, why would I have so many preprocessor flags? This is how the Buck build system currently works. If a Haskell library depends on a C++ library then the GHC invocation gets the C++ library's directory as include path (`-optP-I -optP-I some/library/path`). This can grow quite big. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12463: SPECIALIZABLE pragma?
by GHC 14 May '18

14 May '18

#12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Inlining | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. If we include an `INLINEABLE` pragma (as most performance-aware authors would do) then we can convince GHC to produce an unfolding, but only at the expense of lowering its inlining cost as well. This is unfortunate since we never wanted GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALIZE forall a. LibraryFunction a #-} }}} This would request that GHC would keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, it would try to minim -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12463> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21