December 2018 - ghc-tickets

[GHC] #11534: Allow class associated types to reference functional dependencies
by GHC 22 Dec '18

22 Dec '18

#11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs class Foo i j | i -> j where type Bar i :: * type Bar i = j }}} This is rejected as `j` is not an argument to `Bar`, but when we realize any instance `j` will be a known type, determined by `i`, as told to us by the | i -> j functional dependency on the class. This would likely require some sort of extra pass over the instances with class associated types of this form to elaborate them, or a slight modification of the default signature implementation for class associated types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened
by GHC 21 Dec '18

21 Dec '18

#15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: type checker | Operating System: Unknown/Multiple plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the following, a plugin will receive a wanted constraint that includes a `fsk` flattening skolem. {{{ -- "Reduced" via the plugin type family F u v where {} type family G a b where {} data D p where DC :: (p ~ F x (G () ())) => D p }}} (Please ignore the apparent ambiguity regarding `x`; the goal is for the plugin to eliminate any ambiguity.) A do-nothing plugin that merely logs its inputs gives the following for the ambiguity check on DC. {{{ given [G] $d~_a4oh {0}:: (p_a4o2[sk:2] :: *) ~ (p_a4o2[sk:2] :: *) (CDictCan) [G] $d~~_a4oi {0}:: (p_a4o2[sk:2] :: *) ~~ (p_a4o2[sk:2] :: *) (CDictCan) [G] co_a4od {0}:: (G () () :: *) ~# (fsk_a4oc[fsk:0] :: *) (CFunEqCan) [G] co_a4of {0}:: (F x_a4o3[sk:2] fsk_a4oc[fsk:0] :: *) ~# (fsk_a4oe[fsk:0] :: *) (CFunEqCan) [G] co_a4og {1}:: (fsk_a4oe[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CTyEqCan) derived wanted [WD] hole{co_a4or} {3}:: (F x_a4o6[tau:2] fsk_a4oc[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CNonCanonical) untouchables [fsk_a4oe[fsk:0], fsk_a4oc[fsk:0], x_a4o3[sk:2], p_a4o2[sk:2]] }}} Note the `fsk_a4oc[fsk:0]` tyvar in the Wanted constraint, which is why I'm opening this ticket. Its presence contradicts the "The wanteds will be unflattened and zonked" claim from https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Callingpluginsfro… section. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8949: switch -msse2 to be on by default
by GHC 21 Dec '18

21 Dec '18

#8949: switch -msse2 to be on by default ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.9 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant. Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways. Flipping this default would also fix the excess precision problem for most users of GHC on the i686 platform. GHC should provide a -mno-sse2 flag for the cases when this needs to be disabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #16081: Clean up family instance consistency checking
by GHC 21 Dec '18

21 Dec '18

