June 2015 - ghc-tickets

[GHC] #10098: Refactor wild card renaming
by GHC 31 Jul '15

31 Jul '15

#10098: Refactor wild card renaming -------------------------------------+------------------------------------- Reporter: | Owner: thomasw thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #9922 Test Case: | Blocking: | Differential Revisions: Phab:D613 | -------------------------------------+------------------------------------- Imported from #9922, comment #5: --------------------- Austin: let's merge this to 7.10.1. Thomas: I'm not very happy with the way that wild-card error reporting is done. I think we discussed this before, but left it on one side until it was all working. Which it now is. What I suggest is this: Things I dislike: * I dislike the `checkParitalTypeSignature` and `checkNoPartialType` stuff in `RdrHsSyn`. The only checks that belong in `RdrHsSym` are ones that prevent you building a syntax tree at all. All other checks are best done later, when good error reporting is easier, and you can recover from errors. * I particularly hate the `RnTypes.extractWildcards` stuff. It's like a whole extra renaming pass over the type, changing `HsWildCardTy` to `HsNamedWildCardTy` with an `Exact` `RdrName` in it. Yuk! Here is a possible plan: * Remove all the checking from `RdrHsSyn`, unless we can't build a syntax tree without it. * Collapse `HsWildcardTy` and `HsNamedWildcardTy` into one, with a boolean (or a `Named`/`Anonymous` flag) to distinguish. * Provide a specialised version of `rnLHsType`, perhpas `rnLHsTypeWithWildCards`, that does the inital pass to find the named wildcards and bring them into scope. This version is called in the places where you can have a type with wildcards, namely * `TypeSig` * `ExprWithTySig` * `rnHsBndrSig` * `rnLHsTypeWithWildCards` can work like this: 1. Collect all the named wildcards, and bring them into scope. This is a simple, ''pure'' function. 2. Call `rnLHsType`. When `rnLHsType` finds an anonymous wildcard, just make up a fresh name, rather than looking it up. 3. Collect all the wildcards (named or anonymous) to get a `[Name]`; again a pure function 4. Return the renamed type and the wildcard names That makes three passes, but each is simple. In fact (1) and (4) could perhaps be the same function, with a boolean flag to say which wildcards to return. * All this means that when `rnLHsType` is called directly (not via `rnLHsTypeWithWildCards`) on a type like `_ -> Int`, it will succeed, generateing a fresh name for the `_`. That's fine. In `tc_hs_type` we will find it is not in scope, so we can say "Unexpected wildcard in type", and the enclosing location information will nail down the details. * There are, I think, three places where `HsWithBndrs` is used: `HsDecls.HsTyPats`, `HsDecls.RuleBndr`, `HsPat.SigPatIn`. In the latter two I think that wildcards should be legal; in the first not so. (Do you have tests for all three?) So the caller of `rnHsBndrSig` should check for empty wildcards in the cases where there shouldn't be any. I this this is just in type/data family patterns. I have not throught throught the extra-constraints wild card, but I think a similar plan should work. Does this make sense? Might you do it? (To HEAD, of course.) Thanks Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9230: Make -fwarn-tabs the default
by GHC 31 Jul '15

31 Jul '15

#9230: Make -fwarn-tabs the default -------------------------------------------+------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Tabs trip up an awful lot of Haskell beginners. Turning the warning on by default will likely save them a lot of grief. Any insane^h^h^h^h^h^hexperienced Haskellers who like tabs will have no trouble disabling the warning in their pragmas. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #9070: "Simplifier ticks exhausted"
by GHC 31 Jul '15

31 Jul '15

#9070: "Simplifier ticks exhausted" ----------------------------------+------------------------------------- Reporter: dermesser | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I know nothing more than what GHC said (I'm on debian, installed from the repositories). {{{ (GHC version 7.6.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:GHC.Base.$fMonadIO_$c>>={v rJ2} [gid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 31764 }}} The code triggering the error is the code commented out in lines 52-54: {{{ 42 redis_family_raw <- getEnv redisFamilyVar 43 redis_addr <- getEnv redisAddressVar 44 redis_port <- getEnv redisPortVar 45 46 (family,redis_family) <- case (parseFamily family_raw,parseFamily redis_family_raw) of 47 (Just fam, Just rfam) -> return (fam,rfam) 48 x -> fail $ "Unknown address family: " ++ show x 49 50 sockaddr <- getSockAddr family broker_address broker_port_raw 51 52 --redis_conn <- case redis_family of 53 -- WAFamilyInet -> R.connect $ defaultConnectInfo { connectHost = redis_addr, connectPort = Service redis_port } 54 -- WAFamilyUnix -> R.connect $ defaultConnectInfo { connectPort = UnixSocket redis_addr } }}} However, this bug occurs only when compiling with cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9227: Coverage Condition cannot be turned off
by GHC 31 Jul '15

31 Jul '15

