April 2017 - ghc-tickets

[GHC] #12110: Windows exception handler change causes segfault with API Monitor
by GHC 26 Sep '17

26 Sep '17

#12110: Windows exception handler change causes segfault with API Monitor ----------------------------------------+---------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- [http://www.rohitab.com/apimonitor API Monitor] is a debugging tool that intercepts and logs calls to DLLs. It was extremely helpful with debugging #12010 and is broken in recent GHCs. Attaching it to a GHC compiled executable causes the message `Segmentation fault/access violation in generated code` to be printed. Launching one from inside API Monitor doesn't work either, though I can't read the console output before the window closes. Bisect shows the offending commit is 5200bdeb26 - "Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64". I know this is somewhat outside of "standard usage", but there are very few useful debugging tools for stuff like this and I'd really like to not lose this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11198: TypeInType error message regressions
by GHC 26 Sep '17

26 Sep '17

#11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- `TypeInType` causes error messages around certain kind errors to degrade. Here is the case: {{{ [W] (alpha :: k) ~ (Int :: *) }}} where `alpha` is a unification variable, `k` is a skolem, and there is no witness that `k ~ *`. The solver will simplify to {{{ [W] kco :: k ~ * [W] (alpha :: k) ~ (Int |> sym kco) }}} and then the latter, now homogeneous equality is solved by unification {{{ alpha := Int |> sym kco }}} This is all sound. But when reporting a kind error around `k` not equalling `*`, GHC likes to report the type error that the kind error came from. But, after zonking, the type error looks like `Int ~ Int`, when we drop coercions (as we tend to do in error messages). That's unfortunate. It affects test cases * T9196 * T8262 * T8603 * tcfail122 Simon has proposed a rule that should avoid this: never, ever use a wanted as a kind cast. That might work, but an attempt at implementing caused a loop when kind families were involved. I will keep pushing on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa)
by GHC 26 Sep '17

26 Sep '17

#12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I write in a signature: {{{ data Type = TArrow t1 t2 | TApp String [Type] }}} But it turns out that the real data type only has TApp (and uses "->" as the TyCon for TArrow). It would be nice if a pattern synonym could be used to implement this "concrete abstract data type" instead. Signature matching would have to typecheck the pattern synonyms against each other, and also check for totality. Note that in this example, App would need a guard against the Arrow case; otherwise the patterns overlap, whereas in the data type above it shouldn't matter what order the patterns go in. The converse might be useful too: {{{ data Type pattern TArrow :: Type -> Type -> Type pattern TInt :: Type }}} These patterns would be available for matching, with the assumption that they weren't total. If they were implemented directly using constructors, that should not be a problem. (In fact, do we even support abstract pattern synonyms?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13608: Expose the type of quasiquotes
by GHC 22 Sep '17

22 Sep '17

#13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: QuasiQuotes | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12778 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the context in which the quasiquote is used would allow to build the later variant. However, GHC provides no way to grab the type that it expects of the quasiquote. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(parseExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_<loc_hash> = $(parseExp java " 0.0 ") in __ghc_qq_<loc_hash> }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback about the proposal meanwhile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #8919: Why is xhtml library installed but not exported to users?
by GHC 20 Sep '17

20 Sep '17

#8919: Why is xhtml library installed but not exported to users? ------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC 7.8.1-rc2 installs the xhtml library, but doesn't export it, i.e. it's completely invisible to users. Is there a particular reason why this setup is necessary? If GHC needs that library internally anywhere, would it be possible to link it statically and *not* install it? Or, if that's not possible, if the library needs to be installed, please make it visible to users. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8919> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 27

[GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions
by GHC 19 Sep '17

19 Sep '17

#9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions. If successful, this would - allow to avoid the custom GMP allocator hack, and thus - avoid issues when linking against other C libraries using GMP, - simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now), - and finally maybe even remove a few more superfluous temporary heap allocations. This rewrite can be done incrementally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #13481: T12622 fails in ghci way
by GHC 19 Sep '17

19 Sep '17

#13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `T12622`, which is intended to test StaticPointers, fails in the GHCi way with a core lint warning, {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** <no location info>: warning: In the expression: >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a1DF) lvl_s3bD) lvl_s3bE s_a1DF :: StaticPtr (Bool -> Bool) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 70 0}] is out of scope *** Offending Program *** g :: Bool [LclIdX] g = break<15>() True $trModule_s3b7 :: Addr# [LclId] $trModule_s3b7 = "main"# $trModule_s3b6 :: TrName [LclId] $trModule_s3b6 = TrNameS $trModule_s3b7 $trModule_s3b9 :: Addr# [LclId] $trModule_s3b9 = "Main"# $trModule_s3b8 :: TrName [LclId] $trModule_s3b8 = TrNameS $trModule_s3b9 $trModule :: Module [LclIdX] $trModule = Module $trModule_s3b6 $trModule_s3b8 lvl_s3bj :: Addr# [LclId] lvl_s3bj = "error"# lvl_s3bk :: [Char] [LclId] lvl_s3bk = unpackCString# lvl_s3bj lvl_s3bl :: Addr# [LclId] lvl_s3bl = "main"# lvl_s3bm :: [Char] [LclId] lvl_s3bm = unpackCString# lvl_s3bl lvl_s3bn :: Addr# [LclId] lvl_s3bn = "Main"# lvl_s3bo :: [Char] [LclId] lvl_s3bo = unpackCString# lvl_s3bn lvl_s3bp :: Addr# [LclId] lvl_s3bp = "T12622.hs"# lvl_s3bq :: [Char] [LclId] lvl_s3bq = unpackCString# lvl_s3bp lvl_s3br :: Int [LclId] lvl_s3br = I# 21# lvl_s3bs :: Int [LclId] lvl_s3bs = I# 14# lvl_s3bt :: Int [LclId] lvl_s3bt = I# 21# lvl_s3bu :: Int [LclId] lvl_s3bu = I# 64# lvl_s3bv :: SrcLoc [LclId] lvl_s3bv = SrcLoc lvl_s3bm lvl_s3bo lvl_s3bq lvl_s3br lvl_s3bs lvl_s3bt lvl_s3bu lvl_s3bw :: ([Char], SrcLoc) [LclId] lvl_s3bw = (lvl_s3bk, lvl_s3bv) $dIP_s3bc :: CallStack [LclId] $dIP_s3bc = pushCallStack lvl_s3bw emptyCallStack lvl_s3bx :: Addr# [LclId] lvl_s3bx = "couldn't find "# lvl_s3by :: [Char] [LclId] lvl_s3by = unpackCString# lvl_s3bx lookupKey :: forall a. StaticPtr a -> IO a [LclIdX, Arity=1] lookupKey = \ (@ a_a23X) (p_X1DX :: StaticPtr a_a23X) -> break<8>(p_X1DX) >>= @ IO $fMonadIO @ (Maybe (StaticPtr a_a23X)) @ a_a23X (break<1>(p_X1DX) unsafeLookupStaticPtr @ a_a23X (break<0>(p_X1DX) staticKey @ a_a23X p_X1DX)) (\ (ds_d3as :: Maybe (StaticPtr a_a23X)) -> case ds_d3as of { Nothing -> break<7>(p_X1DX) error @ 'LiftedRep @ (IO a_a23X) ($dIP_s3bc `cast` (Sym (N:IP[0] <"callStack">_N <CallStack>_N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint))) (break<6>(p_X1DX) ++ @ Char lvl_s3by (break<5>(p_X1DX) show @ StaticPtrInfo $fShowStaticPtrInfo (break<4>(p_X1DX) staticPtrInfo @ a_a23X p_X1DX))); Just p_a1DI -> break<3>(p_a1DI) return @ IO $fMonadIO @ a_a23X (break<2>(p_a1DI) deRefStaticPtr @ a_a23X p_a1DI) }) $dTypeable_s3bA :: TypeRep Bool [LclId] $dTypeable_s3bA = mkTrCon @ * @ Bool $tcBool ([] @ SomeTypeRep) s_s3bC :: StaticPtr (Bool -> Bool) [LclId] s_s3bC = case break<9>() sg @ Bool ($dTypeable_s3bA `cast` (Sym N:Typeable[0] <*>_N <Bool>_N :: (TypeRep Bool :: *) ~R# (Typeable Bool :: Constraint))) of { T s_a38b -> s_a38b } lvl_s3bD :: IO (Bool -> Bool) [LclId] lvl_s3bD = lookupKey @ (Bool -> Bool) s_s3bC lvl_s3bE :: (Bool -> Bool) -> IO () [LclId] lvl_s3bE = \ (f_a1DG :: Bool -> Bool) -> break<12>(f_a1DG) print @ Bool $fShowBool (break<11>(f_a1DG) f_a1DG True) main :: IO () [LclIdX] main = break<14>() break<13>(s_s3bC) >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a1DF) lvl_s3bD) lvl_s3bE main :: IO () [LclIdX] main = runMainIO @ () main *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 ===== program output begins here ===== program output begins here T12622:6:30: error: Not in scope: ‘Main.main’ No module named ‘Main’ is imported. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13481> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13525: hWaitForInput with timeout causes program to abort
by GHC 19 Sep '17

19 Sep '17

#13525: hWaitForInput with timeout causes program to abort --------------------------------------+---------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 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: --------------------------------------+---------------------------------- This program, {{{#!hs import System.IO import System.Timeout main = hWaitForInput stdin (5 * 1000) }}} causes the program to abort (tested on Linux), {{{ $ ghc hi.hs [1 of 1] Compiling Main ( hi.hs, hi.o ) Linking hi ... $ ./hi fdReady: msecs != 0, this shouldn't happenAborted }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9157: cmm common block not eliminated
by GHC 19 Sep '17

19 Sep '17

#9157: cmm common block not eliminated ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For the toTuple# function (in the attached file) GHC generates a cmm switch statement, with all the alternatives, unsurprisingly, the same. Yet, cmm common block elimination does not kick in. In this particular example, the whole case statement could be annihilated, because all alternatives lead to the same code. BTW, this is how they match in France. {{{ #!ocaml type alt = A of int | B of int | C of int | D of int let g x = match x with A v | B v | C v | D v -> v }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs
by GHC 18 Sep '17

18 Sep '17

#9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Windows build over here spews a bunch of errors during the build like the ones below. All of them seem to be related to hsc2hs. The errors do not the build for some reason, so the problem is not critical, but we should look into what's going on here. Note that the errors are indeterministic and the set of files affected varies between builds. Examples: {{{ ghctrace.2/3.log:Failed to remove file libraries/base/dist- install/build/System/CPUTime_hsc_make.exe; error= DeleteFile "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- time/dist-install/build/System/Time_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": permission denied (Access is denied.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15