- ghc-devs - Haskell.org

Compiling binaries of bytecode: ever been considered?
by Christopher Done 04 Nov '19

04 Nov '19

Hi all, I was just wondering: has a compiler output mode ever been considered that would dump bytecode to a file, dynamic link to the ghc runtime, and then on start-up that program would just interpret the bytecode like ghci does? The purpose would be simply faster compile-and-restart times. Cheers, Chris

3 2

GitLab email
by Ben Gamari 04 Nov '19

04 Nov '19

Hi everyone, On Friday I finished importing the prime.haskell.org Trac instance into GitLab. For this process I had to disable mail delivery to ensure that users weren't spammed by import messages. Unfortunately, it looks like I neglected to reenable mail after the import had concluded. I re-enabled mail about half an hour ago and consequently you may find yourself facing a few more messages than usual this morning. Sorry for the inconvenience! Cheers, - Ben

1 0

Working in my own branch with changes in submodules
by Alejandro Serrano Mena 01 Nov '19

01 Nov '19

Dear GHC devs, I am currently working on my own fork of GHC ( https://gitlab.haskell.org/trupill/ghc) and as part of it I need to do some changes to the Cabal and haskeline libraries. However, since they are in submodules, I am not sure about how I can commit those changes, share them with others, and rebase my changes against the current HEAD for these submodules. Thanks in advance and kind regards, Alejandro

2 1

DriverPipeline/HscMain DynFlags mystery
by Ömer Sinan Ağacan 01 Nov '19

01 Nov '19

Hi, We recently did some refactoring in HscMain and DriverPipeline to generate interfaces after final Cmms are generated (previously interfaces would be generated after the tidying pass). It's mostly done but there's one thing that I couldn't figure out after two full days of debugging (I also asked a few people about it on IRC), so I wanted to ask here in case someone here knows. Previously the interface value (ModIface) would be generated and written to disk in `HscMain.finish`. The DynFlags we use to generate the ModIface and to write it to disk would be the one passed to `HscMain.hscIncrementalCompile`. In the new implementation part of the interface is still generated in `HscMain.hscIncrementalCompile` (see mkPartialIface), using the same DynFlags as before. But more stuff is added after the final Cmms are generated (see mkFullIface calls in DriverPipeline) using DynFlags in `compileOne'` or `runPhase` (called by `runPipeline`). It turns out these DynFlags are different enough from the one passed to `HscMain.hscIncrementalCompile` that some tests fail (I remember a backpack test, but there may be more). ("Full" interfaces are written to disk right after generation) See [1] for the hack I added as a workaround. Basically I keep the DynFlags passed to hscIncrementalCompile so that I can generate the final interfaces correctly. The question is what's changing in DynFlags that makes things go wrong. I tried looking at the fields used by mkFullIface and hscMaybeWriteIface, but as far as I can see none of the fields used by these functions are different from the DynFlags passed to hscIncrementalCompile. If anyone knows what's going on any help would be appreciated. Thanks, Ömer [1]: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/main/HscTypes.hs#L2…

2 2

Linking problem
by Simon Peyton Jones 30 Oct '19

30 Oct '19

Devs On the branch wip/inline-compulsory, I'm getting a strange link error: simonpj@MSRC-3645512:~/tmp$ ~/code/HEAD-2/inplace/bin/ghc-stage1 Hello.hs [1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello ... /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(Updates.o):stg_bh_upd_frame_info: error: undefined reference to 'stg_marked_upd_frame_ret' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(StgMiscClosures.o):stg_CAF_BLACKHOLE_info: error: undefined reference to 'stg_BLACKHOLE_entry' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(StgMiscClosures.o):__stg_EAGER_BLACKHOLE_info: error: undefined reference to 'stg_BLACKHOLE_entry' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(Apply.o):stg_AP_STACK_info: error: undefined reference to 'stg_WHITEHOLE_entry' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(Exception.o):function stg_raisezh: error: undefined reference to 'stg_ap_n_ret' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(Exception.o):function stg_raisezh: error: undefined reference to 'stg_ap_pv_ret' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(AutoApply.o):stg_ap_v_info: error: undefined reference to 'stg_BCO_entry' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(AutoApply.o):stg_ap_f_info: error: undefined reference to 'stg_BCO_entry' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(AutoApply.o):stg_ap_d_info: error: undefined reference to 'stg_BCO_entry' /home/simonpj/code/HEAD-2/rts/dist/build/libHSrts.a(AutoApply.o):stg_ap_l_info: error: undefined reference to 'stg_BCO_entry' ... etc... But I have done nothing in the RTS! If I try 'nm' I get bash$ nm rts/dist/build/libHSrts.a | grep stg_ap_p_fast U stg_ap_p_fast U stg_ap_p_fast 0000000000003f58 T stg_ap_p_fast So somehow the same symbol is defined and unresolved. Really strange. Can you help? Thanks Simon

2 2

Handling source locations in HsSyn via TTG
by Simon Peyton Jones 30 Oct '19

30 Oct '19

Friends As you know * We are trying to use "Trees That Grow<https://gitlab.haskell.org/ghc/ghc/wikis/implementing-trees-that-grow>" (TTG) to move HsSyn towards a situation in which GHC is merely a client of a generic HsSyn data type that can be used by clients other than GHC. * One sticking point has been the question of attaching source locations. We used to have a "ping-pong" style, in which very node is decorated with a source location, but that's a bit more awkward in TTG. * This wiki page<https://gitlab.haskell.org/ghc/ghc/wikis/implementing-trees-that-grow/handl…> outlines some choices, while ticket #15495<https://gitlab.haskell.org/ghc/ghc/issues/15495> has a lot of discussion. * HEAD embodies Solution A. But it has the disadvantage that the type system doesn't enforce locations to be present at all. That has undesirable consequences (eg ticket #17330<https://gitlab.haskell.org/ghc/ghc/issues/17330>) * The proposal is to move to Solution D on that page; you can see how it plays out in MR !1970<https://gitlab.haskell.org/ghc/ghc/merge_requests/1970>. * (I think Solutions B and C are non-starters by comparison.) If you care, please check out the design and the MR. We can change later, of course, but doing so changes a lot of code, including client code, so we'd prefer not to. Let's try to converge by the end of the week. Thanks Simon

5 9

Status of the rich errors proposal
by Javier Neira Sanchez 29 Oct '19

29 Oct '19

Hi, lately i am being collaborated in the haskell-ide-engine (hie) repo and one of the issues i get to fix was related with the parsing of ghc errors. It turns out that delimiters of terms in errors are different in windows (`term') and *nix (‘term’) systems and that drive to parse errors. Quite code actions and diagnostics are based in parsing them and they were broken in windows. I am afraid that the code is very brittle and close to human readable error messages. the actual code look like this: -- | Extract a term from a compiler message. -- It looks for terms delimited between '‘' and '’' falling back to '`' and '\'' -- (the used ones in Windows systems). extractTerm :: T.Text -> T.Text extractTerm txt = case extract '‘' '’' txt of "" -> extract '`' '\'' txt -- Needed for windows term -> term where extract b e = T.dropWhile (== b) . T.dropWhileEnd (== e) . T.dropAround (\c -> c /= b && c /= e) or extractImportableTerm :: T.Text -> Maybe (T.Text, SymbolImport SymbolType) extractImportableTerm dirtyMsg = do (n, s) <- extractedTerm let n' = T.strip n return (n', s) where importMsg = S.headMay -- Get rid of the rename suggestion parts $ T.splitOn "Perhaps you meant " $ T.replace "\n" " " -- Get rid of trailing/leading whitespace on each individual line $ T.unlines $ map T.strip $ T.lines $ T.replace "* " "" -- Needed for Windows $ T.replace "• " "" dirtyMsg extractTerm prefix symTy = importMsg >>= T.stripPrefix prefix >>= \name -> Just (name, Import symTy) extractType b = extractTerm ("Not in scope: type constructor or class " <> b) Type extractedTerm = asum [ extractTerm "Variable not in scope: " Symbol , extractType "‘" , extractType "`" -- Needed for windows , extractTerm "Data constructor not in scope: " Constructor] It is clearly unsatisfactory but hard to improve without changing the messages to make it more structured. Moreover any legitimate change on errors to make it better will likely break it. After exposing my worries in the hie irc channel, @mpickering pointed out that it is already a proposal to improve error messages: https://github.com/bgamari/ghc-proposals/blob/rich-errors-proposal/proposal… that nicely will improve the state of things. Otoh there are already a way to output ghc errors as json (see https://gitlab.haskell.org/ghc/ghc/issues/13190) It contains valuable info about the error in specific fields but the message itself is in plain text. So merging both features will let tools to handle compiler errors without use the ghc api directly if needed. what is the status of the proposal? hie an other tooling developers will welcome it very heartly. Thanks in advance!