#16081: Clean up family instance consistency checking -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- There is a big mess concerning consistency checking for family instances. It's described in `Note [The type family instance consistency story]` in `FamInst`, which is reproduced below. Note in particular the "four subtle points that have not been addressed yet". The fourth one bit me today, and forced me to introduce a new hack into `loadIface`, described in `Note [Loading your own hi-boot file]` in `LoadIface`. Somehow we should be able to do better! {{{ {- Note [The type family instance consistency story] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To preserve type safety we must ensure that for any given module, all the type family instances used either in that module or in any module it directly or indirectly imports are consistent. For example, consider module F where type family F a module A where import F( F ) type instance F Int = Bool f :: F Int -> Bool f x = x module B where import F( F ) type instance F Int = Char g :: Char -> F Int g x = x module Bad where import A( f ) import B( g ) bad :: Char -> Int bad c = f (g c) Even though module Bad never mentions the type family F at all, by combining the functions f and g that were type checked in contradictory type family instance environments, the function bad is able to coerce from one type to another. So when we type check Bad we must verify that the type family instances defined in module A are consistent with those defined in module B. How do we ensure that we maintain the necessary consistency? * Call a module which defines at least one type family instance a "family instance module". This flag `mi_finsts` is recorded in the interface file. * For every module we calculate the set of all of its direct and indirect dependencies that are family instance modules. This list `dep_finsts` is also recorded in the interface file so we can compute this list for a module from the lists for its direct dependencies. * When type checking a module M we check consistency of all the type family instances that are either provided by its `dep_finsts` or defined in the module M itself. This is a pairwise check, i.e., for every pair of instances we must check that they are consistent. - For family instances coming from `dep_finsts`, this is checked in checkFamInstConsistency, called from tcRnImports. See Note [Checking family instance consistency] for details on this check (and in particular how we avoid having to do all these checks for every module we compile). - That leaves checking the family instances defined in M itself against instances defined in either M or its `dep_finsts`. This is checked in `tcExtendLocalFamInstEnv'. There are four subtle points in this scheme which have not been addressed yet. * We have checked consistency of the family instances *defined* by M or its imports, but this is not by definition the same thing as the family instances *used* by M or its imports. Specifically, we need to ensure when we use a type family instance while compiling M that this instance was really defined from either M or one of its imports, rather than being an instance that we happened to know about from reading an interface file in the course of compiling an unrelated module. Otherwise, we'll end up with no record of the fact that M depends on this family instance and type safety will be compromised. See #13102. * It can also happen that M uses a function defined in another module which is not transitively imported by M. Examples include the desugaring of various overloaded constructs, and references inserted by Template Haskell splices. If that function's definition makes use of type family instances which are not checked against those visible from M, type safety can again be compromised. See #13251. * When a module C imports a boot module B.hs-boot, we check that C's type family instances are compatible with those visible from B.hs-boot. However, C will eventually be linked against a different module B.hs, which might define additional type family instances which are inconsistent with C's. This can also lead to loss of type safety. See #9562. * The call to checkFamConsistency for imported functions occurs very early (in tcRnImports) and that causes problems if the imported instances use type declared in the module being compiled. See Note [Loading your own hi-boot file] in LoadIface. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16014: Avoid unnecessary code duplication from String Literals.
by GHC 21 Dec '18

21 Dec '18

#16014: Avoid unnecessary code duplication from String Literals. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When we compile a function like this: {{{ foo :: Int -> String foo 1 = "1_String" foo 2 = "2_String" foo 3 = "3_String" foo 4 = "4_String" foo 5 = "5_String" foo _ = "unknown_string" }}} We get a few things. Obviously there are the actual strings: {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} Foo.foo10 :: GHC.Prim.Addr# Foo.foo10 = "1_String"# }}} There is no way around these so that's fine. Then we end up with a function to unpack the actual string. {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} Foo.foo9 :: [Char] [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Foo.foo9 = GHC.CString.unpackCString# Foo.foo10 }}} We want to have a closure for each of these. Otherwise we end up constructing a new string each time, which would be a waste. So on the surface this is fine. However we end up with one of these for each string. Looking at the Cmm/Asm the functions are not THAT small. {{{ [Foo.foo9_entry() // [R1] { info_tbls: [(c2hj, label: Foo.foo9_info rep: HeapRep static { Thunk } srt: Nothing)] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2hj: // global if ((Sp + -16) < SpLim) (likely: False) goto c2hk; else goto c2hl; c2hk: // global R1 = R1; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; c2hl: // global (_c2hg::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1); if (_c2hg::I64 == 0) goto c2hi; else goto c2hh; c2hi: // global call (I64[R1])() args: 8, res: 0, upd: 8; c2hh: // global I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c2hg::I64; R2 = Foo.foo10_bytes; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; } } }}} In actual code size (HEAD/-O2) the code + info table is about 100Byte. To give an idea in my current ghc-stage2 I have 12,409 calls to unpackCString, and I assume 99% of them are from actual strings. So that comes out to about one megabyte. Out of a binary size of 84MB, so surprisingly significant actually! == Now what can we do about this! I think the right way to go here is to define a `unpackString` function which does the actual work. Then we jump into that from a small per-string wrapper. So we would end up with code like: {{{ [Foo.foo9_entry() // [R1] c2hj: // R1 = Closure pointer R2 = Foo.foo10_bytes; call (unpackString)(R1,R2) args: 8, res: 0, upd: 8; } }}} Which should be well under 50 bytes. It does cause an extra indirection when unpacking the String, but if the performance of that matters using String is likely the wrong choice to begin with. How to actually get GHC to generate code like that I'm not sure yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types
by GHC 21 Dec '18

21 Dec '18

