March 2015 - ghc-tickets

[GHC] #10202: Weak inference when using rank-2 types and type families.
by GHC 27 Mar '15

27 Mar '15

#10202: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ‘b0’ with ‘Char’ ‘b0’ is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ‘f’, namely ‘k’ In the second argument of ‘const’, namely ‘(f k)’ }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10201: Weak inference when using rank-2 types and type families.
by GHC 27 Mar '15

27 Mar '15

#10201: Weak inference when using rank-2 types and type families. -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type inference does work as expected, when a rank-2 type has type-family constraint. Consider the following program: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} type family F a f :: (forall s. (F s ~ Int) => s -> b) -> b f _ = undefined k :: s -> Char k = undefined example :: Bool example = const True (f k) }}} It is rejected with the following error: {{{ Couldn't match type ‘b0’ with ‘Char’ ‘b0’ is untouchable inside the constraints (F s ~ Int) bound by a type expected by the context: (F s ~ Int) => s -> b0 at bug.hs:13:23-25 Expected type: s -> b0 Actual type: s -> Char In the first argument of ‘f’, namely ‘k’ In the second argument of ‘const’, namely ‘(f k)’ }}} This is unexpected because the result of `f` should be the same as the result of its parameter, and we know the exact type of the parameter, namely `Char`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception
by GHC 27 Mar '15

27 Mar '15

#8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: shadewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- See: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /System-IO-Error.html The description for IOError refers to module Control.Exception.Exception: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /Control-Exception-Exception.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9947: Unicode «other number» characters not consistently accepted in identifiers
by GHC 27 Mar '15

27 Mar '15

#9947: Unicode «other number» characters not consistently accepted in identifiers -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I’ve noticed that some characters classified as numeric by the Unicode standard will currently generate a lexical error. E.g., characters from the «enclosed alphanumerics» block don’t work, such as ① (circled digit one, U+2460), despite having being of the general Unicode category «other number». Usually, «other number» characters are accepted in identifiers. E.g., superscripts like «²» work fine. This is related to https://ghc.haskell.org/trac/ghc/ticket/5108 , where modifier letters (which are also alphanumeric in Unicode) also throw a lexical error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators
by GHC 27 Mar '15

27 Mar '15

#5108: Allow unicode sub/superscript symbols in both identifiers and operators -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Status: infoneeded Type: feature request | Milestone: 7.12.1 Priority: normal | Version: 7.1 Component: Compiler | Keywords: lexer (Parser) | unicode Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10196 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10196 Comment: Replying to [comment:16 thomie]: > {{{ > λ> let ᵤxᵤy = 1 > }}} > > GHC 7.10 follows Unicode standard 7.0, in which `'ᵤ'` (`'\x2b9'`) is in the `ModifierLetter` (Lm) general category, so that will no longer compile. Ticket #10196 intends to fix this regression, by allowing MODIFIERLETTER in identifiers after the first character. Comments welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5108#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans
by GHC 27 Mar '15

27 Mar '15

