- ghc-devs - Haskell.org

Serious bug in GHC 9.4 on basic math on aarch64
by Ian-Woo Kim 14 Oct '22

14 Oct '22

Hi, We found a reproducible error with a simple math test (div/mod) on aarch64. (on linux, on macos), so we want to call for attention on this. https://gitlab.haskell.org/ghc/ghc/-/issues/22282 This was originally caught by this issue: https://github.com/haskell-foundation/foundation/issues/571 Thank you! Ian-Woo Kim Mercury Technologies

4 4

Milestones page is missing or has inaccurate dates
by George Colpitts 13 Oct '22

13 Oct '22

Hi The Milestones page <https://gitlab.haskell.org/ghc/ghc/-/milestones> is missing many dates or has inaccurate dates: - Most milestones don't have any associated completion date. - As far as I know 9.4.2 and 9.2.4 are released but the milestones pages doesn't seem to show that. Can the page be updated so we have an idea of what is coming when? There has been a lot of great work done and I know a lot is being worked on. It would be great if the milestones page could be updated to better reflect that. Thanks George

3 4

Warnings in RTS
by Simon Peyton Jones 11 Oct '22

11 Oct '22

Whenever I compile the RTS I get these warnings. Are they necessary? Simon In file included from rts/Schedule.c:16:0: error: rts/Schedule.c: In function ‘schedule’: rts/Schedule.h:143:1: error: warning: inlining failed in call to ‘appendToRunQueue’: call is unlikely and code size would grow [-Winline] 143 | appendToRunQueue (Capability *cap, StgTSO *tso) | ^~~~~~~~~~~~~~~~ | 143 | appendToRunQueue (Capability *cap, StgTSO *tso) | ^ rts/Schedule.c:1226:9: error: note: called from here 1226 | appendToRunQueue(cap,t); | ^~~~~~~~~~~~~~~~~~~~~~~ | 1226 | appendToRunQueue(cap,t); | ^ In file included from rts/Schedule.c:16:0: error: rts/Schedule.h:164:1: error: warning: inlining failed in call to ‘pushOnRunQueue’: call is unlikely and code size would grow [-Winline] 164 | pushOnRunQueue (Capability *cap, StgTSO *tso) | ^~~~~~~~~~~~~~ | 164 | pushOnRunQueue (Capability *cap, StgTSO *tso) | ^ rts/Schedule.c:1228:9: error: note: called from here 1228 | pushOnRunQueue(cap,t); | ^~~~~~~~~~~~~~~~~~~~~ | 1228 | pushOnRunQueue(cap,t); | ^ rts/Schedule.c: At top level: cc1: warning: unrecognized command line option ‘-Wno-nonportable-include-path’

2 1

Implementing a compilation server
by Domínguez, Facundo 11 Oct '22

11 Oct '22

Dear ghc devs, I'm using the ghc API to write a compilation server (a.k.a. persistent worker). The idea is to serve requests to compile individual modules. In this fashion, we can compile modules with different compilation flags and yet pay only once for the startup overheads of the compiler. One challenge of this approach is to reuse as much as possible from the ghc API session/environment from one compilation request to the next, so we save the trouble of reconstructing it each time. This message is to ask for advise on how to better accomplish this reuse. I tried reusing the whole environment for multiple requests, but I'm conjecturing that this might cause troubles when the requests require building modules with different values of -this-unit-id. Another problem that streams from this is that recompiling a module which defines a type class instance fails because it encounters in the environment the type class instance from the previous compilation. My work-in-progress implementation is here [1]. There appears to be multiple ways to compile a module in the API, so far I have been trying DriverPipeline.compileFile. My best lead right now is to look for inspiration in how GHCi implements the load command, but this does a sort of --make compilation while I'm going here for the one-shot style. Thanks in advance, Facundo [1] https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebc…

2 3

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 06 Oct '22

06 Oct '22

Dear Haskell community, the GHC Steering committee is seeking nominations for one or more new members. The committee scrutinizes, nitpicks, improves, weighs and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to maintain in perpetuity in GHC's code base, to learn, and to deal with its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore seek a balance of background, expertise, and views on the committee. Membership of the committee gives you the chance to influence the future direction of Haskell, and to serve the Haskell community. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Looking up names in an "opportunistic" type checker plugin
by Erdi, Gergo 03 Oct '22