#15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: TypeFamilies | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds #-} module A where data family D :: k type family F (a :: k) :: * type instance F (D Int) = Int type instance F (f a b) = Char type instance F (D Int Bool) = Char }}} The last equation, even though a specialization of the middle one, trips up the equality consistency check: {{{#!hs a.hs:9:15: error: Conflicting family instance declarations: F (D Int) = Int -- Defined at a.hs:9:15 F (D Int Bool) = Char -- Defined at a.hs:10:15 | 9 | type instance F (D Int) = Int | ^ }}} So GHC is able to infer that `D Int ~/~ f a b` because `D ~/~ f a`, but for some reason the same reasoning doesn't work for `D ~/~ D a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15192: Refactor of Coercion
by GHC 21 Dec '18

21 Dec '18

#15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- This patch aims at defining the new coercion rule {{{#!hs | EraseEqCo Role Type Type KindCoercion -- "e" -> _ -> _ -> N -> e }}} which corresponds to the typing rule {{{ t1 : k1 t2 : k2 |t1| = |t2| g : k1 ~ k2 ------------------------------------ EraseEqCo r t1 t2 g : t1 ~r t2 }}} Namely, if two types after erasure of casts and coercions are equivalent, then they can be casted from and to each other. This new coercion rule is designed to replace the current coherence rule {{{#!hs -- Coherence applies a coercion to the left-hand type of another coercion -- See Note [Coherence] | CoherenceCo Coercion KindCoercion -- :: e -> N -> e }}} The new rule is useful in several places. For example, now it is easier to define coercion {{{t |> k ~ t}}} without resorting to reflexivity coercion, and {{{t ~ t |> k}}} without resorting to symmetric rule. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15113: Do not make CAFs from literal strings
by GHC 21 Dec '18

21 Dec '18

#15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- Currently (as I discovered in #15038), we get the following code for `GHC.Exception.Base.patError`: {{{ lvl2_r3y3 :: [Char] [GblId] lvl2_r3y3 = unpackCString# lvl1_r3y2 -- RHS size: {terms: 7, types: 6, coercions: 2, joins: 0/0} patError :: forall a. Addr# -> a [GblId, Arity=1, Str=<B,U>x, Unf=OtherCon []] patError = \ (@ a_a2kh) (s_a1Pi :: Addr#) -> raise# @ SomeException @ 'LiftedRep @ a_a2kh (Control.Exception.Base.$fExceptionPatternMatchFail_$ctoException ((untangle s_a1Pi lvl2_r3y3) `cast` (Sym (Control.Exception.Base.N:PatternMatchFail[0]) :: (String :: *) ~R# (PatternMatchFail :: *)))) }}} That stupid `lvl2_r3y3 :: String` is a CAF, and hence `patError` has CAF- refs, and hence so does any function that calls `patError`, and any function that calls them. That's bad! Lots more CAF entries in SRTs, lots more work traversing those SRTs in the garbage collector. And for what? To share the work of unpacking a C string! This is nuts. What to do? * Somehow refrain from floating `unpackCSTring# lit` to top level, even if you could otherwise do so. But that seems very ad-hoc, and it make the function bigger and less inlinable. * Treat a top level definition {{{ x :: [Char] x = unpackCString# y }}} as NOT a CAF, and make it single-entry so that the thunk is not updated. Then every use of `x` will unpack the string afresh, which is probably a good idea anyhow. I like this more. It would be implemented somewhere in the code generator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #16028: tyThingCoAxiom panics while building Agda
by GHC 21 Dec '18

21 Dec '18

#16028: tyThingCoAxiom panics while building Agda -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-…) {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for arm-unknown-linux): tyThingCoAxiom Identifier ‘fromDescListWithKey’ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/main/HscTypes.hs:2153:32 in ghc:HscTypes Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The same version of Agda builds fine with ghc-8.4.3 on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-…) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16065: Stack squeezing during context switches makes for non-determinism in allocations
by GHC 21 Dec '18

21 Dec '18

#16065: Stack squeezing during context switches makes for non-determinism in allocations -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime | Version: 8.6.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #4450, #8861 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As #4450 and #8611 show, stack squeezing in the RTS makes allocation numbers between two different runs of the same binary non-deterministic, because its effect is depending on when context switches are bound to happen. A short-term solution might be to deactivate stack squeezing for vulnerable benchmarks with `+RTS -Z` like in Phab:D5460, but IMO a more elegant solution would be to only deactivate stack squeezing in `threadPause` calls that happen due to context switches. Would you agree? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11