- ghc-tickets - Haskell.org

[GHC] #12532: Remove sum and tuple names from knownKeyNames
by GHC 14 Oct '16

14 Oct '16

#12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- As noted in ticket:12415#comment:5 there are a large number of names inhabiting `knownKeyNames` and therefore the original name cache due to tuples and sums. It shouldn't be so hard to remove these and handle them in an ad-hoc manner: * original name cache lookups (e.g. finding out the `Name` associated with an `OccName`) can been handled by parsing the `OccName`'s string * looking up the `Name` associated with a `Unique` (which is needed in `BinIface` during interface file deserialization) can be done with a set of static functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12415: Fancy BinIface encoding for tuples is broken for constraint tuples
by GHC 14 Oct '16

14 Oct '16

#12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12357 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We have a special way of encoding tuple-related names in the interface file symbol table. See `Note [Symbol table representation of names]`. However, it was broken for constraint tuples by ffc21506894c7887d3620423aaf86bc6113a1071. The problem is very similar to the one which prevented us from encoding tuple type representations in #12357 (see ticket:12357#comment:31). By unwiring constraint tuples it becomes harder to identify them for special handling during serialization. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12415> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12705: Renamer should reject signatures that reexport only part of a declaration
by GHC 14 Oct '16

14 Oct '16

#12705: Renamer should reject signatures that reexport only part of a declaration -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following signature is bogus, and also, unfortunately, accepted by GHC at the moment: {{{ signature A(f) where data T = MkT { f :: Bool } }}} This doesn't make any sense at all. We should reject it early. It can lead to very strange errors (see bkpreex05 in tree) but happily it is fairly easy to avoid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12705> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12053: Mode for ghc --make which only compiles the files I pass on command line
by GHC 14 Oct '16

14 Oct '16

#12053: Mode for ghc --make which only compiles the files I pass on command line -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: backpack | 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 are a few situations where GHC picks up "too many" files when running `--make`: * Suppose a user doesn't add enough modules to `exposed-modules`/`other- modules` in Cabal. GHC will happily pick up extra source files, but those files won't get bundled in the `sdist` or be included in ABI computation. Difficult for Cabal to tell when this has happened. * Suppose the user wants to define multiple internal libraries, and give them the same hs-source-dir. This won't work: because GHC sees the source file it will prefer it over the external dependency. There's a very easy thing that GHC could do to make this better: add a mode to `--make` which says "only compile the files that are explicitly passed on the command line." Something like `ghc --make --only A.hs` will only build A.hs, and error if you try to import B.hs. Seems like this should be fairly easy to do, and would help solve a lot of problems related to GHC slurping up too many files. (I've assigned myself because this is a blocker for backpack, but if someone wants to take a crack at this be my guest.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10798: Signatures with only types should not be included in unit keys
by GHC 14 Oct '16

14 Oct '16

#10798: Signatures with only types should not be included in unit keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: ⊥ Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose we want to modularize the dependence on `p` in this program: {{{ unit p where module A where data T = T mkT = T unit q where include p module B where import A bar = mkT }}} The obvious signature to write for `A` is: {{{ signature A where data T mkT :: T }}} But this presupposes an implementation of `A` which exports `T`. But `B` doesn't use any export of `T`, and an equally valid implementation would be if `T` was defined in some `Types` module and then imported here. But suppose we change our signature to be: {{{ signature A.Types where data T signature A where import A.Types mkT :: T }}} This is maximally general, but requires that the module which exports `T` be named `A.Types`. If someone puts the type anywhere else, we have to rename the signature to the real place it was defined, or make a dummy implementation module which reexports the type in question. Now there is a curious thing, which is that the choice of module we use to fill these extra signature modules currently influences the type identity of anything else in the unit. But we never rely on any code from these signatures: if I make two distinct dummy modules to set `T` to the same type, this really shouldn't have any impact (at all!) on the code generated. So, my suggestion is that if a signature contains only types (perhaps they could be named something else, like `tysignature`), they should not count towards the calculation of a unit key. This means that a user can freely create dummy modules to fill in these types when they are instantiating; all that is being done is helping Backpack figure out what the identities of types are. (If we wanted to be fancy, Backpack could even look inside type signatures to determine some types, but let's not go there for now.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9717: More lazy orphan module loading
by GHC 14 Oct '16

14 Oct '16

#9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: backpack | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, when we import a module, we eagerly load all of the orphan modules transitively reachable from it (TcRnDriver:tcRnImports). This is a bit of bummer: as module import hierarchies get deeper and deeper, we'll collect more and more orphan instances and load more and more modules eagerly. The idea is to try to arrange for an orphan module not to be loaded, unless we think that it might have a relevant instance. Instead of just recording a list of orphan modules transitively reachable from a module, we will also record a digest of what type classes and types the orphan provides instances for. (This will be similar to the data we record for `ifInstTys` in `IfaceClsInst`.) Now, when we do any operation involving instances, we check and see if there are also orphans which could provide relevant instances (based on the digest) and load those. If an instance could never have been used, we avoid loading its interface file entirely. This doesn't appear to help too much for type families, where we have to load all of the instances anyway in order to check for consistency. A choice to make: Should we record just the class, or also the types involved? It would be best if we could quickly conclude that there are no more instances to load, but this may be difficult if matching against types as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12660: singletons doesn't compile with GHC 8.0.2 snapshot
by GHC 14 Oct '16

14 Oct '16

#12660: singletons doesn't compile with GHC 8.0.2 snapshot -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- The current state of the `ghc-8.0` branch (a24092ff501028ca1245b508320493f394378495) apparently fails to compile the `singletons` library, yet 8.0.1 and `master` work fine. The compiler appears to loop. See https://github.com/goldfirere/singletons/issues/162#issuecomment-251272894. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 14 Oct '16

14 Oct '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Phab:D2592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2592 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:61> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12689: DataCon wrappers get in the way of rules
by GHC 14 Oct '16

14 Oct '16

#12689: DataCon wrappers get in the way of rules -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 is a spin-off of https://ghc.haskell.org/trac/ghc/ticket/12618#comment:25: Simon writes there: Actually this is already a problem today. It's just rendered more prominent now that even `(:)` has a wrapper. Consider {{{#!hs data T = MkT {-# UNPACK #-} !Int {-# RULES "fT" f MkT = True "gT" forall x. g (MkT x) = x #-} f :: (Int -> T) -> Bool {-# NOINLINE f #-} f x = True g :: T -> Int {-# NOINLINE g #-} g (MkT x) = x+1 }}} yields {{{ Foo.hs:9:1: warning: [-Winline-rule-shadowing] Rule "fT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' Foo.hs:10:1: warning: [-Winline-rule-shadowing] Rule "gT" may never fire because 'Foo.$WMkT' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'Foo.$WMkT' }}} What to do? If we are to match these rules, we really must delay inlining the wrapper for `MkT` (after inlining we get a mess of unboxing etc). So either we must allow you to add a `NOINLINE` pragma to `MkT`; or we must add one automatically (e.g. `NOINLINE [1]`). Delaying all consructor-wrapper inlining to phase 1 is potentially quite drastic, because case-of-known-constructor wouldn't happen until the wrappers are inlined. Maybe that's ok; I'm not sure. Worth trying I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12456: Panics when making a quotation as pattern synonym
by GHC 13 Oct '16

13 Oct '16

#12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -XPatternSynonyms -XViewPatterns -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> pattern A :: ExpQ; pattern A <- (undefined -> ()) where A = undefined ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): nameModule system $dIP_a4HS Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Language.Haskell.TH> }}} should we be able to use quotations that are pattern synonyms? I have no use for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12456> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4