- ghc-tickets - Haskell.org

[GHC] #14561: Panic on levity polymorphic very unsafe coerce
by GHC 13 Dec '17

13 Dec '17

#14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MagicHash #-} module LevityId where import GHC.Types import GHC.Prim levityPolymorphicId :: forall (a :: TYPE r). a -> a levityPolymorphicId = unsafeCoerce# }}} {{{ (GHC version 8.3.20170928 for x86_64-apple-darwin): runtimeRepPrimRep typePrimRep (a_aW0 :: TYPE r_aVZ) r_aVZ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1144:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:358:5 in ghc:RepType runtimeRepPrimRep, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:307:18 in ghc:RepType typePrimRep, called at compiler/simplStg/UnariseStg.hs:666:8 in ghc:UnariseStg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As originally mentioned [https://github.com/ghc-proposals/ghc- proposals/pull/98#issuecomment-349727273 here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14577: Internal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profiling
by GHC 13 Dec '17

13 Dec '17

#14577: Internal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profiling -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14576 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the GHC API with this minimal example, using the -fexternal- interpreter option, compiled with profiling enabled: {{{#!hs import GHC import Control.Monad.IO.Class import GHC.Paths ( libdir ) import DynFlags import Linker main = runGhc (Just libdir) $ do env <- getSession dflags <- getSessionDynFlags liftIO $ initDynLinker env setSessionDynFlags (setGeneralFlag' Opt_ExternalInterpreter dflags) target <- guessTarget "A.hs" Nothing setTargets [target] load LoadAllTargets }}} Invoking the main executable: {{{ testprof }}} While A.hs contains a TH splice: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where $(return []) }}} The compiler crashes: {{{ Access violation in generated code when writing 0000000000000024 }}} Probably I'm misusing the API in this example, but the way it crashes is suspicious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14448: CircleCI can't build on OS X
by GHC 13 Dec '17

13 Dec '17

#14448: CircleCI can't build on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.2.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 mentioned in [[https://github.com/ghc/ghc/pull/83]] CircleCI seems to have trouble with OS X builds. They invariably end in one of a few ways, * it hangs * it is "cancelled" with CircleCI issuing the vague warning that there was "an issue while running this container" Fuuzetsu has raised the issue with CircleCI support. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14448> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14409: Split GHC(-API) into multiple packages
by GHC 13 Dec '17

13 Dec '17

#14409: Split GHC(-API) into multiple packages -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Current GHC-API is pretty monolithic and a lot of data is hidden in monads. I'd prefer to have cleanly separated packages for parser, module system, type-checker, optimizer, code generator, linker. E.g. Haddock would certainly only use the first two, maybe three, steps. Advanced editing features in an IDE would use only the first three steps. A compiler for a Haskell dialect might use only optimizer and code generator. The packages should have clean interfaces. E.g. it should be possible to enter a Text or String into the parser and get a ByteString containing code or a pointer to executable code in memory from the code generator, with no need to write temporary files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4020: Please consider adding support for local type synonyms
by GHC 13 Dec '17

13 Dec '17

#4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): > Type synonyms are top level/global because all types and classes are. Otherwise type solving might be incoherent. -1 from me. Type synonyms can be expanded, and using a synonym or its expansion should not affect coherence of type class resolution (what’s solving?). > Please explain why you couldn't declare the synonym at top level, as usual. Do you want the synonym to work wherever this module gets imported into? How will that go if it's nested? > Please provide a more focussed example. Line 202 of 707. Do you really need 707 lines to explain the need? Looking at lines 189 to 207: the RHS of the type synonym refers to lexically scoped variables, so the poster has to lambda-lift the type synonym. That’s similarly annoying to any other use of lambda-lifting. Arguably, the poster is just asking for something with the semantics of let, but for types (ignoring the difference between let and where). I’d guess you’d want both, and you’ll probably get both in general in DependentHaskell. A local type synonym should arguably be expanded, and only be in scope in its where clause, or in general in the lexical scope of the declaration. Probably the synonym should be expanded when exiting the synonym’s scope, so that error messages for type errors in the block use the synonym and not its expansion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4020#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14126: Two Failing Test Cases in HEAD
by GHC 12 Dec '17

12 Dec '17

