- ghc-devs - Haskell.org

Re: Where (else) do I need to register instances from loaded modules?
by Erdi, Gergo 24 Aug '21

24 Aug '21

INTERNAL Hi, Thanks Matt! Unfortunately, I couldn't get it working even with these suggestions. 1. I changed registerModule so that it only changes the HPT when toUnitId (moduleUnit mod) == homeUnitId (hsc_dflags env). But I'm pretty sure this will be vacuously true, since the unit of the module comes from prepareModule setting the home unit before the call to `downsweep`. TBH I don't understand the whole idea behind the home package, and maybe all my pain comes from misusing packages in the first place. As you can see in the original code I've sent, I'm loading modules from different units; in my real use case, I'd even like to do things like load module1 from unit1, then module2 from unit2, then module3 from unit1 again -- basically just using the units as a cheap way to classify modules so that later downstream, I can make decisions based on the unit of the module of the source of a given definition. Should I give up on this idea, is this going to lead to problems later on? 2. I also changed mkModIface to fill in the `deps` and while I'm at it, the `usages` field, by copy-pasting more code from mkIfaceTc. I'm really starting to think that I'd be better off just changing mkIfaceTc to return a PartialModIface... Anyway, the new definitions of `deps` and `usages` are: let pluginModules = map lpModule (cachedPlugins (hsc_dflags hsc_env)) unit_id = homeUnitId (hsc_dflags hsc_env) deps <- mkDependencies unit_id (map mi_module pluginModules) tcg dep_files <- readIORef dependent_files let used_names = mkUsedNames tcg usages <- mkUsageInfo hsc_env this_mod (imp_mods imports) used_names dep_files merged pluginModules With these changes applied, I am still seeing the same error. Printing shows that `dep_orphs deps` is empty for Instance.src; further tracing, in turn, shows that `imp_orphs . tcg_imports $ tcg` is also empty! I have also found the wording in the documentation regarding dep_orphs confusing: it sounds like, in my case, this would mean that Use has a dependency on Instance, because it is using an orphan instance from there. But my problems are way before I am making a ModIface for Use, since it fails already during typechecking. But you saying the problem is the incomplete deps in ModIface must mean that dep_orphs needs to be filled in the ModIface for Instance (or, oh god I hope not, Class), right? If I sound somewhat confused, rest assured that in reality I am even MORE confused! Any further advice welcome, Gergo -----Original Message----- From: Matthew Pickering <matthewtpickering(a)gmail.com> Sent: Tuesday, August 24, 2021 5:16 PM To: Erdi, Gergo <Gergo.Erdi(a)sc.com> Cc: GHC <ghc-devs(a)haskell.org>; gergo(a)erdi.hu; Montelatici, Raphael Laurent <Raphael.Montelatici(a)sc.com> Subject: [External] Re: Where (else) do I need to register instances from loaded modules? Hi Gergo, Some things I noticed: * The HPT only contains modules from the current home unit. It seems that registerModule ignores this so you break this invariant. * It seems that `Instance` contains an orphan, but you don't fill in the `deps` field when making a `ModIface`, which should contain all the orphan modules below the module you are compiling. I think that if you fill in `deps` correctly then things may work out. `Dependencies` eventually becomes `ImportAvail`, which gets consulted by `tcVisibleOrphanMods` which is called in `tcGetInstEnvs` which is called by `matchInstEnv`. Matt 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

Where (else) do I need to register instances from loaded modules?
by Erdi, Gergo 24 Aug '21

24 Aug '21

PUBLIC Hi, I am trying to typecheck & load three modules using the GHC API. The first one defines a class, the second one defines an instance of said class, and the third one uses the instance (attached as Class.src, Instance.src and Use.src, respectively). The problem is that when I typecheck Use.src, it complains about the missing instance. It should be noted that the class is found, only the instance isn't. My code is bypassing the normal GHC driver to feed it modules instead of letting GHC itself come up with dependencies and then loading them from disk; that is because in my real use case, some dependencies will have interfaces generated on the fly (there is no underlying Haskell source code), or loaded over HTTP, etc. So I am using parseModule and typeCheckModule on each module, make a ModIface from each, and then I try to register them with GHC, by extending the HPT, the moduleNameProvidersMap, and the EPS. Evidently, this is not enough, and the instances should be registered somewhere else as well - where is that place? I have attached a simplified version of my code as Main.hs; it is targeting the GHC 9.0 API. It hardcodes the GHC 9.0 package.conf.d due to laziness on my part; please change line 96 to your environment before running it. As written, it fails when typechecing Use.src with: input/Use.src:7:7: error: * No instance for (C X) arising from a use of 'method' * In the expression: method In an equation for 'foo': foo = method | 7 | foo = method | ^^^^^^ 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.

