April 2013 - ghc-tickets

[GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 13 Apr '13

13 Apr '13

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -----------------------------+---------------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.4.2 | Keywords: recursive modules, boot files, double vision, double vision problem Os: Unknown/Multiple | Architecture: x86_64 (amd64) Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- In a recursive module (i.e. a module that transitively imports itself), the unique "Name" of an entity E declared in this module's boot file should be precisely the same as that of the corresponding E defined in the module. Right now GHC appears to treat them as separate entities. (In the module systems literature, this problem has been identified as the "double vision problem" [1, Ch 5] and in general has caused problems with implementations of recursive modules. Derek Dreyer and his coauthors have proposed a number of solutions [2], and so have Im et al. more recently in the context of OCaml [3].) With that being said, the ''immediate'' problem here seems to be that GHC does not actually allow, in the implementing module, the import of its boot file's entities. There are a couple related errors I can identify with, huzzah!, very small example programs. The crux of the example is that the module A defines a data type T which is essentially the typical Nat data type -- except that the recursive type reference in the successor constructor refers to the "forward declaration's" view of the type (in the boot file) rather than the local view of that data type T. This first example shows that the boot file import is not actually making available the entities it declares: {{{ module A where data T }}} {{{ module A where import {-# SOURCE #-} qualified A as Decl(T) data T = Z | S Decl.T }}} The Decl.T reference should have the exact same identity as the locally defined T reference; after tying the module knot, this data type should be the same as if we had defined it with a T instead of Decl.T. However, the entity name T does not even appear to be gotten from the import of the boot file: {{{ A.hs:3:18: Not in scope: type constructor or class `Decl.T' }}} In an earlier version of GHC I tested, 6.12.1, the error message lies on the import statement: {{{ A.hs:2:44: Module `A' (hi-boot interface) does not export `T' }}} In the next example, with the same boot file, we see that the mechanism that checks whether the implementation matches the boot file fails to see the two "views" of T as the same. (Note that I changed the definition of T here to make the previous error go away.) {{{ module A(Decl.T(..)) where import {-# SOURCE #-} qualified A as Decl(T) data T = Z | S T }}} Since Decl.T should point to the same entity as T, the export statement should have the same effect as if it were instead "(T(..))". However, GHC again cannot make sense of the reference "Decl.T" and then complains that the boot file's T is not provided in the implementation: {{{ A.hs:1:10: Not in scope: type constructor or class `Decl.T' <no location info>: T is exported by the hs-boot file, but not exported by the module }}} (Making the export list empty shows this second error message only.) Altering this second example by omitting the alias on the import, and by changing the T reference in the type's definition to A.T, results in a well-typed module: {{{ module A(A.T(..)) where import {-# SOURCE #-} qualified A(T) data T = Z | S A.T }}} A final example shows that, in a module that is ''not'' the implementing module, entities defined in the boot file are imported as one would expect! In the following example, we insert a module B, in between A's boot file and A's implementation, which merely passes along the boot file's view of T. {{{ module A where data T }}} {{{ module B(Decl.T(..)) where import {-# SOURCE #-} qualified A as Decl(T) data U = U Decl.T }}} {{{ module A(T(..)) where import qualified B(T) data T = Z | S B.T }}} The error message here, again, lies in the reference B.T in A's implementation: {{{ A.hs:3:18: Not in scope: type constructor or class `B.T' Perhaps you meant `A.T' (line 3) }}} Notice, however, that the reference to Decl.T in the B module is perfectly well-formed. I suspect that the general problem lies with double vision, and that the more immediate problem--whereby imports of boot file entities from their implementing modules fail--is merely the manifestation of that. In the above, wherever I have suggested an intended semantics, I refer primarily to the state of the art in recursive modules systems. A perhaps more pressing justification, however, is that both the Haskell language report and Diatchki et al.'s specification of the module system [4] (seem to) corroborate that intended semantics. Your friend in the recursive module swamp,[[BR]] Scott Kilpatrick ---- References [1] Derek Dreyer. ''[http://www.mpi-sws.org/~dreyer/thesis/main.pdf Understanding and Evolving the ML Module System]'', PhD thesis, 2005.[[BR]] [2] Derek Dreyer. ''[http://www.mpi- sws.org/~dreyer/courses/modules/dreyer07.pdf A Type System for Recursive Modules]'', ICFP 2007.[[BR]] [3] Hyeonseung Im, Keiko Nakata, Jacques Garrigue, and Sungwoo Park. ''[http://dl.acm.org/citation.cfm?doid=2048066.2048141 A syntactic type system for recursive modules]'', OOPSLA 2011.[[BR]] [4] Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. ''[http://web.cecs.pdx.edu/~mpj/pubs/hsmods.html A formal specification of the Haskell 98 module system]'', Haskell 2002. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7660: warning: conflicting types when compiling via-C
by GHC 13 Apr '13

13 Apr '13

#7660: warning: conflicting types when compiling via-C -----------------------------+---------------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: warning Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I don't think this is actually a problem per-se, but usually these warnings are indicative of unsafe assumptions being made: {{{ when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc7162_0/ghc7162_0.hc:1164:1: warning: conflicting types for built-in function 'memchr' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:6885:1: warning: conflicting types for built-in function 'memset' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:8594:1: warning: conflicting types for built-in function 'memcpy' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:11521:1: warning: conflicting types for built-in function 'free' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:11522:1: warning: conflicting types for built-in function 'realloc' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:12038:1: warning: conflicting types for built-in function 'malloc' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:13583:1: warning: conflicting types for built-in function 'strlen' [enabled by default] /tmp/ghc7162_0/ghc7162_0.hc:13994:1: warning: conflicting types for built-in function 'memcmp' [enabled by default] }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 13 Apr '13

13 Apr '13

#7670: StablePtrs should be organized by generation for efficient minor collections -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Currently, stable pointers are all in one giant pointer table (see markStablePtrTable); this results in pretty bad GC behavior when you create a lot of stable pointers (Peaker has a test-case which he thinks is suffering due to repeated traversal of the stable pointers list.) We should partition them up into generations like we do for mutable lists. There might be some trickiness keeping the table up-to-date after GCs. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7669: Empty case causes warning
by GHC 13 Apr '13

13 Apr '13

#7669: Empty case causes warning ----------------------------------------------+----------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: EmptyCase Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- The following code {{{ {-# LANGUAGE EmptyCase #-} {-# OPTIONS_GHC -fwarn-incomplete-patterns #-} data Void foo :: Void -> () foo x = case x of {} }}} causes this warning {{{ /Users/rae/temp/Scratch.hs:6:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: Ok, modules loaded: Main. }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7668: Location in -fdefer-type-errors
by GHC 13 Apr '13

13 Apr '13

#7668: Location in -fdefer-type-errors -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider {{{ x :: Char x = 'x' + 1 y :: Char y = 'y' + 1 }}} Run `ghci -fdefer-type-errors`: {{{ *Main> x *** Exception: G.hs:5:9: No instance for (Num Char) arising from a use of `+' In the expression: 'y' + 1 In an equation for `y': y = 'y' + 1 (deferred type error) *Main> y *** Exception: G.hs:5:9: No instance for (Num Char) arising from a use of `+' In the expression: 'y' + 1 In an equation for `y': y = 'y' + 1 (deferred type error) }}} The first exception is wrong. It seems that the missing `Num Char` instance is filled with the same error message in all places where the constraint should be supplied. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7667: Template Haskell fails to recognize type operator/function +
by GHC 13 Apr '13

13 Apr '13

#7667: Template Haskell fails to recognize type operator/function + --------------------------------------+------------------------------------- Reporter: andygill | Owner: Type: bug | Status: new Priority: normal | Component: Template Haskell Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- The following message is issued for a valid TH program. {{{ Main.hs:7:1: Illegal type constructor or class name: `+' When splicing a TH declaration: type instance GHC.TypeLits.+ 1 2 = 3 Failed, modules loaded: Test1. }}} Code attached. The program is attempting to capture the name +, as used by Nat at the type level. The problem appears to be in Convert.hs {{{ -- Convert.hs okOcc :: OccName.NameSpace -> String -> Bool okOcc _ [] = False okOcc ns str@(c:_) | OccName.isVarNameSpace ns = startsVarId c || startsVarSym c | otherwise = startsConId c || startsConSym c || str == "[]" }}} + is rejected, by okOcc, even though it is acceptable, the symbol neither starts with upper-case, or ':'. I have tried using reify to extract the *actual* name from other sources (rather than use mkNameG_tc), and it fails in the same way. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7484: Template Haskell allows building invalid record fields/names
by GHC 13 Apr '13

13 Apr '13

#7484: Template Haskell allows building invalid record fields/names ---------------------------------+------------------------------------------ Reporter: iustin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Template Haskell | Version: 7.6.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by igloo): See also #7667 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7484#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs
by GHC 13 Apr '13

13 Apr '13

#7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Component: libraries/pretty Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I was running into serious performance problems when printing moderately sized Doc and Xml data (HaXml goes via Doc). Since pretty is shipped with ghc, this is potentially dangerous. Users will just assume that these core components are tried and tested, and working efficiently. More info: http://article.gmane.org/gmane.comp.lang.haskell.cafe/103210 See also: http://stackoverflow.com/questions/9761507/which-pretty-print-library Test case (builds an Xml tree with HaXml and renders it via the pretty library): https://github.com/jwaldmann/haskell-tpdb/blob/master/test/speed.hs -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7665: dynamicToo001 fails on Windows
by GHC 13 Apr '13

13 Apr '13

#7665: dynamicToo001 fails on Windows ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ `dynamicToo001` fails on Windows: {{{ =====> dynamicToo001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory dynamicToo001 </dev/null >dynamicToo001.run.stdout 2>dynamicToo001.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Makefile:12: recipe for target `dynamicToo001' failed Stderr: A001.dyn_o:fake:(.text+0x2e): undefined reference to `__imp_stg_CAF_BLACKHOLE_info' A001.dyn_o:fake:(.text+0x5f): undefined reference to `__imp_newCAF' A001.dyn_o:fake:(.text+0x72): undefined reference to `__imp_stg_bh_upd_frame_info' A001.dyn_o:fake:(.text+0x87): undefined reference to `__imp_ghczmprim_GHCziTypes_Czh_con_info' c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: A001.dyn_o: bad reloc address 0x0 in section `.data' c:/ghc64/git/cygwin/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Invalid operation collect2: ld returned 1 exit status make[2]: *** [dynamicToo001] Error 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7659: Add some latency nofib benchmarks
by GHC 13 Apr '13

13 Apr '13

#7659: Add some latency nofib benchmarks -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Component: NoFib benchmark suite Version: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- At the moment, GHC is heavily throughput oriented (e.g. scheduler choices, etc). However, applications like Cloud Haskell often would like to reduce latency, even if it is at the cost of some throughput. However, we have no good way of measuring when changes to the RTS improve latency. We should add some benchmark programs along these lines. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7659> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1