November 2021 - ghc-devs

Re: How to build Haddock documentation quickly?
by Andrey Mokhov 21 Nov '21

21 Nov '21

Hi Norman, > I'm more than willing to dive into Hadrian and figure out how it works. > I could even add a new target to build just what I'm interested in. > But I would need help. I've spent some time poking around the `doc` directory, and I've read > the Shake papers (and some of Andrei's work) but I've never used these tools myself. I would be delighted to help you (or anyone else!) navigate Hadrian source code. Please feel free to get in touch directly. (Alas, in the last couple of years I couldn't contribute to improving Hadrian but that's not for the lack of desire - just due to some life changes. Hopefully I can at least help by helping others!) Cheers, Andrey

1 0

How to build Haddock documentation quickly?
by Norman Ramsey 20 Nov '21

20 Nov '21

In service of #20528, I'm trying to clean up some Haddock documentation in the GHC sources. The only command I know is ./hadrian/build -j _build/docs/html/index.html It turns out that if I change Haddock comments in one file (GHC/Tc/Gen/Foreign.hs), rebuilding the HTML takes a minute and a quarter. That's a little long. (And I had one build take over four minutes, which is even longer.) What tricks can I use to speed up this process? Might there be a way to run Haddock directly until things are to my liking? Norman

2 2

DWARF support
by Richard Eisenberg 20 Nov '21

20 Nov '21

Hi devs, I was intrigued by Bodigrim's comment about HasCallStack in base (https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-9…) that there are other alternatives, such as DWARF. Over the years, I had tuned out every time I saw the word DWARF: it was (and is!) an unknown acronym and seems like a low-level detail. But Bodigrim's comment made me want to re-think this stance. I found Ben's series of blog posts on DWARF, starting with https://www.haskell.org/ghc/blog/20200403-dwarf-1.html. These are very helpful! In particular, they taught me that DWARF = platform-native debugging metadata. Is that translation accurate? If so, perhaps we should use both names: if I see that GHC x.y.z has DWARF support, I quickly scroll to the next bullet. If I see that GHC x.y.z has support for platform-native debugging metadata and is now compatible with e.g. gdb, I'm interested. Going further, I have a key question for my use case: is this support available on Mac? The first post in the series describes support for "Linux and several BSDs" and the last post says that "Windows PDB support" is future work. (Is "PDB" platform-native debugging metadata for Windows? I don't know.) But I don't see any mention of Mac. What's the status here? It would be very cool if this conversation ends with me making a video on how a few simple GHC flags can allow us to, say, get a stack trace on a pattern-match failure in a Haskell program. Thanks! Richard

8 13

[ANNOUNCE] GHC 9.2.1 now available
by Ben Gamari 18 Nov '21

18 Nov '21

Hi all, The GHC developers are very happy to at long last announce the availability of GHC 9.2.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1 GHC 9.2 brings a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merging of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [`-hi` profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices. * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Faster compilation and a smaller memory footprint * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket] if you see anything amiss. Happy testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

6 8

Interpreter thread in ghc-8.10.6 in macOS
by Domínguez, Facundo 17 Nov '21

17 Nov '21

Dear devs, I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving differently than previous compilers when running Template Haskell code. When upgrading HaskellR to use a newer ghc I found that it would work fine with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R runtime in particular, is sensitive to local state in the threads that are used to execute the runtime. HaskellR is arranging to run the R runtime when running TemplateHaskell splices, and this stopped working in MacOS with ghc-8.10.6. The error I got is not new. It comes from R and we would get it in ghci if we try to use HaskellR without passing the command line flag -fno-ghci-sandbox. But this is the first time we get the error when using TemplateHaskell. Does anyone know if there have been changes to the threads in which the TH splices are run? And were there any changes specific to TH in MacOS? Thanks in advance, Facundo [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170

3 4

request for comments: foreign calls (#20693)
by Norman Ramsey 17 Nov '21

17 Nov '21

I'd like it to be easier to extend GHC with support for new species of foreign calls. Existing support makes it easy to *replace* GHC's implementation of foreign calls but not to *extend* it. Details in #20693 (https://gitlab.haskell.org/ghc/ghc/-/issues/20693) I'd welcome comments, especially from anyone involved with GHCJS. Norman

1 0

Defaulting design choices
by Simon Peyton Jones 16 Nov '21

16 Nov '21

Sam, Richard, Adam, Vlad, Ryan, and other people interested in GHC's type system. Following discussion with Richard, I have created a new ticket #20686 for Make the design of defaulting explicit<https://gitlab.haskell.org/ghc/ghc/-/issues/20686>. This should inform !6851 which is trying to finish up Concrete# constraints. Please have a look - we 'd love your views on The Choice. Richard especially, but everyone really: feel free to edit the Description to make it more clear/accurate. I propose to treat it as our master design document. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj(a)microsoft.com.)

1 0

Case split uncovered patterns in warnings or not?
by Sebastian Graf 10 Nov '21

10 Nov '21

Hi Devs, In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 we saw that GHC >= 8.10 outputs pattern match warnings a little differently than it used to. Example from there: {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}foo :: [a] -> [a]foo [] = []foo xs = ys where (_, ys@(_:_)) = splitAt 0 xsmain :: IO ()main = putStrLn $ foo $ "Hello, coverage checker!" Instead of saying ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns not matched: (_, []) We now say ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns of type ‘([a], [a])’ not matched: ([], []) ((_:_), []) E.g., newer versions do (one) case split on pattern variables that haven't even been scrutinised by the pattern match. That amounts to quantitatively more pattern suggestions and for each variable a list of constructors that could be matched on. The motivation for the change is outlined in https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110, but I could easily be swayed not to do the case split. Which arguably is less surprising, as Andreas Abel points out. Considering the other examples from my post, which would you prefer? Cheers, Sebastian

5 7

[RFC] Split the GHC.* hierarchy from `base` in its own package, `ghc-base`
by Hécate 09 Nov '21

09 Nov '21

Hello everyone, after a chat with Ben and seeing the idea thrown around, I have opened an RFC ticket to explore designs regarding a split of the GHC.* hierarchy from base, into its own package. The RFC is here: https://gitlab.haskell.org/ghc/ghc/-/issues/20647 Please do keep the comments in the ticket so that this discussion may be better archived. Cheers! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

advice on minor cleanups?
by Norman Ramsey 09 Nov '21

09 Nov '21

All, It appears that `runHscBackendPhase` returns a tuple that include an element of type `Maybe Linkable` but that in practice is always `Nothing`. I'm thinking of removing this element from the tuple, which would also entail simplifying the type of value constructor `T_HscBackend` for the `TPhase` type. Simplifying the code seems like a good thing, but perhaps there is a reason to leave well enough alone? Please advise me. Norman

3 3