November 2015 - ghc-tickets

[GHC] #8245: ghc-pkg list prints packages in non-alphabetical order
by GHC 07 Dec '15

07 Dec '15

#8245: ghc-pkg list prints packages in non-alphabetical order ------------------------------------+------------------------------------- Reporter: nh2 | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Instead, it prints the ones with the smallest version first. That does not make much sense. I will attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8245> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names
by GHC 07 Dec '15

07 Dec '15

#10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to help @mpickering with Phab:D1258, I looked at the code in `tcRnSrcDecls` and was surprised to see that exports are renamed after this function is complete. This didn't make any sense to me. And, indeed, it's wrong, witness by this example: {{{ {-# OPTIONS_GHC -fwarn-missing-exported-sigs #-} module Bug (Data.List.intercalate, x) where import qualified Data.List intercalate = True x :: Bool x = intercalate }}} This produces {{{ Bug.hs:7:1: Warning: Top-level binding with no type signature: intercalate :: Bool }}} This warning should not be emitted. I'm not all that concerned about this scenario biting in the wild, but it suggests that refactoring this code is a good thing, and not something Phab:D1258 should take pains to avoid. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11028: Refactor ConDecl
by GHC 07 Dec '15

07 Dec '15

#11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ‘::’ , con_doc :: Maybe LHsDocString , con_old_rec :: Bool } | ConDeclH98 { con_name :: Located name , con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer , con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any) , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T` * `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type) * The `con_old_rec` is a warning thing for GADTs (see current source code) This ticket is just to track the thought and invite feedback. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #9015: A documented way to differentiate between statements, declarations, imports, etc.
by GHC 07 Dec '15

07 Dec '15

#9015: A documented way to differentiate between statements, declarations, imports, etc. -------------------------------------+------------------------------------- Reporter: splinterofchaos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Moderate (less | bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- I'm working on a little REPL and the GHC API seems to supply two functions for evaluating one line, without compiling and evaluating into an `HValue`, which doesn't seem to have an `Outputable` instace: `runStmt` and `runDecls`. As it turns out, I need slightly different code to run on declarations verses statements, so this makes sense, but given a random string from the user, how can I tell the difference? I don't see anything in the documentation about this. I took a look at ghci's source (https://github.com/ghc/ghc/blob/a6f2c852d49313fa8acea2deb3741ab86c6ef995/gh…] and it looks like they just peek at the first word of the input, and that may be correct and sufficient, but impossible to verify without looking at Haskell's grammar. But even if I did verify it, that doesn't make explicit the difference between what `runDecls` and `runStmt` will accept. For a contrived example, consider if GHC implemented a feature that allowed for a new type of decl. It might be enabled by a language extension which means that testing whether a string is a statement or declaration cannot be done purely as we have to check the dynflags. Furthermore, the client may not be aware of the extension and thus send the input to `runStmt` instead. It would seem to me that requiring the user to manually parse the input violates separation of concerns since truly GHC knows best what source GHC will accept. The user should not have to examine the input except for if they need to modify or interpret it as something other than Haskell source code. The GHC API should either document an example function for differentiating declarations from statements (and even import statements), supply one itself, or supply several along the lines of `isDecl, isStmt, isImport :: String -> Bool`. This would improve ease-of-use by making client code more obvious and correct. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11128: New `-fwarn-noncanonical-monad-instances` warning
by GHC 06 Dec '15

06 Dec '15

#11128: New `-fwarn-noncanonical-monad-instances` warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Priority: normal | 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: -------------------------------------+------------------------------------- placeholder -- I needed a ticket number; will flesh out description asap -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9706: New block-structured heap organization for 64-bit
by GHC 05 Dec '15

05 Dec '15