#14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 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: -------------------------------------+------------------------------------- In a freshly cloned GHC code base (c6462ab0...), in my system,`make test TEST="T13780c T13822"` fails.That is while `./validate` passes. Specifically, I follow the following steps: (1) `git clone --recursive git://git.haskell.org/ghc.git` (2) `cd ghc` (3) `cp mk/build.mk.sample mk/build.mk` (4) set `BuildFlavour = devel2` and then (5) ./boot (6) ./configure (7) make -j4 (8) make test TEST="T13780c T13822" I build in a variant of the docker image for GHC development on Linux (64 bit), if it matters. As it seems, @alanz also gets the similar result on his system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14573: runtimeRepPrimRep panic when building GHC 8.2.2 with -fprof-auto-exported
by GHC 12 Dec '17

12 Dec '17

#14573: runtimeRepPrimRep panic when building GHC 8.2.2 with -fprof-auto-exported -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When building GHC 8.2.2 with the following options in `build.mk`, the stage1 compiler panics when building `StgCmmMonad.p_o` {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O2 -fprof-auto-exported GhcLibHcOpts = -O2 -fprof-auto-exported BUILD_PROF_LIBS = YES }}} {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_12 :: TYPE k0_10) k0_10 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (tested on x86_64 linux with GHC 8.0.2 as bootstrap compiler) The GHC 8.4 branch doesn't appear to do this, but I'm not sure if the underlying problem has been fixed. Compiling only the `StgCmmMonad` module with `-fprof-auto-exported` does not trigger the panic -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13210: Can't run terminfo code in GHCi on Windows
by GHC 12 Dec '17

12 Dec '17

#13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's possible this is a duplicate of another runtime linker on Windows issue out there, but I'll post this just in case this really is a unique case. I was attempting to compile the `terminfo` library on Windows, and I actually made it surprisingly far--but I quickly stumbled when I actually tried to run some code in GHCi. First, make sure you have a native Windows version of `ncurses` installed. On MSYS2: {{{ $ pacman -S mingw-w64-x86_64-ncurses }}} And here's a stripped-down version of `terminfo`, which I'll use to demonstrate the bug: {{{#!hs module Main where import Control.Exception import Foreign import Foreign.C.String import Foreign.C.Types data TERMINAL newtype Terminal = Terminal (ForeignPtr TERMINAL) -- Use "unsafe" to make set_curterm faster since it's called quite a bit. foreign import ccall unsafe set_curterm :: Ptr TERMINAL -> IO (Ptr TERMINAL) foreign import ccall "&" del_curterm :: FunPtr (Ptr TERMINAL -> IO ()) foreign import ccall setupterm :: CString -> CInt -> Ptr CInt -> IO () setupTerm :: String -> IO Terminal setupTerm term = withCString term $ \c_term -> with 0 $ \ret_ptr -> do -- NOTE: I believe that for the way we use terminfo -- (i.e. custom output function) -- this parameter does not affect anything. let stdOutput = 1 -- Save the previous terminal to be restored after calling setupterm. old_term <- set_curterm nullPtr -- Call setupterm and check the return value. setupterm c_term stdOutput ret_ptr ret <- peek ret_ptr if (ret /=1) then throwIO $ SetupTermError $ "Couldn't look up terminfo entry " ++ show term else do cterm <- set_curterm old_term fmap Terminal $ newForeignPtr del_curterm cterm data SetupTermError = SetupTermError String instance Show SetupTermError where show (SetupTermError str) = "setupTerm: " ++ str instance Exception SetupTermError where main :: IO () main = do Terminal t <- setupTerm "xterm" print t }}} If you compile this code, it "works" (in the sense that it'll actually call the C code): {{{ $ ghc -lncursesw Terminfo.hs [1 of 1] Compiling Main ( Terminfo.hs, Terminfo.o ) Linking Terminfo.exe ... $ ./Terminfo Terminfo.exe: setupTerm: Couldn't look up terminfo entry "xterm" }}} But attempting to run the same code in GHCi is a disaster: {{{ $ runghc -lncursesw Terminfo.hs ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `nanosleep' ghc.exe: Could not on-demand load symbol '_nc_cookie_init' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_cookie_init' ghc.exe: Could not on-demand load symbol '.refptr._nc_wacs' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_wacs' ghc.exe: Could not on-demand load symbol '_nc_WIN_DRIVER' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_WIN_DRIVER' ghc.exe: Could not on-demand load symbol '_nc_get_driver' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_get_driver' ghc.exe: Could not on-demand load symbol '_nc_setupterm_ex' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_setupterm_ex' ghc.exe: Could not on-demand load symbol 'newterm' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `newterm' ghc.exe: Could not on-demand load symbol '.refptr._nc_globals' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_globals' ghc.exe: Could not on-demand load symbol '_nc_err_abort' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_err_abort' ghc.exe: Could not on-demand load symbol 'tparm' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `tparm' ghc.exe: Could not on-demand load symbol '.refptr._nc_prescreen' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_prescreen' ghc.exe: Could not on-demand load symbol '_nc_outch_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_outch_sp' ghc.exe: Could not on-demand load symbol '.refptr._nc_outch_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr._nc_outch_sp' ghc.exe: Could not on-demand load symbol '_nc_scrolln_sp' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_scrolln_sp' ghc.exe: Could not on-demand load symbol '.refptr.SP' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr.SP' ghc.exe: Could not on-demand load symbol '.refptr.cur_term' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `.refptr.cur_term' ghc.exe: Could not on-demand load symbol '_nc_ospeed' ghc.exe: C:/msys64/mingw64/lib/../lib/libncursesw.a: unknown symbol `_nc_ospeed' ghc.exe: Could not on-demand load symbol 'set_curterm' Terminfo.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: set_curterm 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 }}} Also reproducible on GHC HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14575: ghc: panic! (the 'impossible' happened)
by GHC 12 Dec '17

