- ghc-devs - Haskell.org

Hadrian
by Simon Peyton Jones 11 Jul '22

11 Jul '22

I am working on a branch of GHC, actually on !8210. I have rebased on master. Then I say

3 7

Re: 9.4.1 Final Call
by Ryan Scott 05 Jul '22

05 Jul '22

One thing that wasn't included in the list but arguably should be is #21618 (Loading libc++ in ghci results in segfaults). As far as I am aware, this renders GHC 9.4 unusable on Windows for libraries that link against C++. (Or, at the very least, I haven't figured out a way to make it work.) Best, Ryan S.

1 0

9.4.1 Final Call
by Matthew Pickering 05 Jul '22

05 Jul '22

Hello all, This is the final call for patches which need to be included in 9.4.1. The status of which I do not know the answer: * GHC 9.4 infinite loop in typechecker - #21530 (@simonpj, @rae) ? To my knowledge the remaining unfinished work list is: * Resolve static linking issues with text-2.0 - #21787 (Unresolved) (Matt/Ben/Zubin/Tamar/Andreww) * CAF reachability bug with -fprof-late - !7797 (WIP) (Andreas/Ben) * XMonad segfault - #21708 (WIP) (Ben/Andreas) * HIE File Fixes - !7888 (landing) (Zubin) * template-haskell-2.19.0.0 depends on filepath - !8516 (landing) (Matt) * Module loops and multiple home units leads to a panic - !8573 (nearly ready to land) (Matt) * extendMG leaks memory - #21816 (Zubin/Matt) To my knowledge, the following are not making it into 9.4.1.. but are not critical to revert: * Tidy up withDict and friends - #21568 Looking like a great release. Matt

2 1

Howto build optimized with stack traces/9.2.3 build broken?
by Benjamin Maurer 03 Jul '22

03 Jul '22

Hey all, I'm trying to debug a segfault caused by my optimization. GHC only segfaults when compiled with -O2 and my flag, i.e., I used the "perf" flavour: > ./hadrian/build -j "stage1.*.ghc.hs.opts += -fregs-ssa" --flavour=perf However, I can't get a stack trace. [1] suggests I need a profiling build for that. So I tried: > ./hadrian/build -j "stage1.*.ghc.hs.opts += -fregs-ssa" --flavour=perf+debug_info+profiled_ghc+no_dynamic_ghc Unfortunately, I'm using GHC 9.2.1 from ghcup to bootstrap and this version doesn't come with profiling enabled base [2]. 8.10.7, which I have installed, can't compile ghc anymore (it seems). So I tried 9.2.3 from ghcup and that gives me the strangest errors. Basically, the compiler seems completely bricked. I installed 9.2.3, ran "hadrian/build clean", "./configure && ./boot" and the same line as above with both "default" and "perf" flavours. When I try to compile nofib/spectral/simple, I get: > /home/ben/Projekte/haskell/ghc/_build/stage1/bin/ghc -O2 Main.hs > [1 of 2] Compiling Main ( Main.hs, Main.o ) > Main.hs:1125:1: error: lexical error (UTF-8 decoding error) (Main.hs only has 1124 lines though, file was not modified, compiles fine with any other ghc version) But most programs I tried give me: > /home/ben/Projekte/haskell/ghc/_build/stage1/bin/ghc -O2 Main.hs > ghc: Unable to commit 283468890112 bytes of memory > ghc: Exiting. The system might be out of memory. Oh kay. I got 16GB RAM, 10 gig available. GHC 9.2.3 works fine. Is my flavour combination bad, or what is broken here? Any other (better) way to get an optimized build with all the debugging aids I can get? I heard GHC 9.2.2 is a broken release, or does anyone know whether it works on Linux x86_64 (and comes with profiling libs from ghcup) - maybe I can get a working version using that? I'd try, but creating a new build takes almost an hour and I have spent most of the day trying to solve this. I am puzzled and desearate to fix my bug and get a working compiler. Appreciate any help! Best Regards, Benjamin [1] https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/doc/debugging.md [2] https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/296

1 0

RST Documentation Trick for reference links
by Matthew Pickering 01 Jul '22

01 Jul '22

Hello, I noticed myself writing things like: ``` and enable the eventlog using :rts-flag:`-l ⟨flags⟩`. ``` When in fact what I wanted was to create a link the eventlog options but render the link as just -l rather than -l <flags>.. but I thought I had to write the whole thing to get the linter to not complain. It turns out can achieve this goal using the following syntax: ``` and enable the eventlog using :rts-flag:`-l <-l ⟨flags⟩>`. ``` ie, include the thing you actually want to reference in angular brackets < > and the text you want to render before that. Yet another thing which has changed my life for good. Cheers, Matt