2 1

git issues or repository issues?
by Karel Gardas 24 Aug '21

24 Aug '21

Hello, for around a year or two I do have issues which updating ghc git repository. There are actually two issues. The clone is created as recommended by ghc.dev: $ git clone --recurse-submodules https://gitlab.haskell.org/ghc/ghc.git Update is performed as recommended too: $ git pull --recurse-submodules. After some time (accumulated patches) since I update monthly or bi-monthly to test I see those two issues: 1. this is what fails first and is able to be "fixed" by running another pull: Fetching submodule utils/hsc2hs fatal: remote error: upload-pack: not our ref 0584d4fd443ac7a8e397895a79d162a55e36ef00 fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref 57d23853806add183308178663c7e22fbef2417f fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref 5361c3d9503d017d5f42daff793837a017e4f7a7 fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref e5a6da21382ae76098a4f02148504b9f79e5e2ff fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref 3373ca908ad059cbadb526e6ed1dcba5679b0d72 fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref 659eb37eb84e9cbdef226726f46a0fa5608eab5c fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref 40e1c4eb53c1e65be23e91f63139aa16111bbdf3 fatal: the remote end hung up unexpectedly fatal: remote error: upload-pack: not our ref b8ae1bf26ee0e74c3e2eeeee7fc2c7dd0dd2b0a2 fatal: the remote end hung up unexpectedly 2. this one is not-fixable, but hard to judge if this is issue at all or what. Certainly "error" is making me nervous about it. Fetching submodule utils/haddock error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create 'refs/remotes/origin/wip/hsyl20/dynflags' >From https://gitlab.haskell.org/ghc/haddock ! [new branch] wip/hsyl20/dynflags -> origin/wip/hsyl20/dynflags (unable to update local ref) Fetching submodule utils/hsc2hs This all is run on Ubuntu 20.04.x LTS pretty uptodate. The provided git is 2.25.1 there. Does anybody here have any idea why this happens? Thanks! Karel

1 0

[RFC] TcPlugin changes in GHC 9.4: what would you like to see?
by Sam Derbyshire 23 Aug '21

23 Aug '21

Hi all, As you may recall, the API for type-checking plugins is changing (ever so slightly) in GHC 9.4. It was pointed out to me that this might be a good opportunity to make further changes to accommodate other needs of type-checking plugin authors. For the moment, I have one concrete change in mind: changing the TcPluginSolveResult datatype to be a flat record, where one can separately return solved constraints, new constraints and insoluble constraints. This allows plugin authors to return contradictions at the same time as they return solved constraints, which (I have been told) can significantly improve the quality of the error messages. Pattern synonyms can be provided for compatibility, so the impact to plugin authors should be very minimal. I would love to hear other suggestions for improvements. Note however that I believe it is best if we keep the GHC API quite sparse, leaving more elaborate design choices to libraries. Thanks, Sam

1 0

[ANNOUNCE] GHC 9.2.1-rc1 now available
by Ben Gamari 22 Aug '21

22 Aug '21