12 Dec '17

#14575: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Pauly | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.2 Keywords: template | Operating System: Linux haskell | Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] spec_a86Q :: t_a86P[tau:1] (CHoleCan: spec)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens after adding of this call in test file (called SimpleTaggingSpec.hs): {{{#!hs $(shrinkEnumTag AnyJT) }}} Implementation of this ''shrinkEnumTag'' looks: {{{#!hs shrinkEnumTag :: forall a. (Data a, IsTag a) => a -> Q [Dec] shrinkEnumTag enm = do let dt = dataTypeOf enm ty = mkName $ dataTypeName dt tickAdd = (++"'") nameWith f = mkName . f . show derivs' = ConT . mkName <$> ["Eq", "Ord", "Enum"] mkShow tn tn' = [d|instance Show $(conT tn') where show a = show $ (toEnum $ fromEnum a :: $(conT tn))|] AlgRep algCs <- pure $ dataTypeRep dt let algCs' = [mkName $ show c | c <- algCs, fromConstr c /= (anyTag::a)] newCs = [NormalC (nameWith tickAdd n) [] | n <- algCs'] TyConI tyCon <- reify ty decs <- case tyCon of DataD _cxt _nm tyVars _mbKind _cs _derivs -> do let ty' = nameWith tickAdd ty when (null newCs) $ fail "Can't find normal constructors" showInst <- mkShow ty ty' return $ [DataD [] ty' tyVars Nothing newCs derivs'] ++ showInst _ -> fail "expected Enum-like data type" return decs }}} If I add this call in not-test module, all is good, compilation is fine, application works. I use GHC 8.0.2, this happened with LTS-8.13 and LTS-9.18. Project uses stack tool. OS is Linux OpenSUSE Tumbleweed. I updated stack to the last version (1.6.1) but this did not help. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14575> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14558: Unable to parse integer-gmp's Cabal file
by GHC 12 Dec '17

12 Dec '17

#14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- integer-gmp version 1.0.1.0 has this line in [https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal its Cabal file]: {{{ build-depends: ghc-prim ^>= 0.5.1.0 }}} That uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error: {{{ Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse "build- depends" 58 }}} This was reported on Stack's issue tracker and on Reddit: - https://github.com/commercialhaskell/stack/issues/3624 - https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to… I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead. I can see how this isn't a bug per se because integer-gmp's Cabal file specifies {{{ cabal-version: 2.0}}}. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical {{{ cabal-version: >= 1.10}}} and specified its dependency as {{{ build-depends: ghc-prim >= 0.5.1 && <0.6}}}, without the caret operator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 51