- ghc-tickets - Haskell.org

[GHC] #10410: make install installs haddck.t files
by GHC 27 May '15

27 May '15

#10410: make install installs haddck.t files -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since changeset:55cdcc96/ghc, building GHC creates `.haddock.t` files with statistics. I’m not sure how useful they are in general, but they are definitely not useful in release tarballs. Currently, `make install` copies them. This affects both the binary release on the ghc page as well as distribution packages (checked Debian and Fedora). It seems these files are used by the test suite (`testsuite/tests/perf/haddock/all.T`), so probably `make install` should be taught to ignore them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10410> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10446: Fix error message when variables in a static form are not in scope
by GHC 27 May '15

27 May '15

#10446: Fix error message when variables in a static form are not in scope -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple StaticPointers | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If an identifier is out-of-scope but inside a static form ({{{static f}}}) then GHC says expression not closed, when really it should just say identifier out of scope. {{{ t.hs:6:5: error: Only identifiers of top-level bindings can appear in the body of the static form: static f but the following identifiers were found instead: f }}} We just want: {{{ t.hs:6:12: error: Not in scope: ‘f’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10446> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 27 May '15

27 May '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I have rooted out another cause for indeterminism and the Debian reproducibilty project managed to compile GHC with a bit-wise identical output: https://reproducible.debian.net/rb-pkg/experimental/amd64/ghc.html See Phab:D910 for a patch. I doubt that this solves the problem completely, but it is a step towards it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:86> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9584: Interface file errors (Iface type variable out of scope: k)
by GHC 27 May '15

27 May '15

#9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Please forgive me if I have not formatted this bug report properly) Anyway, yesterday in a project at work we started having a strange problem where pretty much any change in our code at all would result in the next build failing with this error: {{{ The interface for ‘main:HList’ Declaration for $fRLensk:r_$s$w$crlens: Iface type variable out of scope: k Cannot continue after interface file error }}} I can get around the problem by deleting the dist directory, but this is very unfortunate, since it basically changes my build/test cycle from a few seconds to a minutes because I can't take advantage of the cached builds of things that *haven't* changed. It seems like errors like this have cropped up a few times in GHC, but they've always been fixed so far, so hopefully someone here will be familiar with what is causing this one! Please let me know if there is further information I can provide. The file in question looks basically like this: (it depends on some other stuff in our project, and so it won't build immediately if you paste it onto your machine; let me know if you need me to bundle it up into something self-contained). {{{#!hs -- | A bespoke record/HList type. 'el' interprets fields into types; 'tot' is -- the maximal extension of the record type; and 'rs' is the subset of 'tot' -- contained in the record itself. data Record (el :: k -> *) (tot :: [k]) (rs :: [k]) where Nil :: Record el tot '[] (:*) :: ( ElemTF r tot ?? '("the key", r, "is not permitted in this record, which may only contain", tot) , DistinctTF (r ': rs) ?? '("the key", r, "is already in", rs) ) => el r -> Record el tot rs -> Record el tot (r ': rs) infixr 9 :* -- | Records have lenses for their fields. class ElemTF r rs ~ True => RLens rs r where rlens :: proxy r -> CL.Lens' (Record el tot rs) (el r) instance RLens (r ': rs) r where rlens _ = CL.lens (\(x :* _) -> x) (\(_ :* xs) x -> x :* xs) instance (ElemTF r (s ': rs) ~ True, RLens rs r) => RLens (s ': rs) r where rlens _ = CL.lens (\(_ :* xs) -> xs ^. rlens Proxy) (\(x :* xs) y -> x :* xs & rlens Proxy .~ y) -- | Records with fields in 'K' give rise to a functor from 'Hask^K' to 'Hask'. (<<$>>) :: (forall x. f x -> g x) -> Record f tot rs -> Record g tot rs _ <<$>> Nil = Nil eta <<$>> (x :* xs) = eta x :* (eta <<$>> xs) infixl 8 <<$>> -- | Records can be traversed to pull out some of their effects. rtraverse :: Applicative h => (forall x. f x -> h (g x)) -> Record f tot rs -> h (Record g tot rs) rtraverse _ Nil = pure Nil rtraverse f (x :* xs) = (:*) <$> f x <*> rtraverse f xs -- | As a special case, we can yank out the first layer of effects in a -- composed functor stack. rtraverse1 :: Applicative f => Record (f :. g) tot rs -> f (Record g tot rs) rtraverse1 = rtraverse getCompose -- | Records whose fields are uniform in type may be turned into a list. recordToList :: Record (Const t) tbl rs -> [t] recordToList Nil = [] recordToList (Const x :* xs) = x : recordToList xs instance Show (Record el tot '[]) where show _ = "Nil" instance ( Show (Record el tot rs) , Show (el r) ) => Show (Record el tot (r ': rs)) where show (x :* xs) = "(" ++ show x ++ " :* " ++ show xs ++ ")" data family Sing (a :: k) class SingI a where sing :: Sing a class kparam ~ Any => SingE (kparam :: k) rep | kparam -> rep where fromSing :: Sing (a :: k) -> rep }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8122: make binary-dist broken on OS X in HEAD
by GHC 27 May '15