#9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there is a comment on `dep_orphs` claiming this: {{{ , dep_orphs :: [Module] -- ^ Orphan modules (whether home or external pkg), -- *not* including family instance orphans as they -- are anyway included in 'dep_finsts' }}} However, it is not difficult to discover that this is not true: {{{ [ezyang@hs01 ghc-quick]$ cat A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a :: * [ezyang@hs01 ghc-quick]$ cat B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Int = Bool [ezyang@hs01 ghc-quick]$ cat C.hs module C where import B [ezyang@hs01 ghc-quick]$ inplace/bin/ghc-stage2 --show-iface C.hi | grep orphans orphans: GHC.Base GHC.Float B }}} I'm not sure if the comment or the implementation is wrong. Certainly `TcRnDriver` would not work if we removed type family orphans from the list, because we only currently load `imp_orphans` and not `imp_finsts`. This change occured in this commit: {{{ commit 8f212ab5307434edf92c7d10fe0df88ccb5cd6ca Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu May 26 14:30:15 2011 +0100 Rejig the way in which generic default method signatures are checked - Check GenericSig in tcClassSigs, along with TypeSig - Add the generic default methods to the type envt - Look them up via tcLookupId in TcClassDcl.tcDefMeth Much nicer! diff --git a/compiler/typecheck/TcRnDriver.lhs b/compiler/typecheck/TcRnDriver.lhs index 2542ad3..5aa6959 100644 --- a/compiler/typecheck/TcRnDriver.lhs +++ b/compiler/typecheck/TcRnDriver.lhs @@ -245,7 +245,6 @@ tcRnImports hsc_env this_mod import_decls -- interfaces, so that their rules and instance decls will be -- found. ; loadOrphanModules (imp_orphs imports) False - ; loadOrphanModules (imp_finsts imports) True -- Check type-familily consistency ; traceRn (text "rn1: checking family instance consistency") }}} When did we start adding type family orphans to the list? This commit is to blame (it states that modules with type family orphans are orphans, which means that it will get added to orphan module list in `RnNames` when we import the interface: {{{ commit 98a642cf29781ebd33994a4ecbea6ef07f89bbed Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jan 3 10:35:08 2012 +0000 Major refactoring of CoAxioms @@ -619,7 +620,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls mi_exp_hash = export_hash, mi_orphan_hash = orphan_hash, mi_flag_hash = flag_hash, - mi_orphan = not (null orph_rules && null orph_insts + mi_orphan = not ( null orph_rules + && null orph_insts + && null orph_fis && null (ifaceVectInfoVar (mi_vect_info iface0))), mi_finsts = not . null $ mi_fam_insts iface0, mi_decls = sorted_decls, @@ -631,12 +634,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls this_mod = mi_module iface0 dflags = hsc_dflags hsc_env this_pkg = thisPackage dflags - (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) - (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) - -- See Note [Orphans] in IfaceSyn - -- ToDo: shouldn't we be splitting fam_insts into orphans and - -- non-orphans? - fam_insts = mi_fam_insts iface0 + (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) + (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) + (non_orph_fis, orph_fis) = mkOrphMap ifFamInstOrph (mi_fam_insts iface0) fix_fn = mi_fix_fn iface0 }}} I think this is probably a legitimate optimization (keeps interface file smaller), and we try to put it back into effect. The only downside is we'll try to load in the entire `mi_fam_insts` list (mostly harmless sense redundant requests on that front will hit the cache); also, it's more elegant if mi_orph describes orphanness over all orphans. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #8034: Missing ambiguity test for class methods
by GHC 26 Mar '15

26 Mar '15

#8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Perhaps. I haven't checked HEAD, only my branch, which was not rebased on HEAD for the last couple of weeks. If this is fixed we probably need a regression test before we close this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8034#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8030: FlexibleContexts PolyKinds Type Families bug
by GHC 26 Mar '15

26 Mar '15

#8030: FlexibleContexts PolyKinds Type Families bug -------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8034 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Fixed in HEAD, probably in commit f66e0e695b0377c469fbe877d4850fc0ebca2010: {{{ Author: Simon Peyton Jones <> Date: Wed Mar 4 11:59:47 2015 +0000 A raft of small changes associated with -XConstrainedClassMethods See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes }}} Now always shows the same ambiguity error. Needs a regression test before closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8030#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8034: Missing ambiguity test for class methods
by GHC 26 Mar '15

26 Mar '15

#8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): This is fixed in HEAD already, isn't it? The example from the description gives an ambiguity error at least. See the following commit for details: In f66e0e695b0377c469fbe877d4850fc0ebca2010: {{{ Author: Simon Peyton Jones <> Date: Wed Mar 4 11:59:47 2015 +0000 A raft of small changes associated with -XConstrainedClassMethods See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8034#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8034: Missing ambiguity test for class methods
by GHC 26 Mar '15

26 Mar '15

#8034: Missing ambiguity test for class methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): I looked at the code today to see if I can fix this together with #6018. A quick diagnosis is that the type of class operation is stripped from the foralls and thetas so that only tau remains (in Simon's example the type `foo :: forall (k :: BOX) (a :: k). C a => F a -> F a` is stripped to `F a -> F a`). This tau is passed to ambiguity check but since there are no quantified variables the ambiguity check always succeeds. I wonder what would be the right strategy here: 1. In `TcTyClsDecls.checkValidClass` call `checkValidType` (inside `check_op`) with some type other than `tau`. I tried a quick hack to add the forall variables back to tau (ie. the original type of class operation is stripped only from thetas) but there are some corner cases where this does not work. 2. Modify the first case of `TcValidity.check_type` to look for type variables under type family applications even if these variables are not quantified. I'm not sure which of these two is the right way of fixing this so I didn't try too hard to implement any of these. If anyone with more knowledge can hint me which of these to would be the right way of fixing this I think I should be able to write a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8034#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0