October 2015 - ghc-tickets

[GHC] #11014: re-order GHC type errors for clarity
by GHC 25 Nov '15

25 Nov '15

#11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Here's a typical simple type error from GHC: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ }}} The order of sections is "couldn't match", "expected actual", "relevant bindings", "context" (in the second argument etc.). I think it would be easier to read as "couldn't match", "expected actual", "context", "bindings", and with a * to mark each section: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) }}} I'm sure there are plenty of other sections that don't show up in this simple example, in any case they should go from most to least critical and be marked off with a *. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10483: Refactor HsForAllTy
by GHC 24 Nov '15

24 Nov '15

#10483: Refactor HsForAllTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I got sucked into refactoring `HsForAllTy`, like this: {{{ data HsType name = HsForAllTy (HsForAll name) (LHsType name) | ... data HsForAll name -- The quantifiers of a HsForAllTy = HSF { hsf_flag :: HsExplicitFlag , hsf_extra :: Maybe SrcSpan , hsf_qtvs :: LHsTyVarBndrs name , hsf_ctxt :: LHsContext name } }}} This makes a number of functions neater, as well as naming the fields of a troublesomely-high-arity data constructor. This ticket is here to track progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10483> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11000: Implement `-Wcompat`
by GHC 24 Nov '15

24 Nov '15

#11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: Design/Warnings -------------------------------------+------------------------------------- Currently we have only the following generic warning "levels": {{{ -W enable normal warnings -w disable all warnings -Wall enable almost all warnings (details in ) }}} It would be useful to be able to refer collectively to all currently implemented forward-compatibility warnings (e.g. about upcoming changes in `base`, like `-fwarn-amp`) via a symbolic `-Wcompat` flag. This way, users have more flexibility in opt-in or out of such warnings. So e.g. the following settings are possible in `.cabal` files: `ghc-options: -Wall` :: enable "almost all warnings" as before. Some compat warnings maybe part of `-Wall`, some won't (yet). `ghc-options: -Wall -Wcompat` :: enable "almost all warnings" as well as all implemented warnings. E.g. if GHC 8.0 implements `-fwarn-mfp-compat` but doesn't include it in `-Wall`, this allows users to get notified asap about warnings to opt into that `ghc-options: -Wall -Wno-compat` :: This enables `-Wall` **minus** any future-compat warnings. This is for users who want to be warned at all about any future compat warnings. `ghc-options: -Wcompat` :: Of course, `-W(no-)compat` can be used also w/o `-Wall`, and then is equivalent to turning on/off the respective individual `-fwarn-*-compat` flags. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10656: Ability to get stack traces from Haskell code
by GHC 23 Nov '15

23 Nov '15

#10656: Ability to get stack traces from Haskell code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Tarrasch Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #3693 Test Case: | Blocking: | Differential Revisions: Phab:D963 | -------------------------------------+------------------------------------- With the merge of Phab:D169 and Phab:D396 (included in GHC 7.10.1) GHC now has the ability to produce DWARF debugging information in compiled binaries. It would be nice if Haskell programs could request stack backtraces from the RTS. Tarrasch has some work in this direction in Phab:D963 however there are a number of questions that remain outstanding, * do we want to rely on an external library for parsing DWARF information? If so, how do we address portability concerns? * What should the Haskell-land interfaces look like? Writing down some concrete use-cases would help here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10824: Let-bindings of kind # are processed backwards
by GHC 21 Nov '15

21 Nov '15

#10824: Let-bindings of kind # are processed backwards -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this module: {{{ {-# LANGUAGE MagicHash #-} import GHC.Exts main = do let x = error "bar" :: Int# y = error "foo" :: Int# print (I# x + I# y) }}} When you run this, you will get the error "foo" and not the error "bar". This is backwards! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10666: Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts
by GHC 21 Nov '15

21 Nov '15

