January 2018 - ghc-tickets

[GHC] #11735: Optimize coercionKind
by GHC 20 Apr '18

20 Apr '18

#11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Currently, the `ForAllCo` case of `coercionKind` does an inefficient one- variable substitution. This could be improved by looking for nested `ForAllCo`s. Furthermore, perhaps we don't need an in-scope set and the full substitution machinery here. The subst is simply propagating the update of a tyvar's kind. No structural changes at all. No need for smart coercion constructors or other processing. So if we're going to optimize this, it might be worth making a specialized version of `subst_ty` and `subst_co` that operate over a `VarEnv Var` instead of a full substitution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 87

[GHC] #13380: raiseIO# result looks wrong
by GHC 20 Apr '18

20 Apr '18

#13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `primops.txt.pp` includes the following note: > `raiseIO#` needs to be a primop, because exceptions in the `IO` monad must be ''precise'' - we don't want the strictness analyser turning one kind of bottom into another, as it is allowed to do in pure code. > > But we ''do'' want to know that it returns bottom after being applied to two arguments, so that this function is strict in `y` > {{{#!hs > f x y | x>0 = raiseIO blah > | y>0 = return 1 > | otherwise = return 2 > }}} I believe the "But we do" portion is, unfortunately, entirely wrong. From a user perspective, it is extremely strange to replace a precise exception with an imprecise one. That is, I strongly believe the above code should be considered ''lazy'' in `y`. The function `f` calculates an `IO` action; the value of `y` is only necessary to calculate that action if `x` is non- positive. We can, conservatively, say for certain that the second component of the result of `raiseIO#` (i.e., the "return value") is bottom. We can also say, given {{{#!hs case raiseIO# e s of (# s', r #) -> q }}} that `q` is dead (we could replace it by `(# s', undefined #)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13276: Unboxed sums are not Typeable
by GHC 20 Apr '18

20 Apr '18

#13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While the Typeable machinery introduce in the type-indexed Typeable rework (#11011) is fully capable of representing unboxed sums, we currently don't allow this since it would require that we generate an enormous number of bindings in `GHC.Types`. This is because we need to generate both `TyCon` and `KindRep` bindings for each type constructor and its promoted data constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13261: Consider moving Typeable evidence generation wholly back to solver
by GHC 20 Apr '18

20 Apr '18

#13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | 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: -------------------------------------+------------------------------------- Since 91c6b1f54aea658b0056caec45655475897f1972 we have generated a set of bindings with each datatype definition which the compiler will refer to when constructing `Typeable` evidence. As described in the commit message, this came with a rather significant performance penalty, especially given that it is paid regardless of whether the code being compiled uses `Typeable`. The type-indexed Typeable implementation (#11011) augments these bindings with additional information allowing the kind of a type of be reconstructing at runtime (#10343). Unfortunately, this further blows up the cost of associated with Typeable binding generation. Some of the testsuite regressions are hard to swallow to say the least. While I'm still working out what can be done to reduce this cost, I do wonder whether the generating these bindings at the time of type definition is so wise. Relatively few users make use of Typeable and the cost is not negligible. Moreover, generating bindings for families of tycons (e.g. unboxed sums, which have thousands of type constructors and promoted data constructors) all at once produces a truly massive amount of code (albeit it only has to be done once). On the other hand, I suppose if Richard's dependent types story comes to fruition then perhaps the weight imposed by generating Typeable bindings at type-definition time might pull its weight. Anyways, just idle reflections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13450: Better parse error for empy character literal
by GHC 19 Apr '18

19 Apr '18

#13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature | Status: new request | Priority: normal | 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: -------------------------------------+------------------------------------- Empty character literals give an obscure error message. As an example, this code: {{{#!hs example = foo : bar where foo = '' bar = "asdf" }}} gives the following error when loaded in GHCi: {{{ err.hs:4:6: parse error (possibly incorrect indentation or mismatched brackets) }}} This has affected me once, as a beginner. I've seen it affect a few other beginners, and the error message isn't very helpful to figuring out what's wrong. It would be nice if a better error message could be reported. If there's a parse error on `''`, then GHC could report something like: {{{ err.hs:3:11: parse error on `''`. Note: Character literals may not be empty. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10037: Several profiling tests give different results optimised vs. unoptimised
by GHC 19 Apr '18

19 Apr '18

#10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Profiling | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket. The following tests in `tests/profiling/should_run` are affected: {{{ scc001 T2552 ioprof callstack001 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds
by GHC 19 Apr '18

19 Apr '18

#14710: GHC 8.4.1-alpha allows the use of kind polymorphism without PolyKinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 (Type checker) | Keywords: PolyKinds | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Data.Coerce import Data.Proxy class C a b where c :: Proxy (x :: a) -> b newtype I a = MkI a instance C x a => C x (Bug.I a) where c = coerce @(forall (z :: x). Proxy z -> a) @(forall (z :: x). Proxy z -> I a) c }}} is rightfully rejected by GHC 8.2.2: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:20:16: error: Unexpected kind variables Perhaps you intended to use PolyKinds In a type argument | 20 | c = coerce @(forall (z :: x). Proxy z -> a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:21:16: error: Unexpected kind variables Perhaps you intended to use PolyKinds In a type argument | 21 | @(forall (z :: x). Proxy z -> I a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But GHC 8.4.1-alpha2 actually //accepts// this program! {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180118: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. }}} This is almost certainly bogus. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14689: Load order of .ghci config files is counterintuitive
by GHC 19 Apr '18

19 Apr '18

#14689: Load order of .ghci config files is counterintuitive -------------------------------------+------------------------------------- Reporter: hal9zillion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14250, #6017 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Basically ghci seems to give precedence to global .ghci conguration settings by applying them after any local/project specific .ghci files: https://github.com/ghc/ghc/blob/314bc31489f1f4cd69e913c3b1e33236b2bdf553/gh… OTOH there are a couple of open issues where people dont like the idea of local ghci evaluation for security reasons: #6017 #14250 I suggest the following resolution: - Change the order or evaluation from global first to local - include a new ghci setting that prevents/enables the evaluation of local/project specific .ghci files for people who wish to avoid the security concerns some people have - This flag can then be set in the global .ghci file I believe this would both address the counterintuitive loading strategy implied currently (i was convinced local .ghci files didnt work because when i changed the prompt it was always overwritten by my global config) and the security question. The only question then would be if evaluation of project/local .ghci files would be on or off by default. I would favour the former but that is just personal preference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop
by GHC 17 Apr '18

17 Apr '18

#12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a deriving (C b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12860> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files
by GHC 17 Apr '18

17 Apr '18

#9074: GHC 7.8.2's ghci does not track missing symbols when loading non-Haskell object files ------------------------------------+------------------------------------- Reporter: massysett | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a package that bundles in C library sources. I never had a problem with this when using GHC 7.6. In GHC 7.8, the order of the c-sources in the cabal file now matters. Sources must be listed earlier if they have symbols that subsequently loaded object files will need. If the c-sources are in the wrong order, when running "cabal repl" I get Loading object (static) dist/build/decnumber/src/decQuad.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14294_0/ghc14294_1.so: undefined symbol: DECSTICKYTAB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug When using the same code and cabal file with GHC 7.6, "cabal repl" works fine: GHCi loads each static object (regardless of ordering in the cabal file), links up the necessary symbols, and launches successfully. Haskell Cafe discussion here: http://www.haskell.org/pipermail/haskell-cafe/2014-May/114041.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6