- ghc-tickets - Haskell.org

[GHC] #10200: Documentation not built for base
by GHC 29 Mar '15

29 Mar '15

#10200: Documentation not built for base -------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- None of the modules from the base package appear in the documentation that shipped with the binary distribution. I am looking at share/doc/ghc/html/libraries/index.html and no modules from base are in there. This is the binary distribution for 64-bit Linux that I downloaded from haskell.org, although I also had this same problem when I built rc3 from source using GHC 7.8 on Mac OS X. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10200> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10198: Build failure on Solaris/SPARC due to misaligned data access (bus error)
by GHC 29 Mar '15

29 Mar '15

#10198: Build failure on Solaris/SPARC due to misaligned data access (bus error) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Building of GHC 7.10.1 fails on Solaris/SPARC platform with: {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.12.1.1 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP- DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package-key Cabal_HWT8QvVfJLn2ubvobpycJY -package-key array_FaHmcBFfuRM8kmZLEY8D5S -package-key base_I5BErHzyOm07EBNpKBEeUv -package-key bytes_6vj5EoliHgNHISHCVCb069 -package-key conta_47ajk3tbda43DFWyeF3oHQ -package-key deeps_FpR4obOZALU1lutWnrBldi -package-key direc_3TcTyYedch32o1zTH2MR00 -package-key filep_5HhyRonfEZoDO205Wm9E4h -package-key ghc_IS8uiRKDTo1CRjcMAZsBb8 -package-key trans_ALYlebOVzVI4kxbFX5SGhm -package-key xhtml_0mVDYvYGgNUBWShvlDofr1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user- package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- library/vendor/attoparsec-0.12.1.1/Data/Attoparsec/Number.hs -o utils/haddock/dist/build/Data/Attoparsec/Number.dyn_o gmake[1]: *** [utils/haddock/dist/build/Data/Attoparsec/Number.dyn_o] Bus Error (core dumped) gmake: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

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

28 Mar '15

#10203: 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: {{{#!hs {-# 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/10203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

28 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 28 Mar '15

28 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