Hi all, The GHC developers are very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-rc1 GHC 9.2 will bring 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. * Merge 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] * Support for profiling of pinned objects with the cost-centre profiler (#7275) * 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 give this release a try and 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

3 4

The State of GHC 8.10
by Zubin Duggal 21 Aug '21

21 Aug '21

Hi all, GHC 8.10.6 was released last week, with high hopes of finally putting an end to the long running saga of the GHC 8.10 series. Unfortunately, this was not to be the case as we soon discovered #19950, an issue that we claimed to have fixed in the 8.10.6 release, was still affecting the released compiler. #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). It surfaced in GHC 8.10.5 since we upgraded the toolchain on our Darwin builders to one of the affected versions. The original fix/workaround for #19950 was tested on the master and GHC-9.2 branches and found to be working, and so backported to the 8.10 branch. Unfortunately, Darwin releases for 8.10 are still done using the Make build system, which did not pick up the extra linker options needed to work around the issue. It places a heavy burden on developers to have so many active branches of the compiler to keep in mind, and the current situation with 4 active branches is simply not sustainable. As the oldest currently active branch, it is currently a priority to retire the 8.10 branch of GHC from active development as soon as possible. We have now fixed and verified the fix for #19950 on the 8.10 branch and prepared a GHC 8.10.7 release including it. As of now, the only change in GHC 8.10.7 is to link the x86_64 darwin release build with a few extra linker options to work around #19950. If you have any other critical issues that prevent you from using GHC 8.10(.6), please raise them soon by either pointing to existing tickets on the tracker or creating a new one. We are planning to cut the new release as soon as early next week, and we are really hoping that this would be the final release in the 8.10 series. Cheers, Zubin.

1 0

Call for Participation: Haskell Implementors' Workshop 2021
by Ningning Xie 20 Aug '21

20 Aug '21

Call for Participation ACM SIGPLAN Haskell Implementors' Workshop Sunday 22 Aug 20:00-05:00 (Seoul) https://icfp21.sigplan.org/home/hiw-2021 We are happy to announce that Haskell Implementors' Workshop is taking place this Sunday, co-located with ICFP 2021. The workshop will be live streamed on Youtube. We invite you to watch the talks, and attend the workshop. The program features 11 exciting talks, along with 4 lightning talks. The keynote is given by Bengt Marten Agren (Standard Chartered Bank), on "Haskell reinterpreted – large-scale real-world experience with the Mu compiler in Financial Markets". Program details: https://icfp21.sigplan.org/home/hiw-2021#program Keynote details: https://icfp21.sigplan.org/details/hiw-2021-papers/14/Haskell-reinterpreted… Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnningxie(a)gmail.com>

1 0

Fwd: Unlock instructions
by Bryan Richter 17 Aug '21

17 Aug '21

Hey all, I got this message from gitlab, which makes me think someone is trying to attack the system. I have not tried to log in recently. I have 2FA and unique passwords so I'm not too worried, but just FYI. ---------- Forwarded message --------- From: GitLab <gitlab(a)gitlab.haskell.org> Date: Sat, 14 Aug 2021, 16.42 Subject: Unlock instructions To: <b(a)chreekat.net> Hello, Bryan R! Your GitLab account has been locked due to an excessive amount of unsuccessful sign in attempts. Your account will automatically unlock in 10 minutes or you may click the link below to unlock now. Unlock account <https://gitlab.haskell.org/users/unlock?unlock_token=oeTBsanKDc7a2VUteWUs>

4 3

[Haskell] [ANNOUNCE] GHC 8.10.6 released
by Zubin Duggal 14 Aug '21

14 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.…. As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

Fwd: GHC Module change database
by Ari Fordsham 09 Aug '21

09 Aug '21

AF ---------- Forwarded message --------- From: Ari Fordsham <arifordsham(a)gmail.com> Date: Sun, 8 Aug 2021 at 16:43 Subject: Re: GHC Module change database To: Vaibhav Sagar <vaibhavsagar(a)gmail.com> That's where I generated it from :-) It would be nice to generate that from the new database. My main motivation was as follows: There are two possible paradigms for GHC API compatibility: - Export old names for new modules - as in ghc-api-compat <https://gitlab.haskell.org/haskell/ghc-api-compat> This allows existing code to (kind of) 'just work' - but it doesn't help in managing that code as it gets extended to use new features - Export new names to old modules I am thinking of working on a tool that does this. You need to rewrite code to use current modules (maybe https://github.com/facebookincubator/retrie/issues/33 will help), but then you can just target the latest API, and have compatibility built in. This seems to me better for active codebases. Having a 'single source of truth' database will help with this. AF On Sun, 8 Aug 2021 at 16:36, Vaibhav Sagar <vaibhavsagar(a)gmail.com> wrote: > Hi Ari, > > Have you seen https://gitlab.haskell.org/haskell/ghc-api-compat? > > Thanks, > Vaibhav > > On Mon, Aug 9, 2021 at 1:34 AM Ari Fordsham <arifordsham(a)gmail.com> wrote: > >> I've made a database of GHC API module changes. >> >> https://github.com/AriFordsham/ghc-module-renames >> >> This might be useful for automatic tooling. >> >> It would be nice if this would be moved into the GHC Gitlab, and kept >> up-to-date. >> >> Ari Fordsham >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >

2 1