27 May '15

#8122: make binary-dist broken on OS X in HEAD --------------------------------+------------------------------------------ Reporter: danharaj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Installing GHC failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ After a successful configure and make, make binary-dist fails: {{{ ➜ ghc git:(master) make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all make[1]: Nothing to be done for `all'. ➜ ghc git:(master) make binary-dist rm -f bindist-list make -r --no-print-directory -f ghc.mk bindist BINDIST=YES "cp" -p ghc/stage1/build/tmp/ inplace/lib/bin/ghc-stage1 cp: ghc/stage1/build/tmp/ is a directory (not copied). make[1]: *** [inplace/lib/bin/ghc-stage1] Error 1 make: *** [binary-dist-prep] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 26 May '15

26 May '15

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect | Blocking: warning at compile-time | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by tonyday567): I found a similar bug with this same command here: https://github.com/mikeizbicki/subhask/commit/c98d2b5f1184153820867d83e4fba… Error: {{{ <no location info>: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: subhazuAF2UqVq5DNs9kS0u9qf2pe_SubHaskziTemplateHaskellziMutable_mkMutable_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} As far as I can tell, it doesn't involve Lens. ghc --interactive and cabal build both work fine, so the bug is isolated to the -fno-code flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8025#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10430: openTempFileWithDefaultPermissions has the wrong location name on failure
by GHC 26 May '15

26 May '15

#10430: openTempFileWithDefaultPermissions has the wrong location name on failure -------------------------------------+------------------------------------- Reporter: | Owner: NeilMitchell | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In System/IO.hs I see two typos: {{{#!hs openTempFileWithDefaultPermissions :: FilePath -> String -> IO (FilePath, Handle) openTempFileWithDefaultPermissions tmp_dir template = openTempFile' "openBinaryTempFile" tmp_dir template False 0o666 }}} It should read {{{openTempFile' "openTempFileWithDefaultPermssions"}}}. The function {{{openBinaryTempFileWithDefaultPermissions}}} has the same bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10430> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9950: Documentation for InterruptibleFFI contains broken example
by GHC 26 May '15

26 May '15

#9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In Section "8.1.4. Interruptible foreign calls" the example {{{#!hs foreign import ccall interruptible "sleep" :: CUint -> IO CUint }}} misses the haskell function name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10092: lex doesn't handle binary literals
by GHC 26 May '15

26 May '15

#10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc2 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The {{{lex}}} function from {{{Text.Read.Lex}}} (on which the {{{Read}}} instance for {{{Lexeme}}} is based) can't read binary literals on GHC 7.10.1-rc2: {{{ $ ghci -XBinaryLiterals GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help λ> 0b101010 42 λ> import Text.Read.Lex λ> read "0b101010" :: Lexeme *** Exception: Prelude.read: no parse }}} This should be a simple fix, but I'm not sure if this is the intended behavior or not, since {{{BinaryLiterals}}} isn't a part of the Haskell 2010 standard (and I'm not sure how closely {{{lex}}} adheres to that). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7521: Simplifier ticks exhausted when compiling Accelerate example.
by GHC 26 May '15

26 May '15

#7521: Simplifier ticks exhausted when compiling Accelerate example. -------------------------------------+------------------------------------- Reporter: eamsden | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Should the subject/title, "Simplifier ticks exhausted when compiling Accelerate example" be changed since it is no longer accurate? Given that should the priority be changed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7521#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0