July 2020 - ghc-devs - Haskell.org

Re: HEAD doesn't build. Totally stalled.
by Ryan Scott 17 Jul '20

17 Jul '20

> And while Simon is the only > one I'm aware of, for whom this breaks For what it's worth, I am hitting the same issue when building GHC. Ryan S.

1 0

GHC formally discontinuing 32-bit Windows support?
by Ben Gamari 15 Jul '20

15 Jul '20

tl;dr. Unless someone speaks up, GHC will formally discontinue its (currently-broken) support for 32-bit Windows in 8.12. Hi everyone, As some have noticed, recent GHC releases' support for 32-bit Windows support can be generously described as "unreliable". This has been due to a combination of platform limitations, native toolchain bugs, and a general lack of capacity within the GHC community focusing on Windows support. I won't summarise the concrete issues here (see #17961, and #17700 for the current state-of-play) but let it suffice to say that we are currently stuck due to a bug in GNU binutils. However, I was recently informed that Cygwin and msys have recently discontinued their support for 32-bit Windows. While GHC uses a toolchain from the mingw32-w64 project, it seems only a matter of time before 32-bit builds cease there as well (see [1] for a summary of the relationships between these projects). Furthermore, Microsoft itself has said that 32-bit Windows 10 releases will cease later this year. All of this suggests to me that supporting 32-bit Windows in GHC will be, at best, an up-hill battle. Even worse, it is a battle with little to gained: essentially all Intel-based Windows systems today run on 64-bit-capable systems. I know of no compelling reasons why users would opt to use 32-bit Windows in 2020. Consequently, I suggest that we should formally discontinue 32-bit Windows support in GHC 8.12. In my opinion, GHC's limited engineering capacity on Windows is better spent elsewhere. However, if there are compelling reasons why some users still rely on 32-bit Windows support (despite it being largely unusable for the last two years), please do let me know. I have been consistently surprised by the number of users who have noted the absence of 32-bit Windows builds; I would love to know why they seem to be so popular. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/surviving-windows

1 0

[ANNOUNCE] GHC 8.8.4 is now available
by Ben Gamari 15 Jul '20

15 Jul '20

Hello everyone, The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.4 Release notes are also available [1]. This release fixes a handful of issues affecting 8.8.3: - Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately. - Works around a Linux kernel bug in the implementation of timerfd (#18033) - Fixes a few linking issues affecting ARM - Fixes "missing interface file" error triggered by some uses of Data.Ord.Ordering (#18185) - Fixes an integer overflow in the compact-normal-form import implementation (#16992) - `configure` now accepts a `--enable-numa` flag to enable/disable `numactl` support on Linux. - Fixes potentially lost sharing due to the desugaring of left operator sections (#18151). - Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024) As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.4-notes.h…

1 0

Review for !2377 Haddock and GHC
by Simon Peyton Jones 15 Jul '20

15 Jul '20

Fellow GHC devs I'd like to ask your help with reviewing a GHC patch !2377: Accumulate Haddock comments in P (#17544, #17561, #8944)<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377/diffs#diff-content…> It's a substantial patch to the parser, changing the way in which Haddock documentation is parsed. It moves us in a good direction; it makes us more robust for the future; Vlad has invested a lot of effort in it; and I'm sure we should land it. But it's had surprisingly little review, especially for a patch that potentially affects quite a lot of people (incl Haddock folk, IDE folk). So, would any of you be willing to review the code itself? Especially folk involved in Haddock or Haskell IDE. Early versions were not easy to understand, but Vlad has invested a lot of effort in both simplifying it and in documenting it. We'll land it regardless in a couple of weeks. Thanks! Simon Summary of the payload (taken from #17544) Currently Haddock comments are, first and foremost, comments. It's very annoying to incorporate them into the grammar. We can take advantage of an important property: adding a Haddock comment does not change the parse tree in any way other than wrapping some nodes in HsDocTy and the like (and if it does, that's a bug). Here's the design I propose instead: 1. Accumulate Haddock comments with their locations in the P monad. This logic will be very easy to add in the lexer. 2. After parsing, do a pass over the AST to associate Haddock comments with AST nodes using location info. 3. Report the leftover comments to the user as a warning or an error. This means * The happy grammar won't even have the notion of a Haddock comment. * Parser.y becomes quite a bit simpler. * Ultimately, it is conceivable we could move the logic of associating Haddock comments with AST nodes from GHC to Haddock itself A detailed overview of the implementation plan is in comments at the start of compiler/GHC/Parser/PostProcess/Haddock.hs<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377/diffs#diff-content…>

1 0

Querying Core for information about variables
by Siddharth Bhat 13 Jul '20

13 Jul '20

Hello, I'm trying to understand how to query information about `Var`s from a Core plugin. Consider the snippet of haskell: ``` {-# LANGUAGE MagicHash #-} import GHC.Prim fib :: Int# -> Int# fib i = case i of 0# -> i; 1# -> i; _ -> (fib i) +# (fib (i -# 1#)) main :: IO (); main = let x = fib 10# in return () ``` That compiles to the following (elided) GHC Core, dumped right after desugar: ``` Rec { fib [Occ=LoopBreaker] :: Int# -> Int# [LclId] fib = ... end Rec } Main.$trModule :: GHC.Types.Module [LclIdX] Main.$trModule = GHC.Types.Module (GHC.Types.TrNameS "main"#) (GHC.Types.TrNameS "Main"#) -- RHS size: {terms: 7, types: 3, coercions: 0, joins: 0/0} main :: IO () [LclIdX] main = case fib 10# of { __DEFAULT -> return @ IO GHC.Base.$fMonadIO @ () GHC.Tuple.() } -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () [LclIdX] :Main.main = GHC.TopHandler.runMainIO @ () main ``` I've been using `occNameString . getOccName` to manipulate names of `Var`s from the Core module. I'm rapidly finding this insufficient, and want more information about a variable. In particular, How to I figure out: 1. When I see the Var with occurence name `fib`, that it belongs to module `Main`? 2. When I see the Var with name `main`, whether it is `Main.main` or `:Main.main`? 3. When I see the Var with name `+#`, that this is an inbuilt name? Similarly for `-#` and `()`. 4. When I see the binder $trModule, that it is added by GHC and has type `GHC.Types.Module`? 5. In general, given a Var, how do I decide where it comes from, and whether it is user-defined or something GHC defined ('wired-in' I believe is the term I am looking for)? 6. When I see a `Var`, how do I learn its type? 7. In general, is there a page that tells me how to 'query' Core/`ModGuts` from within a core plugin? Pointers on how to get this information is much appreciated. Also, pointers on "learning how to learn" --- that is, how I could have figured this out on my own / RTFMing better are also very appreciated! Thanks a lot, ~Siddharth -- https://bollu.github.io/

2 1

Broken links in GHC User’s Manual
by Wolfgang Jeltsch 13 Jul '20

13 Jul '20

Hi! When I go to https://www.haskell.org/ghc/ and click on “Documentation”, I’m taken to https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ . Clicking there on the entry for Section 9.1, for example, takes me to https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts… , where there is no page. On the other hand, when I go to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html (which I have in my bookmarks) and then click on the entry for Section 9.1, I’m taken to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… , where there is the expected page. Could this perhaps be fixed? Thank you. All the best, Wolfgang

3 2

A small documentation PR on github
by Alexander Kjeldaas 05 Jul '20

05 Jul '20

Hi devs! I created a small documentation PR for the GHC FFI on github and noticed that there's another one-liner PR from May 2019 that was not merged. https://github.com/ghc/ghc/pull/260 https://github.com/ghc/ghc/pull/255 Just checking that simple PRs are still accepted on github. Alexander

4 5

Async exceptions and delimited continuations
by Alexis King 03 Jul '20

03 Jul '20

Hi all, As some of you are likely aware, I have an open GHC proposal[1] to add native support for delimited continuations to the RTS. I also have an incomplete implementation,[2] and the only major remaining obstacle concerns async exceptions. The issue is subtle, so I’ve tried to provide all the necessary context in this email. If you’re already familiar with the ideas at play, you can skip the context about how delimited continuations work. For those unfamiliar, delimited continuations allow capturing slices of the call stack and restoring them later. For example, the program do y <- prompt $ do x <- control0 $ \k -> k (pure 10) pure (x + 5) print y will print 15. To understand what’s happening operationally, we can imagine an abstract call stack made up of continuation frames: ┌──────────┐ │ ● + 5 │ redex: control0 $ \k -> k (pure 10) ├──────────┤ │ prompt ● │ ├──────────┤ │ print ● │ ├──────────┤ │ ... │ ├──────────┤ Here, each ● represents the “hole” where the evaluated result of the redex will be returned. `control0` moves all the frames between the top of the stack and the first `prompt` into the heap and returns a reference to them, so after a single reduction step, we have ┌──────────┐ │ print ● │ redex: k1 (pure 10) ├──────────┤ heap: k1 = ┌──────────┐ │ ... │ │ ● + 5 │ ├──────────┤ └──────────┘ When a continuation is applied, its stored stack frames are copied back onto the top of the current stack, and the argument becomes the new redex: ┌──────────┐ │ ● + 5 │ redex: pure 10 ├──────────┤ │ print ● │ ├──────────┤ │ ... │ ├──────────┤ Now it should hopefully be clear how we end up printing 15. With that context, consider the following expression: prompt $ mask_ $ do x <- control0 $ \k -> k (pure 10) f x The call stack at the point of control0 looks very similar in this program, but now we have a use of `mask_` in there as well: ┌──────────┐ │ f ● │ redex: control0 $ \k -> k (pure 10) ├──────────┤ exns: masked │ mask_ ● │ ├──────────┤ │ prompt ● │ ├──────────┤ │ ... │ ├──────────┤ When capturing the continuation, we’ll unwind the stack the same way we did before. Because we’re popping mask_ off the stack, we’ll unmask async exceptions: ┌──────────┐ redex: k1 (pure 10) │ ... │ exns: not masked ├──────────┤ heap: k1 = ┌──────────┐ │ f ● │ ├──────────┤ │ mask_ ● │ └──────────┘ Now when we apply `k1`, we’ll copy the `mask_` frame back onto the stack, and we must re-mask async exceptions. Otherwise, exceptions will not be masked during the call to `f`, which would be wrong. Why is this a problem? The RTS applies an optimization: if you call mask_ (actually maskAsyncExceptions#) while exceptions are already masked, it doesn’t push a new stack frame at all. So, for example, if you write mask_ $ mask_ $ foo bar you’ll end up with only one mask_ frame on the call stack, not two. This tiny optimization actually allows not one but two savings: 1. The immediate benefit is that we save a stack frame. 2. The hidden benefit is that we never need to push the old exception masking state onto the stack. If we had multiple mask_ frames on the stack simultaneously, we wouldn’t know what to do when returning: should we unmask them, or should they stay masked? We’d need to push that information onto the stack in the same way we must push a return address when calling a function. By skipping these redundant stack frames, we can always be certain the right thing to do on return is to unmask async exceptions. No need to store anything else. (This explanation is a slight simplification, especially once maskUninterruptible comes into play, but it’s close enough.) Now you may see the looming problem: this strategy completely breaks down in the presence of delimited continuations. With delimited continuations, we might have a program like this: mask_ $ prompt $ mask_ $ ... If we capture a continuation up to this prompt, we expect the inner mask_ frame to be captured along with it. But that won’t happen if we never pushed a mask_ frame at all due to the aforementioned optimization. So now I can finally state my question: what is the right solution for this? I see three obvious possible ways forward: 1. Keep track of whether or not we’re inside a prompt and skip the optimization in that case. 2. Keep some bookkeeping that tracks the modifications to the async exception masking state since the most recently pushed prompt. 3. Just don’t bother with the optimization at all. Option 3 certainly seems the most appealing from a simplicity point of view, and I suspect the optimization doesn’t matter much in practice. Why? Because the real `mask` implementation from Control.Exception already avoids re-masking exceptions if they’re masked! (And that’s okay, because prompt# and control0# are not intended to be used directly in IO, so code that uses them can provide its own version of `mask`.) However, it is admittedly possible for the restore action passed to the argument of `mask` to create redundant calls, as the check is only performed in `mask` itself. Is eliminating this optimization an acceptable compromise? Or is there reason to believe this is important for performance of real programs? Thanks, Alexis [1]: https://github.com/ghc-proposals/ghc-proposals/pull/313 [2]: https://gitlab.haskell.org/lexi.lambda/ghc/-/commits/first-class-continuati…

4 3

Perf notes
by Simon Peyton Jones 02 Jul '20

02 Jul '20

Despite a recent git fetch https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/ci/perf I'm getting lots of perf regressions in HEAD. For example =====> T9203(normal) 1 of 1 [0, 0, 0] ]0;T9203(normal) 1 of 1 [0, 0, 0]cd "T9203.run" && "/home/simonpj/code/HEAD-3/inplace/bin/ghc-stage2" -o T9203 T9203.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O2< cd "T9203.run" && ./T9203 +RTS -V0 -tT9203.stats --machine-readable -RTS < runtime/bytes allocated increased from x86_64-linux-deb9 baseline @ HEAD~28: Expected T9203 (normal) runtime/bytes allocated: 56046952.0 +/-5% Lower bound T9203 (normal) runtime/bytes allocated: 53244604 Upper bound T9203 (normal) runtime/bytes allocated: 58849300 Actual T9203 (normal) runtime/bytes allocated: 108464536 Deviation T9203 (normal) runtime/bytes allocated: 93.5 % *** unexpected stat test failure for T9203(normal) Performance Metrics (test environment: local): T9203(normal) runtime/bytes allocated 108464536.000 (baseline @ HEAD~28) 56046952.000 [increased, 93.5%] What am I doing wrong? Simon

2 6

perf regression with TypeFamilies
by Richard Eisenberg 02 Jul '20

02 Jul '20

Hi Harendra, I saw your comment on a ghc proposal (https://github.com/ghc-proposals/ghc-proposals/pull/343#issuecomment-650797…) that said you experienced perf regressions with -XTypeFamilies enabled (but no other changes). Are these reproducible in a way that can be shared publicly? And are the regressions in compile times or run times? -XTypeFamilies enables -XMonoLocalBinds, which disables let-generalization on some nested lets. It is thus just barely conceivable that different Core is produced depending on this extension, and that there may be a possibility of performance changes. But this would be unexpected, and something worth investigating. In other words: if you can, do please post a bug -- simply enabling -XTypeFamilies should not slow anything down! Thanks, Richard

2 2