#9227: Coverage Condition cannot be turned off ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compile this program {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} module Bug1 where class C a b | a -> b data A a = A data B a = B instance C (A a) (B b) }}} and observe the error message {{{ Bug1.hs:9:10: Illegal instance declaration for `C (A a) (B b)' The coverage condition fails in class `C' for functional dependency: `a -> b' Reason: lhs type `A a' does not determine rhs type `B b' In the instance declaration for `C (A a) (B b)' }}} Then read manual, sec 7.6.3.3: {{{ Both the Paterson Conditions and the Coverage Condition are lifted if you give the -XUndecidableInstances flag }}} Compile again with -XUndecidableInstances. Observe the exact same error message. Either the compiler or the documentation is wrong. I certainly hope it is the compiler, because it worked in 7.6 and was quite useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9227> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8253: example "Core syntax" is ancient
by GHC 31 Jul '15

31 Jul '15

#8253: example "Core syntax" is ancient -------------------------------------+------------------------------------- Reporter: rwbarton | 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: | -------------------------------------+------------------------------------- [http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/options- debugging.html#idp39365504 User's guide section 4.19.5] has some funky "Core syntax" that (according to git blame) dates back to at least 2000, and probably longer ago than that. It could use an update. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails
by GHC 31 Jul '15

31 Jul '15

#8151: ghc-7.4.2 on OpenIndiana (Solaris) createSubprocess fails ----------------------------+-------------------------------------------- Reporter: troydm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Keywords: | Operating System: Solaris Architecture: x86 | Type of failure: Runtime performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------------------------- when i'm compiling this test.hs with ghc -thread ./test.hs and then execute it i get Starting Subprocess Exit code: ExitFailure 127 This error code indicates that command isn't found (i have ghc in /usr/local/bin) and it's specified in PATH variable, however it acts as if it's not even there however if i remove -threaded flag and recompile code again, it works Starting Subprocess ghc: no input files Usage: For basic information, try the `--help' option. Exit code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10467: user's guide description of "foreign export" is out of date
by GHC 31 Jul '15

31 Jul '15

#10467: user's guide description of "foreign export" is out of date -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The first sentence of section 8.2.1 is > When GHC compiles a module (say M.hs) which uses foreign export or foreign import "wrapper", it generates two additional files, M_stub.c and M_stub.h. GHC will automatically compile M_stub.c to generate M_stub.o at the same time. This is false at least for registerised builds, GHC produces an object file directly and its filename is `M.o` not `M_stub.o`. (I don't know what happens in the unregisterised case, but if the final object file name is actually different, that seems inconsistent.) The rest of the section makes similar references to the nonexistent `M_stub.c` and `M_stub.o`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10467> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10523: Add Monoid instance for IO
by GHC 31 Jul '15

31 Jul '15

#10523: Add Monoid instance for IO -------------------------------------+------------------------------------- Reporter: Gabriel439 | Owner: Type: feature | Status: new request | Milestone: 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: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is to add the following `Monoid` instance for `IO`: {{{#!hs instance Monoid a => Monoid (IO a) where mempty = pure mempty mappend = liftA2 mappend }}} I originally proposed this instance on the libraries mailing list a while ago: https://mail.haskell.org/pipermail/libraries/2014-November/024310.html ... and the proposal was well-received so I would like to contribute the instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9114: Invalid UTF8 not round-tripped correctly
by GHC 31 Jul '15

31 Jul '15

#9114: Invalid UTF8 not round-tripped correctly ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As reported by Robert Bihlmeyer at http://bugs.debian.org/748125, the promised round-tripping of invalid UTF8 sequences in filenames through String does not work: ``` $ mkdir foo $ touch foo/$(echo -e '\xC0\xB7.txt') $ ghc -e 'System.Directory.getDirectoryContents "foo" >>= print . last' "7.txt" ``` The sequence 0xC8B7 is an (invalid) encoding of 37, i.e. `'7'`, so if it is mapped to `'7'`, no round-tripping is possible. (Other invalid byte sequences are round-tripped.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9385: Additions to Control.Monad
by GHC 31 Jul '15

31 Jul '15

#9385: Additions to Control.Monad -------------------------------------+------------------------------------- Reporter: olf | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.8.2 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'd like to propose the following additions/changes to Control.Monad: `mfilter` can be generalised: {{{#!hs gen_mfilter :: Monad m => (a -> m ()) -> m a -> m a gen_mfilter f ma = (\a -> liftM (const a) (f a)) =<< ma }}} Now we obtain the old `mfilter` as {{{#!hs gen_mfilter.(guard.) }}} Further, `m ()` is a monoid for every monad, which would cause conflicts for `[()]`, to name one example. (The usual monoid instance of `[()]` is addition of natural numbers, while the monadic monoid instance is multiplication.) More generally, the monoid `m ()` acts on every type `m a` in the following way: {{{#!hs mtimes :: Monad m => m () -> m a -> m a mtimes = gen_mfilter.const = liftM2 (flip const) when = mtimes.guard }}} For example, each element of a list can be duplicated like this: {{{#!hs mtimes [(),()] }}} To see why these functions are useful, consider the `DDist` monad of the ProbabilityMonads package: Since `DDist ()` is essentially the monoid of real numbers with multiplication, `gen_mfilter f` updates a distribution by multiplying the weight of `x` by `f x`. Another example is the state monad `ST s`, where type `(a -> ST s ())` is essentially `a -> s -> s`, so these functions encode changes that, when used with `gen_mfilter` alter state, not the value. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3