03 Oct '22

PUBLIC Hi, I'm writing a type checker plugin that should do things whenever used in the context of a module that already has some definitions loaded. I've hacked together the following function using internal details that I feel I should not be using: lookupOrigMaybe :: Module -> OccName -> TcPluginM (Maybe Name) lookupOrigMaybe mod occ = do hsc_env <- getTopEnv unsafeTcPluginTcM $ liftIO $ updateNameCache (hsc_NC hsc_env) mod occ $ \cache0 -> do let name = lookupOrigNameCache cache0 mod occ return (cache0, name) I would like to do this in a nicer way instead. It should be enough to check that the given module is already loaded, since for my use case, if the module is there but the name isn't, then all bets are off and my plugin might as well just error out. So I was hoping I could use `findImportedModule` followed by `lookupOrig`, but alas, `findImportedModule` fails me in one of two ways: 1. If I don't specify the package (i.e. use `NoPkgQual`), `findImportedModule` seems to return a `Found{}` result even when the module isn't actually loaded yet, leading to `lookupOrig` failing: attempting to use module 'main:Cortex.Stem.Relation.Types' (Cortex.Stem.Relation.Types) which is not loaded 1. If I do specify the package (using `ThisPkg`), then `findImportedModule` chokes in situations when the given unit would come "later" in the dependency graph than the currenty processed one: ghc-mu-core-to-exp: panic! (the 'impossible' happened) GHC version 9.5.20220830: findImportModule Cortex.Stem.Relation.Types "main" Just ghc-bignum main [ghc-bignum, cortex-prim] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:188:37 in ghc-lib-0.20220830-FvKByKwp6ri5ICk6wiQO8W:GHC.Utils.Panic pprPanic, called at compiler/GHC/Unit/Finder.hs:160:32 in ghc-lib-0.20220830-FvKByKwp6ri5ICk6wiQO8W:GHC.Unit.Finder Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug So my question then, is what is the recommended way of looking up a loaded definition opportunistically from a type checker plugin? 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.

1 0

Re: Overnight CI failures
by Bryan Richter 30 Sep '22

30 Sep '22

(Adding ghc-devs) Are these fragile tests? 1. T14346 got a "bad file descriptor" on Darwin 2. linker_unload got some gold errors on Linux Neither of these have been reported to me before, so I don't know much about them. Nor have I looked deeply (or at all) at the tests themselves, yet. On Thu, Sep 29, 2022 at 3:37 PM Simon Peyton Jones < simon.peytonjones(a)gmail.com> wrote: > Bryan > > These failed overnight > > On !8897 > > - https://gitlab.haskell.org/ghc/ghc/-/jobs/1185519 > - https://gitlab.haskell.org/ghc/ghc/-/jobs/1185520 > > I think it's extremely unlikely that this had anything to do with my patch. > > Simon >

1 0

Consistent CI failure in job nightly-i386-linux-deb9-validate
by Bryan Richter 29 Sep '22

29 Sep '22

Hi all, For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2… To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :(

2 7

Pushing to nofib
by Simon Peyton Jones 27 Sep '22

27 Sep '22

Friends How do I push to the nofib/ repository? I just wanted to add some documentation. I'm on branch 'master' and tried to push. Got this below. What next? Thanks Simon bash$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 24 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 543 bytes | 543.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: GitLab: You are not allowed to push code to protected branches on this project. To gitlab.haskell.org:ghc/nofib.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git@gitlab.haskell.org:ghc/nofib.git' simonpj@LHR-WD-22561:~/code/HEAD-1/nofib$

2 1

GItlab search
by Simon Peyton Jones 26 Sep '22

26 Sep '22

Friends I'm struggling with GitLab search. eg I was looking for #22200 I wen to https://gitlab.haskell.org/ghc/ghc/-/issues, and put "-DEEBUG" and "slow" in the search box. No #22200. Yet both of those strings appear in the title of the ticket. Looking for DEBUG or *DEBUG also fails. I find that DDEBUG succeeds. What are the rules? Thanks Simon

2 1