1 0

Guide for testing hackage documentation upload
by Matthew Pickering 01 Jul '22

01 Jul '22

Hi all, In case anyone needs this in the future or is interested then I wrote a little guide about how to test the upload of hackage documentation locally. https://gitlab.haskell.org/ghc/ghc/-/wikis/testing-hackage-documentation Cheers, Matt

1 0

Imminent Removal of Make Build System
by Matthew Pickering 30 Jun '22

30 Jun '22

Hi all, We are imminently going to remove the make build system. See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7094 There is quite extensive documentation about using hadrian, the best place to start is the in-tree documentation: https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/README.md For packagers: * The 9.4.* series will be the last release series which can be built with the make build system. * 9.6.* will only be able to be built using hadrian. * See ghcs-nix for an example of how to modify your own build system to use hadrian: https://gitlab.haskell.org/bgamari/ghcs-nix/-/blob/master/hadrian.nix * Sam Derbyshire is creating a guide aimed at packagers describing how to migrate their build plans. Cheers, Matt

2 1

Re: Migration guide for multiple home units
by Erdi, Gergo 30 Jun '22

30 Jun '22

PUBLIC Thanks, based on this I got things going. I might have to come back to you if it turns out something's still broken in my original full application. -----Original Message----- From: Matthew Pickering <matthewtpickering(a)gmail.com> Sent: Tuesday, June 21, 2022 12:54 AM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: ÉRDI Gergo <gergo(a)erdi.hu>; GHC Devs <ghc-devs(a)haskell.org>; Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com> Subject: [External] Re: Migration guide for multiple home units My issue was caused by running the program in a dirty tree :) Find the modified program here - https://clicktime.symantec.com/39Wzk4MM32vW4JJm9h9nYC96xn?u=https%3A%2F%2Fg… I compiled it with HEAD. Hope you can make sense of it, I think it's simpler than before. Cheers, Matt On Mon, Jun 20, 2022 at 5:47 PM Matthew Pickering <matthewtpickering(a)gmail.com> wrote: > > Gergo, I rewrote your example program for the new API but didn't quite > manage to finish today. I will finish it off and post it tomorrow. > > Matt > > On Mon, Jun 20, 2022 at 6:16 AM Erdi, Gergo <Gergo.Erdi(a)sc.com> wrote: > > > > PUBLIC > > > > I managed to get this working, but I would like some feedback from Matt or others on whether this is the intended way of doing this. > > > > 1. The `extendMG` change can be brute-forced just to keep things going, by looking up dependency `ModSummary`s by `ModName` (we don't have full `Module`s at this point yet!): > > > > registerModSummary :: (GhcMonad m) => ModSummary -> m () registerModSummary ms = modifySession \env -> > > let mg = hsc_mod_graph env > > -- TODO: of course with a bit more housekeeping we can do better than this... > > edges = [ NodeKey_Module $ msKey ms' | dep <- deps, ms' <- mgModSummaries mg, ms_mod_name ms' == dep ] > > mg' = extendMG mg edges ms > > in env{ hsc_mod_graph = mg' } > > where > > deps = map (unLoc . snd) $ ms_textual_imps ms > > > > 2. `registerModule` can be kept mostly as-is, since it only uses `modifyUnitState` to change the active unit: > > > > registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m () registerModule details iface = modifySession $ extendHpt . addModule > > where > > hmi = HomeModInfo iface details Nothing > > > > mod = mi_module iface > > modOrig = ModOrigin (Just True) [] [] True > > > > addModule = modifyUnitState $ \us -> us > > { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod modOrig) $ moduleNameProvidersMap us > > } > > > > extendHpt = hscUpdateHUG $ addHomeModInfoToHug hmi > > > > modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv modifyUnitState f env = env > > { hsc_unit_env = let ue = hsc_unit_env env in > > let units = ue_units ue > > units' = f units > > in ue_setUnits units' ue > > } > > > > 3. The tricky part is getting `addUnit` right. For this, based on the implementation of `initUnits`, I came up with the following: > > > > modifyUnitEnv :: (UnitEnv -> UnitEnv) -> HscEnv -> HscEnv modifyUnitEnv f env = env > > { hsc_unit_env = let ue = hsc_unit_env env in f ue > > } > > > > addUnit :: DynFlags -> UnitId -> HscEnv -> HscEnv addUnit dflags unitId = modifyUnitEnv $ \ue -> > > let dbs = ue_unit_dbs ue > > unit_state = ue_units ue > > home_unit = ue_homeUnit ue > > in flip updateHug ue $ unitEnv_insert unitId $ HomeUnitEnv > > { homeUnitEnv_units = unit_state > > , homeUnitEnv_unit_dbs = dbs > > , homeUnitEnv_dflags = dflags > > , homeUnitEnv_hpt = emptyHomePackageTable > > , homeUnitEnv_home_unit = home_unit > > } > > > > setCurrentUnit :: UnitId -> HscEnv -> HscEnv setCurrentUnit unitId = > > modifyUnitEnv $ ue_setActiveUnit unitId > > > > > > So my questions about this: > > > > 1. How does setting the home unit make sense? By doing this, I am effectively setting the home unit to `main` for all units, since that's the initial `ue_homeUnit` of the initial unit environment. Or does it not matter because after `addUnit`, I call `setCurrentUnit` anyway? I've found that I can't use the unit I am just adding as its own home unit, because that then leads to module name resolution problems in `main`: every imported module from `main` is searched for in `main` instead of its correct unit. > > > > 2. Speaking of `main`, why is it that when adding units, I have to skip `mainUnitId`, otherwise module resolution breaks again? > > > > 3. Unlike the previous version, I am no longer creating and putting `UnitInfo`s anywhere. Where is this going to bite me? Where (if anywhere) should I put `UnitInfo`s with the new setup? > > > > Thanks, > > Gergo > > > > > > -----Original Message----- > > From: ÉRDI Gergő <gergo(a)erdi.hu> > > Sent: Sunday, June 19, 2022 12:32 PM > > To: Erdi, Gergo <Gergo.Erdi(a)sc.com> > > Cc: GHC Devs <ghc-devs(a)haskell.org>; Montelatici, Raphael Laurent > > <Raphael.Montelatici(a)sc.com> > > Subject: [External] Re: Migration guide for multiple home units > > > > > > On Thu, 16 Jun 2022, Erdi, Gergo via ghc-devs wrote: > > > > > Is there a migration guide for GHC API clients for the new “multiple home units” > > > feature? > > > > OK so in concrete terms, please see my attached program which is a heavily cut-down, standalone version of my real program. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400^ (i.e. > > 3219610e3ba6cb6a5cd1f4e32e2b4befea5bd384) it compiles and works as expected. On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400 onwards, two problems pop up: > > > > 1. `extendMG` has changed and now requires manually specifying outgoing dependency edges. I thought the whole point of `summariseFile` was to collect this information? The reason I need to `extendMG` at that point is to get intra-unit orphan instances working. > > > > 2. `modifyUnitState` and its two uses (`addUnit` and `registerModule`) need to be updated to the new API. I think it makes sense that these need changing, since they touch exactly on the issue of which units are being compiled right now. However, I don't know how to update these. Also, I guess `setHomeUnit` should change the `CurrentUnit` instead of the `HomeUnit` now? > > > > Thanks, > > Gergo > > > > This email and any attachments are confidential and may also be > > privileged. If you are not the intended recipient, please delete all > > copies and notify the sender immediately. You may wish to refer to > > the incorporation details of Standard Chartered PLC, Standard > > Chartered Bank and their subsidiaries at https: > > //www.sc.com/en/our-locations > > > > Where you have a Financial Markets relationship with Standard > > Chartered PLC, Standard Chartered Bank and their subsidiaries (the > > "Group"), information on the regulatory standards we adhere to and > > how it may affect you can be found in our Regulatory Compliance > > Statement at https: //www.sc.com/rcs/ and Regulatory Compliance > > Disclosures at http: //www.sc.com/rcs/fm > > > > Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > > > Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. > > > > Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. > > > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

1 1

Release Plans - 9.4.1 and 9.2.4
by Matthew Pickering 30 Jun '22

30 Jun '22

Hello all, Welcome to another update on our release plans. 9.4.1 (Ben Gamari) ~~~~ We proceed smoothly onwards towards the release at the end of July. The alpha3 was released last week - https://discourse.haskell.org/t/ghc-9-4-1-alpha3-now-available/4701 The next release is scheduled to be the first release candidate. 9.2.4 (Zubin Duggal) ~~~~ We intend to also publish a new version in the 9.2 series before the end of July. The priority of this release is motivated by: * Adding support for the DeepSubsumption language extension * Fixing some critical RTS bugs Cheers, Matt

1 0

GHC 9.4.1-alpha3 now available
by Ben Gamari 24 Jun '22

24 Jun '22

The GHC developers are happy to announce the availability of the third alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.1-alpha3). This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it's possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We would like to thank Microsoft Azure, GitHub, IOG, 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. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha3/docs/users_guide/9.4.1-note…

1 0