October 2014 - ghc-tickets

[GHC] #9442: Building GHC with Clang
by GHC 12 Nov '14

12 Nov '14

#9442: Building GHC with Clang -------------------------------------+------------------------------------- Reporter: conradwt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- How does one build GHC from scratch using Clang on OS X 10.9 and 10.10? At this time, I'm seeing the following message: $ ./configure checking for gfind... /opt/local/bin/gfind checking for sort... /usr/bin/sort checking for GHC version date... inferred 7.9.20140813 checking for ghc... no configure: error: GHC is required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9608: Type level as-patterns
by GHC 12 Nov '14

12 Nov '14

#9608: Type level as-patterns -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | 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: -------------------------------------+------------------------------------- Hello! I would love to see type level as-patterns in Haskell. They would be very helpfull when writing complex type families. Here is a good example: {{{ #!haskell type family XOut m1 m2 where XOut (ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env (ValueS vbase vs)) (XSet set (ValueS vbase vs)) m (XSafety s (ValueS vbase vs)) }}} could then be written as: {{{ #!haskell type family XOut m1 m2 where XOut a@(ValueS vbase vs) (MonadCtx2Dummy' m2 s2 env set m s) = MonadCtx2Dummy' m2 s2 (XEnv env a) (XSet set a) m (XSafety s a) }}} which is much cleaner, less verbose and lot safer then the first one. (Safer in terms of accidental typos when refactoring etc). Cheers, Wojciech -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9496: Simplify primitives for short cut fusion
by GHC 12 Nov '14

12 Nov '14

#9496: Simplify primitives for short cut fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there appear to be two production primitives, `build` and `augment` (although I may have missed some). There are multiple consumption primitives (at least: `foldr`, `head`, `and`, `or`, `any`, and `all`). The rule sets for some producers seem to forget to handle `augment`, and the `augment/augment` rule is omitted as "true, but not, I think, useful". A number of other functions are instead rewritten into `foldr` forms, and then written back if they don't fuse. == What to do: == Personally, I'd be very tempted to start by saying `build g = augment g []` (or ''possibly'' even `build g = extend [] g []` if I can ever get that idea to work) and cut the problem in half. The main problem I see with this is if other people are importing `GHC.Exts` or `GHC.Base`, writing things with `build`, and expecting them to fuse. One way to deal with this, perhaps, is to hack a special rule into the RULES compiler to recognize `GHC.Base.build` on the LHS of RULES and replace it with the appropriate `augment` form, emitting a warning. Where to go after that: the question remains whether it's best in general to rewrite a form to `foldr` to make it fuse, or to fuse directly with `augment`. The answer presumably depends, at least in part, on whether there are additional `foldr`-based rules we may want to add that would take advantage of the effort put into the translation back from the `foldr` form. I would conjecture that most such rules we could want would go beyond what the RULES system actually can do. That said, if we can find a way to use `foldr` forms without the horrible pain of translating back from them, that would be a very good thing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9496> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9594: Cleanup of filepath package
by GHC 11 Nov '14

11 Nov '14

#9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.9 Keywords: filepath | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8752 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I did a general cleanup/refactoring of the filepath package. Notable changes: * 10% less code * 2 tiny bug fixes * a few extra tests * some more documentation The commits are in my [https://github.com/thomie/filepath/commits/cleanup cleanup branch] on Github. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9621: New Data.Foldable methods
by GHC 11 Nov '14

11 Nov '14

#9621: New Data.Foldable methods -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9586 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- place-holder text; details to follow soon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9662: stack overflow in type checker
by GHC 11 Nov '14

11 Nov '14

#9662: stack overflow in type checker -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached program causes a stack overflow when loading into ghci-7.8.3 or ghci-7.9.20140929: {{{ $ ghci-7.8.3 -Wall BackpermuteTypeLoop.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling BackpermuteTypeLoop ( BackpermuteTypeLoop.hs, interpreted ) *** Exception: stack overflow }}} I have no idea, what's going on. The problem may be even not critical, because the program is not type-correct anyway. If you replace the `id` argument by the out-commented `modify` argument, you will get a nice type error message. The problem arised when using the Accelerate framework and it involves the `modify` function which helps tupling function arguments and untupling function results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output.
by GHC 11 Nov '14

11 Nov '14

#9077: Forcing the type to be IO {} instead of IO() causes a "panic! The impossible has happened" output. -------------------------+------------------------------------------------- Reporter: | Owner: Westycoot | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: x86 | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Below is the source code in which the bug occurs. It is easily reproduce- able, by having the type be IO{} instead of IO(). When ran, this code will produce the "panic! The impossible has happened" output. Which told me to report the bug here. By changing IO() to IO{} (which I did by accident), no exception is thrown, it simply tells the user to panic! {{{ main :: IO {} main = do e1 <- getLine e2 <- getLine print ((read e1) + (read e2)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8427: GHC accepts invalid program because of EPS poisoning
by GHC 10 Nov '14

10 Nov '14

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This naïve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8672: :browse and roles on typefamilies
by GHC 10 Nov '14

10 Nov '14

#8672: :browse and roles on typefamilies -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect Architecture: Unknown/Multiple | warning at compile-time Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- :browse on `ghci tests/ghci.debugger/scripts/T8557.hs` outputs a weird looking line: {{{ type role Sing nominal data family Sing (a :: k) type role T8557.R:Sing[]a nominal <-- data instance Sing a = SNil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9643: ghci must be restarted to use break point more than once?
by GHC 10 Nov '14

10 Nov '14

#9643: ghci must be restarted to use break point more than once? -------------------------------------+------------------------------------- Reporter: dsamperi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I set a break point (in main say) I stop there when I run the function, but if I run the function again the break point is ignored. Restarting ghci and resetting the break point makes it effective again, but this seems strange. Is this a bug or a feature? Also, when I run :trace after stopping at a break point, the remainder of the function is run, and :back complains that I cannot go backwards because I am not at a break point. Thanks, Dominick -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1