#9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | 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: -------------------------------------+------------------------------------- I was having some discussion about GHC's block structured heap with Sergio Benitez and Adam Belay, and during the discussion it was suggested that the way GHC manages the block structured heap is suboptimal when we're on 64-bit architectures. At the moment, we allocate memory from the operating system per-megablock, storing metadata in the very first megablock. We have to do this because, on 32-bit, we can't generally be too picky about what address our memory ends up living. On 64-bits, we have a lot more flexibility. Here is the proposal: 1. Statically decide on a maximum heap size in a power of two. 2. Next, probe for some appropriately aligned chunk of available virtual address space for this. On POSIX, we can mmap /dev/null using PROT_NONE and MAP_NORESERVE. On Windows, we can use VirtualAlloc with MEM_RESERVE. (There are few other runtimes which do this trick, including GCC Go.) 3. Divide this region into blocks as before. The maximum heap size is now the megablock size, and the block size is still the same as before. Masking to find the block descriptor works as before. 4. To allocate, we keep track of the high-watermark, and mmap in 1MB pages as they are requested. We also keep track of how much metadata we need, and mmap extra pages to store metadata as necessary. We still want to request memory from the operating system in conveniently sized chunks, but we can now abolish the notion of a megablock and the megablock allocator, and work purely with block coalescing. Additionally, the recorded heap location means that we can check if a pointer is HEAP_ALLOCED using a mask and equality check, solving #8199. What do people think? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error
by GHC 04 Dec '15

04 Dec '15

#11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10846 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems to forget about in-scope implicit parameters when there's a hole in the type signature. Given {{{#!haskell {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} module Bad where f1 :: (?loc :: Int, _) => Int f1 = ?loc f2 :: (?loc :: Int) => _ f2 = ?loc }}} GHC incorrectly reports the following errors. {{{ % ghc -fforce-recomp Bad.hs [1 of 1] Compiling Bad ( Bad.hs, Bad.o ) Bad.hs:8:6: Unbound implicit parameter (?loc::Int) arising from a use of implicit parameter ‘?loc’ In the expression: ?loc In an equation for ‘f1’: f1 = ?loc Bad.hs:11:1: Occurs check: cannot construct the infinite type: _ ~ (?loc::Int) => _ When checking that ‘f2’ has the specified type f2 :: (?loc::Int) => _ Probable cause: the inferred type is ambiguous Bad.hs:11:6: Unbound implicit parameter (?loc::_) arising from a use of implicit parameter ‘?loc’ Relevant bindings include f2 :: _ (bound at Bad.hs:11:1) In the expression: ?loc In an equation for ‘f2’: f2 = ?loc }}} `?loc` is very clearly bound by both `f1` and `f2`'s signature. `f2` additionally reports what looks to me to be a bogus occurs-check error; we know from the theta that `?loc :: Int` so the hole should be solved for `Int`. I suspect this is all related to the fact that PartialTypeSignatures triggers `tcPolyInfer` instead of `tcPolyCheck`. I think this is the same underlying bug as #10846. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11144: Custom type errors need tidying
by GHC 04 Dec '15

04 Dec '15

#11144: Custom type errors need tidying -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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: -------------------------------------+------------------------------------- This is an excerpt from `testsuite/tests/typecheck/should_fail/CustomTypeErrors02.stderr`: {{{ CustomTypeErrors02.hs:17:1: error: The type 'a_aES -> a_aES' cannot be represented as an integer. When checking that ‘err’ has the inferred type err :: (TypeError ...) }}} We should tidy these types before printing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8582: Record syntax for pattern synonyms
by GHC 04 Dec '15

04 Dec '15

#8582: Record syntax for pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Implement syntax for {{{ pattern Cons{car, cdr} = (car, cdr) }}} which can then be used just like a regular record constructor, so the following are all valid patterns: {{{ Cons (Just x) [] Cons{car = Just x} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11077: ghc panic: ieName failed pattern match
by GHC 02 Dec '15

02 Dec '15

#11077: ghc panic: ieName failed pattern match -------------------------------------+------------------------------------- Reporter: woehr | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- My custom prelude module is producing the following panic in ghc: {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): ieName failed pattern match! Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The module is as follows: {{{#!hs module Prelude ( module X , tshow ) where import BasePrelude as X import Data.Text as X (Text, pack, unpack) tshow :: Show a => a -> Text tshow = pack . show }}} In my cabal file I depend on base-noprelude and base-prelude and use the above as my custom Prelude module. The panic is triggered by ```tshow```. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7