#10666: Distinguish between semantic module / identity module in TcGblEnv, ModIface and ModGuts -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When we write a signature like {{{ package p where signature H where data T }}} and compile it to an interface file, there are two ways we might say what the `Module` of this interface is: 1. The **identity module** uniquely identifies an interface file, and is used for dependency analysis and tracking. In the example above, the identity module is `p(H -> HOLE:H):H`. 2. The **semantic module** tells us what the `Name`s of the entities defined in the module are supposed to be; e.g., it's used for generating new names when type-checking hs files or interfaces. In the example above, the semantic module is `hole:H`, since this signature exports one entity named `hole:H.T`. The semantic module can always be derived from the identity module. For normal Haskell modules, the semantic and identity module coincide. However, for signatures they differ: we may have many signatures for the same module; they all share their semantic module but have differing identity modules. By in large, when GHC manipulates `Module` directly it is interested in the identity module. However, when a `Module` is used with reference to a `Name` (primarily `nameIsLocalOrFrom`), we want to use the SEMANTIC module. (Another example: when we filter out the type environment before making a `ModIface`, need to filter against the semantic module.) I tried a few ways of factoring GHC's code so we'd be less likely to confuse these two `Module`s when typechecking signatures: the big problem is if you're adding a `getModule` call to `TcRn`, you're probably not going to think too hard whether or not you actually wanted the semantic module or the identity module. But if you pick the wrong thing that will break all sorts of things for signatures. Here are some things we could do: 1. My initial attempt was to change `tcg_mod`, `mg_module` and `mi_module` to record a new data type `TopModule` which recorded both the semantic and identity module, with `getModule` in `TcRn` continuing to return a semantic module, but `mi_module` returning an identity module. However, the resulting patch was pretty ugly and it's not altogether clear that `getModule` returning the semantic module is always correct. 2. My other idea is to say that these entries always are IDENTITY modules (this will result on fail fast behavior for signatures if you get it wrong), and then rewrite `nameIsLocalOrFrom`, `externaliseAndTidyId`, `initIfaceTcRn`, `newGlobalBinder` so that they always do the right thing (i.e. use the semantic module); thus, the only time you can get it wrong is if you're creating some new functionality that's not these functions that needs to use semantic modules. Pretty delicate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports
by GHC 21 Nov '15

21 Nov '15

#10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Here are two issues with our GHCi support for foreign prim imports: Here is a program that works: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Word# -> State# RealWorld -> (# State# RealWorld, Word# #) }}} If I remove the world token passing, as in here: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Word# -> Word# }}} I get: {{{ (GHC version 7.10.1 for x86_64-unknown-linux): ByteCodeGen.generateCCall: missing or invalid World token? }}} Another error is if I try to pass Any as an argument: {{{ {-# LANGUAGE GHCForeignImportPrim, MagicHash, UnliftedFFITypes, UnboxedTuples #-} module Serum where import GHC.Exts foreign import prim "cheneycopy" cheneycopy :: Any -> State# RealWorld -> (# State# RealWorld, Word# #) }}} Then I get: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): primRepToFFIType }}} Note to anyone who is running into this problem: an easy workaround is to use `-fobject-code` which bypasses bytecode generation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9651: Increasing verbosity doesn't give useful information for why we couldn't load package
by GHC 21 Nov '15

21 Nov '15

#9651: Increasing verbosity doesn't give useful information for why we couldn't load package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I don't time to fix this now, so recording so I remember. {{{ [ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3 Using binary package database: /home/hs01/ezyang/ghc- head/inplace/lib/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) [ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) [ezyang@hs01 ghc-nocode]$ /home/hs01/ezyang/ghc-head/inplace/bin/ghc- stage2 -package-key ghc_GE0xPzNsQzT2p10hpwDwSW --interactive -package-db libraries/bootstrapping.conf -v GHCi, version 7.9.20140929: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 7.9.20140929, stage 2 booted by GHC version 7.8.3 Using binary package database: /home/hs01/ezyang/ghc- head/inplace/lib/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: <command line>: cannot satisfy -package-key ghc_GE0xPzNsQzT2p10hpwDwSW (use -v for more information) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9651> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8079: Redo T7919 with a cabal file
by GHC 21 Nov '15

21 Nov '15

#8079: Redo T7919 with a cabal file -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Right now T7919 fails because the new dynamic-by-default GHC means that Template Haskell must be built with dynamic; of course, GHC isn't clever enough to figure this out. If we Cabalize the test, the example should start building again (and if they don't, well, that's a bug!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8199: Get rid of HEAP_ALLOCED
by GHC 21 Nov '15

21 Nov '15

#8199: Get rid of HEAP_ALLOCED ----------------------------------------------+---------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- This bug is to track progress of removing HEAP_ALLOCED from GHC, promising faster GC, as long as we can keep the cost of indirections down. The relevant wiki article: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced ; we are implementing method 2. The attached patchset is *almost* able to support GHC itself; a ghc-stage2 built this way can compile most files, but is much slower in some cases, and probably has some correctness bugs. Improvements possible: * Don't pay for a double indirection when -fPIC is turned on. Probably the easiest way to do this is to *not* bake in the indirections into compiled code when it is -fPIC'd, and instead scribble over the GOT. However, I don't know how to go backwards from a symbol to a GOT entry, so we might need some heinous assembly hacks to get this working. * Closure tables should have their indirections short-circuited by the initialization code. * We are paying an indirection when a GC occurs when the closure is not in R1. According to the wiki page, technically this is not needed, but I don't know how to eliminate references to the closure itself from stg_gc_fun. * Properly handle the Windows DLL case (e.g. SRTs); this should be simpler now that everything is an indirection. * Bikeshed hs_main API changes (because closures are not valid prior to RTS initialization, so you have to pass in an indirection instead) * Improve static indirection and stable pointer registration, avoiding binary bloat from `__attribute(constructor)__` stubs. * Need to implement a new megablock tracking structure so we can free/check for lost blocks -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8199> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 52