3 2

Simplifier bug fixed in GHC 8.8.1?
by Alexis King 28 Oct '19

28 Oct '19

Hi all, I have an odd question: I’ve bumped into a clear simplifier bug, and although it only happens on GHC 8.6.5, not 8.8.1, I’d like to locate the change that fixed it. My library’s test suite currently fails on GHC 8.6.5 due to the bug, and I’d rather not force all my users to upgrade to 8.8 if I can help it, so I’m hoping to find a workaround. The minimal test case I’ve found for the bug is this program: {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving, TypeFamilies #-} import Control.Exception import Control.Monad.IO.Class import Control.Monad.Trans.Identity import Control.Monad.Trans.Reader class Monad m => MonadFoo m where foo :: m a -> m a instance MonadFoo IO where foo m = onException m (pure ()) instance MonadFoo m => MonadFoo (ReaderT r m) where foo m = ReaderT $ \r -> foo (runReaderT m r) deriving instance MonadFoo m => MonadFoo (IdentityT m) type family F m where F m = IdentityT m newtype FT m a = FT { runFT :: F m a } deriving (Functor, Applicative, Monad, MonadIO, MonadFoo) main :: IO () main = run (foo (liftIO (throwIO (IndexOutOfBounds "bang")))) where run :: ReaderT () (FT (ReaderT () IO)) a -> IO a run = flip runReaderT () . runIdentityT . runFT . flip runReaderT () Using GHC 8.6.5 on macOS 10.14.5, compiling this program with optimizations reliably triggers the -fcatch-bottoms sanitization: $ ghc -O -fcatch-bottoms weird.hs && ./weird [1 of 1] Compiling Main ( weird.hs, weird.o ) Linking weird ... weird: Bottoming expression returned What goes wrong? Somehow the generated core for this program includes the following: lvl_s47B :: SomeException lvl_s47B = $fExceptionArrayException_$ctoException lvl_s483 m_s47r :: () -> State# RealWorld -> (# State# RealWorld, () #) m_s47r = \ _ (eta_B1 :: State# RealWorld) -> raiseIO# lvl_s47B eta_B1 main_s2Ww :: State# RealWorld -> (# State# RealWorld, () #) main_s2Ww = \ (eta_a2wK :: State# RealWorld) -> catch# (case m_s47r `cast` <Co:33> of { }) raiseIO# eta_a2wK This core is completely bogus: it assumes that m_s47r is bottom, but m_s47r is a top-level function! The program still passes -dcore-lint, unfortunately, as it is still well-typed. (Also, in case it helps: -ddump-simplifier-iterations shows that the buggy transformation occurs in the first iteration of the very first simplifier pass.) I’ve been trying to figure out what change might have fixed this so that I can assess if it’s possible to work around, but I haven’t found anything obvious. I’ve been slowly `git bisect`ing to look for the commit that introduced the fix, but many of the commits I’ve tested cause unrelated panics on my machine, which has been exacerbating the problem of the slow recompilation times. I’m a little at wits’ end, but opening a bug report hasn’t felt right, since the bug does appear to already be fixed. Does this issue ring any bells to anyone on this list? Is there a particular patch that landed between GHC 8.6.5 and GHC 8.8.1 that might have fixed this problem? If not, I’ll keep trying with `git bisect`, but I’d appreciate any pointers. Thanks, Alexis

2 2

Debugging specialization
by Alexis King 28 Oct '19

28 Oct '19

Hi all, I am trying to understand why GHC is not specializing an imported INLINABLE instance method, and the information provided by -ddump-spec -Wall-missed-specialisations has not been enough to help me figure it out. Is there some easy/well-trodden way that I could build GHC with some additional instrumentation in place to help me better understand the decisions being made by the specializer, or is -ddump-spec the most granularity available? I’ve noticed that Specialise.hs has handful of pprTrace calls sprinkled about, but they are all commented out. Is the recommended method to just uncomment these calls and rebuild GHC? Thanks, Alexis

3 3

ghc, rts/Linker.c, OpenBSD and WXNEEDED and NOPIE
by Matthias Kilian 28 Oct '19

28 Oct '19

Hi, tl;dr: with shared / dynamic libs, is anything from rts/Linker.c still in use? If so, where and why? I hope this hasn't already been discussed in the past, and I apolotzie if all this is no longer relevant for ghc-8.8 or newer (I'm still at 8.6)... On OpenBSD, I had to explicitely mark ghc as WXNEEDED (i.e. allow it to map pages both as writable and executable), which I would like to get rid of. Likewise, I had to do some dances to explicitely disable PIE. If my memory doesn't fail completely, most (if not all) oft his was because of rts/Linker.c mmapping objects to be loaded at runtime and kind of simulating what dlopen() does for shared objects. Recently, thanks to Greg Steuck (who helped me a lot with this), we updated our ghc port to ghc-8.6 and also enabled shared (or dynamic, if you prefer this term) libraries. So my hope was that the code in rts/Linker.c were no longer used (because dynamic loading as done by ghci or template Haskell) could be done with dlopen(). However, after building ghc-8.6 with all the WXNNEDED stuff removed, and running ghci from this build, I still get an abort because pages are mapped both writable and executable (I've configured my system to abort processes when a W^X violation happens). Here's a backtrace in case it's helpfull at all: #0 _thread_sys___syscall () at -:3 #1 0x00000002010bb179 in _libc_mmap (addr=Variable "addr" is not available.) at /usr/src/lib/libc/sys/mmap.c:47 #2 0x000000021be22374 in mmapForLinker (bytes=Variable "bytes" is not available.) at rts/Linker.c:1029 #3 0x000000021be3e99b in m32_allocator_init () at rts/linker/M32Alloc.c:160 #4 0x00000002fd518be1 in cimc_info () from /usr/local/lib/ghc/bin/../ghci-8.6.4/libHSghci-8.6.4-ghc8.6.4.so #5 0x0000000000000000 in ?? () Any thougts about this? And, since W|X (and nopie) isn't good on any system: is anyone working on getting rid of this for other unixes? Thanks in advance for any help. Ciao, Kili

2 1