From matthewtpickering at gmail.com  Mon Aug  2 09:03:55 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 2 Aug 2021 10:03:55 +0100
Subject: How to Collect Type Errors?
In-Reply-To: <CALCz0oZ6y0uvmHgqyy+BzBAiZZ2OxDadx-jYCia5uEibL=Gh6w@mail.gmail.com>
References: <CALCz0oZ6y0uvmHgqyy+BzBAiZZ2OxDadx-jYCia5uEibL=Gh6w@mail.gmail.com>
Message-ID: <CALuQ0m8sh5KJMoJQbpAmkYGr04QxE5VaG-vqS7n2YG2vCmymJw@mail.gmail.com>

Hi Gunda,

Could you be a bit more precise about what you want to achieve? HLS
already displays type errors in your program, perhaps it would be
better to ask someone on the HLS issue tracker how to use their API to
do what you want.

Matt

On Fri, Jul 30, 2021 at 7:03 PM Guanda Yuan <guandayuan0715 at gmail.com> wrote:
>
> Hello all,
>
> I want to write a plugin for Haskell Language Server, to collect type errors in the code. I'm new to GHC API, so I need some help. My current thought is, I can collect diagnostics or the error messages and extract the type error infos. I have tried to referred to the Haddock documentation for GHC API, but I'm still not sure which function should I use.
>
> Thanks,
> Guanda
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From matthewtpickering at gmail.com  Mon Aug  2 10:01:14 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 2 Aug 2021 11:01:14 +0100
Subject: Email Threading (finally fixed)
Message-ID: <CALuQ0m8HKMwfKymK6BzKFRTbsWro-+rWVC1pzfiFvzg69q=MiA@mail.gmail.com>

Hi all,

If anyone received emails from gitlab you may have noticed that the
comments to issues ended up in different threads to the original issue
description.

This was because of a custom patch on our gitlab instance which I
think I have now fixed.

For example issue #20192 now has the correct threading, the original
issue and comment now appear in the same email thread (at least in my
client).

Cheers,

Matt

From carter.schonwald at gmail.com  Mon Aug  2 12:46:00 2021
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 2 Aug 2021 08:46:00 -0400
Subject: Email Threading (finally fixed)
In-Reply-To: <CALuQ0m8HKMwfKymK6BzKFRTbsWro-+rWVC1pzfiFvzg69q=MiA@mail.gmail.com>
References: <CALuQ0m8HKMwfKymK6BzKFRTbsWro-+rWVC1pzfiFvzg69q=MiA@mail.gmail.com>
Message-ID: <CAHYVw0xX8=LZFu1WaENMyY1MndQAu=-kQXs39fUqw3pKcj_pKQ@mail.gmail.com>

I was wondering about that!  Awesome
On Mon, Aug 2, 2021 at 6:01 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Hi all,
>
> If anyone received emails from gitlab you may have noticed that the
> comments to issues ended up in different threads to the original issue
> description.
>
> This was because of a custom patch on our gitlab instance which I
> think I have now fixed.
>
> For example issue #20192 now has the correct threading, the original
> issue and comment now appear in the same email thread (at least in my
> client).
>
> Cheers,
>
> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210802/1864450e/attachment.html>

From xnningxie at gmail.com  Fri Aug  6 04:06:37 2021
From: xnningxie at gmail.com (Ningning Xie)
Date: Fri, 6 Aug 2021 00:06:37 -0400
Subject: Call for Lightning Talks: Haskell Implementors' Workshop @ ICFP'21
Message-ID: <CABjRk3nNuVXE5=GBazf4cuQHe9AYuZbc2rBq0qv+kVQt8+2xrA@mail.gmail.com>

                        Call for Lightning Talks
               ACM SIGPLAN Haskell Implementors' Workshop

                https://icfp21.sigplan.org/home/hiw-2021
                         Virtual, 22 Aug, 2021

                      Co-located with ICFP 2021
                     https://icfp21.sigplan.org/

Important dates
---------------

Deadline:       Thursday, 19 Aug, 2021
                (or when slots are full, whichever is sooner)
Workshop:       Sunday, 22 Aug, 2021

The 13th Haskell Implementors' Workshop is to be held alongside ICFP
2021 this year virtually. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure, to share their work and discuss future
directions and collaborations with others.

We will have a number of slots for lightning talks. Lightning talks
will be ~7 minutes and are scheduled on the day of the workshop.
Suggested topics for lightning talks are to present a single idea, a
work-in-progress project, a problem to intrigue and perplex Haskell
implementors, or simply to ask for feedback and collaborators.

Lightning talks are proposed by submitting a title and an abstract.
Submissions will not be part of the peer-review process. Notification
of acceptance will be continuous until slots are full.

Submissions should be made via Google form:
https://forms.gle/BmUSyWWTXt1AMTec8

Accepted lightning talks will be posted on the workshop’s website.

Scope and target audience
-------------------------

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are specially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

  * Compilation techniques
  * Language features and extensions
  * Type system implementation
  * Concurrency and parallelism: language design and implementation
  * Performance, optimisation and benchmarking
  * Virtual machines and run-time systems
  * Libraries and tools for development or deployment


Logistics
---------

Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW)
will be held remotely this year. However, the organizers are still
working hard to provide for a great workshop experience.

While we are sad that this year will lack the robust hallway track that
is often the highlight of HIW, we believe that this remote workshop
presents a unique opportunity to include more of the Haskell community
in our discussion and explore new modes of communicating with our
colleagues. We hope that you will join us in making this HIW as
vibrant as any other.

Contact
-------

  * Ningning Xie <xnningxie at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210806/8b766155/attachment.html>

From guandayuan0715 at gmail.com  Fri Aug  6 18:43:51 2021
From: guandayuan0715 at gmail.com (Guanda Yuan)
Date: Fri, 6 Aug 2021 13:43:51 -0500
Subject: How to Collect Type Errors?
In-Reply-To: <CALuQ0m8sh5KJMoJQbpAmkYGr04QxE5VaG-vqS7n2YG2vCmymJw@mail.gmail.com>
References: <CALCz0oZ6y0uvmHgqyy+BzBAiZZ2OxDadx-jYCia5uEibL=Gh6w@mail.gmail.com>
 <CALuQ0m8sh5KJMoJQbpAmkYGr04QxE5VaG-vqS7n2YG2vCmymJw@mail.gmail.com>
Message-ID: <CALCz0oaOSZz2yeaqZtQsQkPh_xStN7q7ugsdKA1pUHpiXBGhZA@mail.gmail.com>

Hello Matthew,

During the time I have already figured the problem out. My original thought
is to log the errors from code to some file. Later I did find a function
being able to collect the diagnostics.

On the other hand, I'm new to the mailing list, and after I asked
the question I have further understood what the list is for. I think that
my question should be not suitable for the list, and sorry for that.

Guanda

Matthew Pickering <matthewtpickering at gmail.com> 于2021年8月2日周一 上午4:04写道：

> Hi Gunda,
>
> Could you be a bit more precise about what you want to achieve? HLS
> already displays type errors in your program, perhaps it would be
> better to ask someone on the HLS issue tracker how to use their API to
> do what you want.
>
> Matt
>
> On Fri, Jul 30, 2021 at 7:03 PM Guanda Yuan <guandayuan0715 at gmail.com>
> wrote:
> >
> > Hello all,
> >
> > I want to write a plugin for Haskell Language Server, to collect type
> errors in the code. I'm new to GHC API, so I need some help. My current
> thought is, I can collect diagnostics or the error messages and extract the
> type error infos. I have tried to referred to the Haddock documentation for
> GHC API, but I'm still not sure which function should I use.
> >
> > Thanks,
> > Guanda
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210806/34052f33/attachment.html>

From arifordsham at gmail.com  Sun Aug  8 15:34:00 2021
From: arifordsham at gmail.com (Ari Fordsham)
Date: Sun, 8 Aug 2021 16:34:00 +0100
Subject: Fwd: GHC Module change database
In-Reply-To: <CAPQL5p+aS7Mka98_2eDg0qnucKp1UYSqGkuW01eD1=xKt_6hBQ@mail.gmail.com>
References: <CAPQL5p+aS7Mka98_2eDg0qnucKp1UYSqGkuW01eD1=xKt_6hBQ@mail.gmail.com>
Message-ID: <CAPQL5pKHbhT_B0kh-Sw7unqXyDnL8N=UHYa5Mv5_fGDUh_NrZw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210808/47ac175c/attachment.html>

From vaibhavsagar at gmail.com  Sun Aug  8 15:36:17 2021
From: vaibhavsagar at gmail.com (Vaibhav Sagar)
Date: Mon, 9 Aug 2021 01:36:17 +1000
Subject: GHC Module change database
In-Reply-To: <CAPQL5pKHbhT_B0kh-Sw7unqXyDnL8N=UHYa5Mv5_fGDUh_NrZw@mail.gmail.com>
References: <CAPQL5p+aS7Mka98_2eDg0qnucKp1UYSqGkuW01eD1=xKt_6hBQ@mail.gmail.com>
 <CAPQL5pKHbhT_B0kh-Sw7unqXyDnL8N=UHYa5Mv5_fGDUh_NrZw@mail.gmail.com>
Message-ID: <CACK-K+2MgzC5on+oNbv58mMgWq+a1D4GuajEzCLuSiVU8VpXjg@mail.gmail.com>

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210809/5ea9d19e/attachment.html>

From arifordsham at gmail.com  Sun Aug  8 15:46:09 2021
From: arifordsham at gmail.com (Ari Fordsham)
Date: Sun, 8 Aug 2021 16:46:09 +0100
Subject: Fwd: GHC Module change database
In-Reply-To: <CAPQL5pJyK3JbPNDgk8pof=038S1LHU4vTGN8dacpLOVd-3PE2w@mail.gmail.com>
References: <CAPQL5p+aS7Mka98_2eDg0qnucKp1UYSqGkuW01eD1=xKt_6hBQ@mail.gmail.com>
 <CAPQL5pKHbhT_B0kh-Sw7unqXyDnL8N=UHYa5Mv5_fGDUh_NrZw@mail.gmail.com>
 <CACK-K+2MgzC5on+oNbv58mMgWq+a1D4GuajEzCLuSiVU8VpXjg@mail.gmail.com>
 <CAPQL5pJyK3JbPNDgk8pof=038S1LHU4vTGN8dacpLOVd-3PE2w@mail.gmail.com>
Message-ID: <CAPQL5pKz9dDZTg8g9PSmwU9M1xmWpeCwVGtgL1o9wA5+tzj25Q@mail.gmail.com>

AF


---------- Forwarded message ---------
From: Ari Fordsham <arifordsham at gmail.com>
Date: Sun, 8 Aug 2021 at 16:43
Subject: Re: GHC Module change database
To: Vaibhav Sagar <vaibhavsagar at 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 at 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 at 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210808/34402d35/attachment.html>

From sylvain at haskus.fr  Mon Aug  9 07:43:55 2021
From: sylvain at haskus.fr (Sylvain Henry)
Date: Mon, 9 Aug 2021 09:43:55 +0200
Subject: Fwd: GHC Module change database
In-Reply-To: <CAPQL5pKz9dDZTg8g9PSmwU9M1xmWpeCwVGtgL1o9wA5+tzj25Q@mail.gmail.com>
References: <CAPQL5p+aS7Mka98_2eDg0qnucKp1UYSqGkuW01eD1=xKt_6hBQ@mail.gmail.com>
 <CAPQL5pKHbhT_B0kh-Sw7unqXyDnL8N=UHYa5Mv5_fGDUh_NrZw@mail.gmail.com>
 <CACK-K+2MgzC5on+oNbv58mMgWq+a1D4GuajEzCLuSiVU8VpXjg@mail.gmail.com>
 <CAPQL5pJyK3JbPNDgk8pof=038S1LHU4vTGN8dacpLOVd-3PE2w@mail.gmail.com>
 <CAPQL5pKz9dDZTg8g9PSmwU9M1xmWpeCwVGtgL1o9wA5+tzj25Q@mail.gmail.com>
Message-ID: <9afcdd86-b26f-2be8-8a85-6b67753d0106@haskus.fr>

 > Having a 'single source of truth' database will help with this.

Don't hesitate to make a PR to 
https://gitlab.haskell.org/haskell/ghc-api-compat so that at least the 
DB and the .cabal files live in the same repo.

I have created this package but I don't use it so anyone should really 
feel free to take it over.

Sylvain


On 08/08/2021 17:46, Ari Fordsham wrote:
>
>
> AF
>
>
> ---------- Forwarded message ---------
> From: *Ari Fordsham* <arifordsham at gmail.com 
> <mailto:arifordsham at gmail.com>>
> Date: Sun, 8 Aug 2021 at 16:43
> Subject: Re: GHC Module change database
> To: Vaibhav Sagar <vaibhavsagar at gmail.com <mailto:vaibhavsagar at 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 
> <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 at gmail.com 
> <mailto:vaibhavsagar at gmail.com>> wrote:
>
>     Hi Ari,
>
>     Have you seen https://gitlab.haskell.org/haskell/ghc-api-compat
>     <https://gitlab.haskell.org/haskell/ghc-api-compat>?
>
>     Thanks,
>     Vaibhav
>
>     On Mon, Aug 9, 2021 at 1:34 AM Ari Fordsham <arifordsham at gmail.com
>     <mailto:arifordsham at gmail.com>> wrote:
>
>         I've made a database of GHC API module changes.
>
>         https://github.com/AriFordsham/ghc-module-renames
>         <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 at haskell.org <mailto:ghc-devs at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210809/edaef0e2/attachment.html>

From zubin at well-typed.com  Sat Aug 14 13:10:06 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sat, 14 Aug 2021 18:40:06 +0530
Subject: [Haskell] [ANNOUNCE] GHC 8.10.6 released
Message-ID: <20210814131006.ttd55aaxh6etlq43@zubin-msi>

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.6-notes.html).

As always, feel free to report any issues you encounter via
[gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210814/26772696/attachment.sig>

From b at chreekat.net  Sat Aug 14 15:23:36 2021
From: b at chreekat.net (Bryan Richter)
Date: Sat, 14 Aug 2021 18:23:36 +0300
Subject: Fwd: Unlock instructions
In-Reply-To: <6117c82c5b145_ecfbb459c0102156d@gitlab.mail>
References: <6117c82c5b145_ecfbb459c0102156d@gitlab.mail>
Message-ID: <CAH9BU=zCmWvvpQKrprd+Fyh88FMFS0kZYt00WjJOf2hy7tjeCA@mail.gmail.com>

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 at gitlab.haskell.org>
Date: Sat, 14 Aug 2021, 16.42
Subject: Unlock instructions
To: <b at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210814/24151771/attachment.html>

From jakob.bruenker at gmail.com  Sun Aug 15 02:26:36 2021
From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=)
Date: Sun, 15 Aug 2021 04:26:36 +0200
Subject: Unlock instructions
In-Reply-To: <CAH9BU=zCmWvvpQKrprd+Fyh88FMFS0kZYt00WjJOf2hy7tjeCA@mail.gmail.com>
References: <6117c82c5b145_ecfbb459c0102156d@gitlab.mail>
 <CAH9BU=zCmWvvpQKrprd+Fyh88FMFS0kZYt00WjJOf2hy7tjeCA@mail.gmail.com>
Message-ID: <CAJjQ6oMdz8Sh2xzMoghySjGM4o4DkqpGcOUGXeua01MVPCszmw@mail.gmail.com>

Hi,

for what it's worth, I just now got the same Email, so it's not just you.

Jakob

On Sat, Aug 14, 2021 at 5:26 PM Bryan Richter <b at chreekat.net> wrote:

> 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 at gitlab.haskell.org>
> Date: Sat, 14 Aug 2021, 16.42
> Subject: Unlock instructions
> To: <b at 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>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210815/d62336fa/attachment.html>

From ben at well-typed.com  Mon Aug 16 14:14:31 2021
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 Aug 2021 10:14:31 -0400
Subject: Fwd: Unlock instructions
In-Reply-To: <CAH9BU=zCmWvvpQKrprd+Fyh88FMFS0kZYt00WjJOf2hy7tjeCA@mail.gmail.com>
References: <6117c82c5b145_ecfbb459c0102156d@gitlab.mail>
 <CAH9BU=zCmWvvpQKrprd+Fyh88FMFS0kZYt00WjJOf2hy7tjeCA@mail.gmail.com>
Message-ID: <87o89xpjd8.fsf@smart-cactus.org>

Bryan Richter <b at chreekat.net> writes:

> Hey all,
>
Hi Bryan,

Indeed it seems someone attempted to brute-force a few accounts but I have
no reason to believe that they succeeded. Thanks for letting me know!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210816/e31be42a/attachment.sig>

From iavor.diatchki at gmail.com  Tue Aug 17 07:22:47 2021
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 17 Aug 2021 10:22:47 +0300
Subject: Fwd: Unlock instructions
In-Reply-To: <87o89xpjd8.fsf@smart-cactus.org>
References: <6117c82c5b145_ecfbb459c0102156d@gitlab.mail>
 <CAH9BU=zCmWvvpQKrprd+Fyh88FMFS0kZYt00WjJOf2hy7tjeCA@mail.gmail.com>
 <87o89xpjd8.fsf@smart-cactus.org>
Message-ID: <CAGK9nuqM0UEz4hWmLLrLU1V+nPHheL7WeauDtW3pKkNxb-514w@mail.gmail.com>

Yeah, I got one of these too, definitely worth keeping an eye on what's
happening.

Iavor

On Mon, Aug 16, 2021, 17:16 Ben Gamari <ben at well-typed.com> wrote:

> Bryan Richter <b at chreekat.net> writes:
>
> > Hey all,
> >
> Hi Bryan,
>
> Indeed it seems someone attempted to brute-force a few accounts but I have
> no reason to believe that they succeeded. Thanks for letting me know!
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210817/89825ebc/attachment.html>

From lazyswamp at gmail.com  Wed Aug 18 14:20:54 2021
From: lazyswamp at gmail.com (Kwanghoon Choi)
Date: Wed, 18 Aug 2021 15:20:54 +0100
Subject: How to use Lexer.lexer to produce closing braces as well?
Message-ID: <CAN+A2EUVSn+U0=TQdQftkCdFaOgu78s1UG7KATLXNh8CPff-ow@mail.gmail.com>

Hi,

I have recently been playing with GHC's Lexer.lexer in the ghc-parser-lib
package.

Given

   module HelloWorld where

   main = putStrLn "Hello World!\n"

it produces

   stack exec -- lexer-exe ./examples/HelloWorld.hs
   Lexing&Parsing: ./examples/HelloWorld.hs
   module at (1, 1): module
   CONID at (1, 8): CONID
   where at (1, 19): where
   vocurly at (3, 1): vocurly    <==== { is inserted automatically!!
   VARID at (3, 1): VARID
   = at (3, 6): =
   VARID at (3, 8): VARID
   STRING at (3, 17): STRING
   ; at (4, 1): ;

By the example above, the lexer automatically inserts an opening brace
(i.e. vocurly) right after 'where'. But it does not insert a matching
closing brace (i.e., vccurly), which would lead to a failure in parsing a
list of tokens produced by the lexer.

My question is how to use the GHC lexer to produce closing braces as well.

All my code is available
 - https://github.com/kwanghoon/hslexer

To save your time, the relevant part of the code is as follows:

In app/HaskellLexer.hs,

    singleHaskellToken :: P (Located Token)
    singleHaskellToken =
      Lexer.lexer False
        (\locatedToken -> P (\pstate -> POk pstate locatedToken))

    tokInfos :: [Terminal Token] -> P (Line, Column, [Terminal Token])
    tokInfos s = do
      locatedToken <- singleHaskellToken
      case locatedToken of
        L srcspan ITeof ->
          let (start_line, start_col, end_line, end_col) = srcSpanToLineCol
srcspan in
          return (end_line, end_col, s)

        L srcspan tok ->
          let (start_line, start_col, end_line, end_col) = srcSpanToLineCol
srcspan in
          tokInfos (Terminal (fromToken tok) start_line start_col (Just
tok) : s)

Thanks in advance

Best regards,

Kwanghoon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210818/aa1e791a/attachment.html>

From ekmett at gmail.com  Wed Aug 18 16:05:18 2021
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 18 Aug 2021 09:05:18 -0700
Subject: How to use Lexer.lexer to produce closing braces as well?
In-Reply-To: <CAN+A2EUVSn+U0=TQdQftkCdFaOgu78s1UG7KATLXNh8CPff-ow@mail.gmail.com>
References: <CAN+A2EUVSn+U0=TQdQftkCdFaOgu78s1UG7KATLXNh8CPff-ow@mail.gmail.com>
Message-ID: <CAJumaK_Sb=ucmpzKNLXeL6X_Dnr1nQoa33X+A8z2d3rF09bdcw@mail.gmail.com>

Unfortunately, the current parsing rules for Haskell aren't fully
phase-separable like this.

If you look at the rules for Layout token insertion in the Haskell report
the 9th rule requires that in the event the parser encounters a parse
error it should insert a virtual close brace and continue on!

Otherwise you couldn't parse things like *let **{** foo = bar **}** in
baz *where
the {}'s are virtual without reframing *let* and *in* as a different kind
of paired opening and closing brace or using other hacks in the grammar. It
is quite difficult to hack around all the ways parses can go wrong.

The main downside this has from a language standpoint is you simply can't
properly lex Haskell without more or less fully parsing Haskell.

-Edward

On Wed, Aug 18, 2021 at 7:22 AM Kwanghoon Choi <lazyswamp at gmail.com> wrote:

>
> Hi,
>
> I have recently been playing with GHC's Lexer.lexer in the ghc-parser-lib
> package.
>
> Given
>
>    module HelloWorld where
>
>    main = putStrLn "Hello World!\n"
>
> it produces
>
>    stack exec -- lexer-exe ./examples/HelloWorld.hs
>    Lexing&Parsing: ./examples/HelloWorld.hs
>    module at (1, 1): module
>    CONID at (1, 8): CONID
>    where at (1, 19): where
>    vocurly at (3, 1): vocurly    <==== { is inserted automatically!!
>    VARID at (3, 1): VARID
>    = at (3, 6): =
>    VARID at (3, 8): VARID
>    STRING at (3, 17): STRING
>    ; at (4, 1): ;
>
> By the example above, the lexer automatically inserts an opening brace
> (i.e. vocurly) right after 'where'. But it does not insert a matching
> closing brace (i.e., vccurly), which would lead to a failure in parsing a
> list of tokens produced by the lexer.
>
> My question is how to use the GHC lexer to produce closing braces as well.
>
> All my code is available
>  - https://github.com/kwanghoon/hslexer
>
> To save your time, the relevant part of the code is as follows:
>
> In app/HaskellLexer.hs,
>
>     singleHaskellToken :: P (Located Token)
>     singleHaskellToken =
>       Lexer.lexer False
>         (\locatedToken -> P (\pstate -> POk pstate locatedToken))
>
>     tokInfos :: [Terminal Token] -> P (Line, Column, [Terminal Token])
>     tokInfos s = do
>       locatedToken <- singleHaskellToken
>       case locatedToken of
>         L srcspan ITeof ->
>           let (start_line, start_col, end_line, end_col) =
> srcSpanToLineCol srcspan in
>           return (end_line, end_col, s)
>
>         L srcspan tok ->
>           let (start_line, start_col, end_line, end_col) =
> srcSpanToLineCol srcspan in
>           tokInfos (Terminal (fromToken tok) start_line start_col (Just
> tok) : s)
>
> Thanks in advance
>
> Best regards,
>
> Kwanghoon
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210818/1ca5a2c6/attachment.html>

From xnningxie at gmail.com  Fri Aug 20 21:57:39 2021
From: xnningxie at gmail.com (Ningning Xie)
Date: Fri, 20 Aug 2021 17:57:39 -0400
Subject: Call for Participation: Haskell Implementors' Workshop 2021
Message-ID: <CABjRk3kFgu3-4rPBODnBJg-1fgENO7uC_4CqZJEMmJikpZXi_w@mail.gmail.com>

                      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-large-scale-real-world-experience-with-the-Mu-compiler-in-Fin


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 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210820/b71c0485/attachment.html>

From zubin at well-typed.com  Sat Aug 21 09:50:24 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sat, 21 Aug 2021 15:20:24 +0530
Subject: The State of GHC 8.10
Message-ID: <20210821095024.aobr5jrtedls4om6@zubin-msi>

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210821/76e5a8d7/attachment.sig>

From ben at well-typed.com  Sun Aug 22 21:56:37 2021
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 22 Aug 2021 17:56:37 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
Message-ID: <87wnodm9dq.fsf@smart-cactus.org>


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-unlifted-datatypes.rst
[-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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210822/58af141e/attachment.sig>

From david.feuer at gmail.com  Sun Aug 22 22:10:20 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 22 Aug 2021 18:10:20 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <87wnodm9dq.fsf@smart-cactus.org>
References: <87wnodm9dq.fsf@smart-cactus.org>
Message-ID: <CAMgWh9sF4Ann5MO+mwahDbWW44yaddLrE_FVf0iV6_fBH0ioQw@mail.gmail.com>

Have array and reference types and primos been updated to be
BoxedRep-polymorphic, or is it still just expensive scaffolding?

On Sun, Aug 22, 2021, 6:01 PM Ben Gamari <ben at well-typed.com> wrote:

>
> 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-unlifted-datatypes.rst
> [-hi
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst%5B-hi>
> profiling]:
> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [ghc-debug
> <https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/%5Bghc-debug>]:
> http://ghc.gitlab.haskell.org/ghc-debug/
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210822/aa709a25/attachment.html>

From sam.derbyshire at gmail.com  Sun Aug 22 22:57:06 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Mon, 23 Aug 2021 00:57:06 +0200
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <CAMgWh9sF4Ann5MO+mwahDbWW44yaddLrE_FVf0iV6_fBH0ioQw@mail.gmail.com>
References: <87wnodm9dq.fsf@smart-cactus.org>
 <CAMgWh9sF4Ann5MO+mwahDbWW44yaddLrE_FVf0iV6_fBH0ioQw@mail.gmail.com>
Message-ID: <CAA1CnJPVU2Ojcc=0635tYZqESqmExT3bCJq27FW1d5FAKrk2QQ@mail.gmail.com>

> Have array and reference types and primos been updated to be
> BoxedRep-polymorphic, or is it still just expensive scaffolding?
>

Not at the moment. A few primops have been updated for GHC 9.4 (e.g.
pointer equality, keepAlive) , but nothing pertaining to arrays yet (MR
!5218 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5218>).

Cheers,

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210823/8c02a176/attachment.html>

From david.feuer at gmail.com  Mon Aug 23 00:14:01 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 22 Aug 2021 20:14:01 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <87wnodm9dq.fsf@smart-cactus.org>
References: <87wnodm9dq.fsf@smart-cactus.org>
Message-ID: <CAMgWh9utBYWXRmavvT2VXbM-F49Q6tLkHFZCbT+-4hV8wAM73A@mail.gmail.com>

One more question: is Solo exported from Data.Tuple yet, or do we still
have to depend on ghc-prim and import it from GHC.Magic? It would be really
nice to have that fixed by release, and it's so tiny.

On Sun, Aug 22, 2021, 6:01 PM Ben Gamari <ben at well-typed.com> wrote:

>
> 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-unlifted-datatypes.rst
> [-hi
> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst%5B-hi>
> profiling]:
> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [ghc-debug
> <https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/%5Bghc-debug>]:
> http://ghc.gitlab.haskell.org/ghc-debug/
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210822/85def702/attachment.html>

From david.feuer at gmail.com  Mon Aug 23 00:15:10 2021
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 22 Aug 2021 20:15:10 -0400
Subject: [ANNOUNCE] GHC 9.2.1-rc1 now available
In-Reply-To: <CAMgWh9utBYWXRmavvT2VXbM-F49Q6tLkHFZCbT+-4hV8wAM73A@mail.gmail.com>
References: <87wnodm9dq.fsf@smart-cactus.org>
 <CAMgWh9utBYWXRmavvT2VXbM-F49Q6tLkHFZCbT+-4hV8wAM73A@mail.gmail.com>
Message-ID: <CAMgWh9s4UDEh5-0=G5ha8jbegsGk7kix7gkNjUHObPWo9xcaCA@mail.gmail.com>

I mean GHC.Tuple, of course.

On Sun, Aug 22, 2021, 8:14 PM David Feuer <david.feuer at gmail.com> wrote:

> One more question: is Solo exported from Data.Tuple yet, or do we still
> have to depend on ghc-prim and import it from GHC.Magic? It would be really
> nice to have that fixed by release, and it's so tiny.
>
> On Sun, Aug 22, 2021, 6:01 PM Ben Gamari <ben at well-typed.com> wrote:
>
>>
>> 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-unlifted-datatypes.rst
>> [-hi
>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst%5B-hi>
>> profiling]:
>> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
>> [ghc-debug
>> <https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/%5Bghc-debug>]:
>> http://ghc.gitlab.haskell.org/ghc-debug/
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210822/201b8f76/attachment.html>

From sam.derbyshire at gmail.com  Mon Aug 23 09:41:15 2021
From: sam.derbyshire at gmail.com (Sam Derbyshire)
Date: Mon, 23 Aug 2021 11:41:15 +0200
Subject: [RFC] TcPlugin changes in GHC 9.4: what would you like to see?
Message-ID: <CAA1CnJPHCy1ULgSTdJH-GmvwDBFfAg1HWAndqcHfD4e4xxhAmQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210823/a0e42723/attachment.html>

From Gergo.Erdi at sc.com  Tue Aug 24 02:17:46 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Tue, 24 Aug 2021 02:17:46 +0000
Subject: Where (else) do I need to register instances from loaded modules?
Message-ID: <HK0PR03MB4867C68212D2BD6A87BEC566E9C59@HK0PR03MB4867.apcprd03.prod.outlook.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210824/1bb30519/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Class.src
Type: application/octet-stream
Size: 65 bytes
Desc: Class.src
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210824/1bb30519/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Instance.src
Type: application/octet-stream
Size: 73 bytes
Desc: Instance.src
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210824/1bb30519/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Use.src
Type: application/octet-stream
Size: 75 bytes
Desc: Use.src
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210824/1bb30519/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.hs
Type: application/octet-stream
Size: 10938 bytes
Desc: Main.hs
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210824/1bb30519/attachment-0003.obj>

From ietf-dane at dukhovni.org  Tue Aug 24 04:32:08 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 24 Aug 2021 00:32:08 -0400
Subject: primitive (byte) string literal with length?
Message-ID: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>


Is there any GHC syntax for constructing a primitive string literal with a known (not hand coded) byte count?
With `"some bytes"#` I get just the `Addr#` pointer, but not the size.

If there's nothing available, would it be reasonable to introduce a new syntax?
Perhaps:

	"some bytes"## :: (# Addr#, Int# #)

-- 
	Viktor.


From sylvain at haskus.fr  Tue Aug 24 06:48:53 2021
From: sylvain at haskus.fr (Sylvain Henry)
Date: Tue, 24 Aug 2021 08:48:53 +0200
Subject: primitive (byte) string literal with length?
In-Reply-To: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>
References: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>
Message-ID: <eb275c32-b310-474d-b5d6-1cffe9e303a2@haskus.fr>

Hi,

You can use cstringLength# which has a constant-folding rules for literals. That's what we use in GHC to build FastString literals.

⁣

Le 24 août 2021 à 06:34, à 06:34, Viktor Dukhovni <ietf-dane at dukhovni.org> a écrit:
>
>Is there any GHC syntax for constructing a primitive string literal
>with a known (not hand coded) byte count?
>With `"some bytes"#` I get just the `Addr#` pointer, but not the size.
>
>If there's nothing available, would it be reasonable to introduce a new
>syntax?
>Perhaps:
>
>	"some bytes"## :: (# Addr#, Int# #)
>
>-- 
>	Viktor.
>
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210824/75349e34/attachment.html>

From karel.gardas at centrum.cz  Tue Aug 24 07:50:06 2021
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Tue, 24 Aug 2021 09:50:06 +0200
Subject: git issues or repository issues?
Message-ID: <136bb129-b543-8816-f1d8-eff6a29fec26@centrum.cz>


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

From matthewtpickering at gmail.com  Tue Aug 24 09:16:20 2021
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 24 Aug 2021 10:16:20 +0100
Subject: Where (else) do I need to register instances from loaded modules?
In-Reply-To: <HK0PR03MB4867C68212D2BD6A87BEC566E9C59@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867C68212D2BD6A87BEC566E9C59@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <CALuQ0m-wA6Jd9Gx8by=U-oEEbpBdO7dfmUt8ba_DfiqrsztSjw@mail.gmail.com>

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

On Tue, Aug 24, 2021 at 3:20 AM Erdi, Gergo via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> 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.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ietf-dane at dukhovni.org  Tue Aug 24 13:03:30 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Tue, 24 Aug 2021 09:03:30 -0400
Subject: primitive (byte) string literal with length?
In-Reply-To: <eb275c32-b310-474d-b5d6-1cffe9e303a2@haskus.fr>
References: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>
 <eb275c32-b310-474d-b5d6-1cffe9e303a2@haskus.fr>
Message-ID: <YSTuIn+7xtbt/O7Z@straasha.imrryr.org>

On Tue, Aug 24, 2021 at 08:48:53AM +0200, Sylvain Henry wrote:

> Le 24 août 2021 à 06:34, à 06:34, Viktor Dukhovni <ietf-dane at dukhovni.org> a écrit:
> >
> >Is there any GHC syntax for constructing a primitive string literal
> >with a known (not hand coded) byte count?
> >With `"some bytes"#` I get just the `Addr#` pointer, but not the size.
> >
> >If there's nothing available, would it be reasonable to introduce a new
> >syntax?
> >Perhaps:
> >
> >	"some bytes"## :: (# Addr#, Int# #)
>
> You can use cstringLength# which has a constant-folding rules for
> literals. That's what we use in GHC to build FastString literals.

Sadly, that does not work when the primitive octet string contains
internal NUL bytes.

    λ> :set -package ghc-prim
    λ> :set -XMagicHash
    λ> import GHC.CString
    λ> import GHC.Int
    λ>
    λ> I# (cstringLength# "foobar\xa0"#)
    7
    λ> I# (cstringLength# "foo\0bar\xa0"#)
    3

-- 
	Viktor.

From Gergo.Erdi at sc.com  Wed Aug 25 02:36:57 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Wed, 25 Aug 2021 02:36:57 +0000
Subject: Where (else) do I need to register instances from loaded modules?
Message-ID: <HK0PR03MB4867037E149A796BEA32E098E9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>

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 at gmail.com> 
Sent: Tuesday, August 24, 2021 5:16 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: GHC <ghc-devs at haskell.org>; gergo at erdi.hu; Montelatici, Raphael Laurent <Raphael.Montelatici at 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.

From Gergo.Erdi at sc.com  Wed Aug 25 03:00:25 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Wed, 25 Aug 2021 03:00:25 +0000
Subject: Where (else) do I need to register instances from loaded modules?
In-Reply-To: <HK0PR03MB4867037E149A796BEA32E098E9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <HK0PR03MB4867037E149A796BEA32E098E9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <HK0PR03MB48679E4C4E564AB41ECA142FE9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>

INTERNAL

Oops, forgot to attach the updated program

-----Original Message-----
From: Erdi, Gergo 
Sent: Wednesday, August 25, 2021 10:37 AM
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: GHC <ghc-devs at haskell.org>; gergo at erdi.hu; Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>
Subject: Re: Where (else) do I need to register instances from loaded modules?

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 at gmail.com> 
Sent: Tuesday, August 24, 2021 5:16 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: GHC <ghc-devs at haskell.org>; gergo at erdi.hu; Montelatici, Raphael Laurent <Raphael.Montelatici at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.hs
Type: application/octet-stream
Size: 11762 bytes
Desc: Main.hs
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210825/96633499/attachment.obj>

From ietf-dane at dukhovni.org  Wed Aug 25 15:31:40 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 25 Aug 2021 11:31:40 -0400
Subject: primitive (byte) string literal with length?
In-Reply-To: <YSTuIn+7xtbt/O7Z@straasha.imrryr.org>
References: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>
 <eb275c32-b310-474d-b5d6-1cffe9e303a2@haskus.fr>
 <YSTuIn+7xtbt/O7Z@straasha.imrryr.org>
Message-ID: <YSZiXCirRTWriP77@straasha.imrryr.org>

On Tue, Aug 24, 2021 at 09:03:30AM -0400, Viktor Dukhovni wrote:

I originally wrote:

> > >Is there any GHC syntax for constructing a primitive string literal
> > >with a known (not hand coded) byte count?
> > >With `"some bytes"#` I get just the `Addr#` pointer, but not the size.
> > >
> > >If there's nothing available, would it be reasonable to introduce a new
> > >syntax?
> > >Perhaps:
> > >
> > >	"some bytes"## :: (# Addr#, Int# #)

But neglected to mention that I knew about `cstringLength#`, but found
it wanting, because it does not support octet-strings with embedded NUL
characters:

> Sadly, that does not work when the primitive octet string contains
> internal NUL bytes.
> 
>     λ> :set -package ghc-prim
>     λ> :set -XMagicHash
>     λ> import GHC.CString
>     λ> import GHC.Int
>     λ>
>     λ> I# (cstringLength# "foobar\xa0"#)
>     7
>     λ> I# (cstringLength# "foo\0bar\xa0"#)
>     3

If there isn't some other extant work-around, any feedback on my
proposal of a new syntax for a primitive unboxed (address, length) pair:

    "some bytes"## :: (# Addr#, Int# #)

-- 
    Viktor.

From oleg.grenrus at iki.fi  Wed Aug 25 16:05:58 2021
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Wed, 25 Aug 2021 19:05:58 +0300
Subject: primitive (byte) string literal with length?
In-Reply-To: <YSZiXCirRTWriP77@straasha.imrryr.org>
References: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>
 <eb275c32-b310-474d-b5d6-1cffe9e303a2@haskus.fr>
 <YSTuIn+7xtbt/O7Z@straasha.imrryr.org> <YSZiXCirRTWriP77@straasha.imrryr.org>
Message-ID: <a60aa346-76f6-75ed-ca76-f70235190102@iki.fi>

There are bytearray literal proposals [1,2]. My older proposal [2] idea
that the literal prim literal strings could generate also ByteArray# and
(# Int#, Addr# #), but as it was proposing to change how literal Haskell
Strings are compiled the proposal got stalled. The newew proposal [1] is
tagged as "needs revision". It doesn't include(# Int#, Addr# #), but
those are easy to get from ByteArray# which has negligible overhead. I
haven't followed the discussion so I'm not sure what syntax it actually
proposes (description and proposal text differ) and what are the needed
revisions.

I'm cc-ing Andew, he knows better :)

- Oleg

[1] https://github.com/ghc-proposals/ghc-proposals/pull/292
[2] https://github.com/ghc-proposals/ghc-proposals/pull/135

On 25.8.2021 18.31, Viktor Dukhovni wrote:
> On Tue, Aug 24, 2021 at 09:03:30AM -0400, Viktor Dukhovni wrote:
>
> I originally wrote:
>
>>>> Is there any GHC syntax for constructing a primitive string literal
>>>> with a known (not hand coded) byte count?
>>>> With `"some bytes"#` I get just the `Addr#` pointer, but not the size.
>>>>
>>>> If there's nothing available, would it be reasonable to introduce a new
>>>> syntax?
>>>> Perhaps:
>>>>
>>>> 	"some bytes"## :: (# Addr#, Int# #)
> But neglected to mention that I knew about `cstringLength#`, but found
> it wanting, because it does not support octet-strings with embedded NUL
> characters:
>
>> Sadly, that does not work when the primitive octet string contains
>> internal NUL bytes.
>>
>>     λ> :set -package ghc-prim
>>     λ> :set -XMagicHash
>>     λ> import GHC.CString
>>     λ> import GHC.Int
>>     λ>
>>     λ> I# (cstringLength# "foobar\xa0"#)
>>     7
>>     λ> I# (cstringLength# "foo\0bar\xa0"#)
>>     3
> If there isn't some other extant work-around, any feedback on my
> proposal of a new syntax for a primitive unboxed (address, length) pair:
>
>     "some bytes"## :: (# Addr#, Int# #)
>

From ietf-dane at dukhovni.org  Wed Aug 25 17:35:11 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Wed, 25 Aug 2021 13:35:11 -0400
Subject: primitive (byte) string literal with length?
In-Reply-To: <a60aa346-76f6-75ed-ca76-f70235190102@iki.fi>
References: <C177DB63-C63D-4866-ACF4-4EF619F8A88A@dukhovni.org>
 <eb275c32-b310-474d-b5d6-1cffe9e303a2@haskus.fr>
 <YSTuIn+7xtbt/O7Z@straasha.imrryr.org>
 <YSZiXCirRTWriP77@straasha.imrryr.org>
 <a60aa346-76f6-75ed-ca76-f70235190102@iki.fi>
Message-ID: <YSZ/TyMd3TdvQOim@straasha.imrryr.org>

On Wed, Aug 25, 2021 at 07:05:58PM +0300, Oleg Grenrus wrote:

> The newew proposal [1] is tagged as "needs revision". It doesn't
> include(# Int#, Addr# #), but those are easy to get from ByteArray#
> which has negligible overhead.
> [...]
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/292

Yes, ByteArray# literals would work just as well for my needs.

The one thing that's missing, from the proposed variants:

    Rather than adding new syntax, this proposal leverages an existing
    GHC extension: QuasiQuotes. Rather than using TemplateHaskell, these
    quasiquoters would be built in to the compiler. Here are some
    examples of ByteArray# literals under this scheme:

    [octets|fe01bce8|] -- ByteArray# (four bytes)
    [utf8|Araña|]      -- ByteArray# (UTF-8)
    [utf16|Araña|]     -- ByteArray# (UTF-16, native endian)
    [utf16le|Araña|]   -- ByteArray# (UTF-16, little endian)
    [utf16be|Araña|]   -- ByteArray# (UTF-16, big endian)

is a syntax for octet-strings that does not force hex encoding of every
byte, thus something along the lines of:

    [octetstr|foo%A0bar|] -- ByteArray# (seven bytes)

The "%hh" hex octet could be "\hh" or "\xhh", ... whatever is deemed
sufficiently natural/readable (perhaps "foo\xA0\&bar" for consistency
with Haskell strings?).  The "\xhh" form would be familiar to Python
users:

    >>> x = b'foo\xA0bar'
    >>> len(x)
    7
    >>> x[3]
    160

So, I support the proposal, even though quasi-quoters are more bulky
than "somebytes"##, they have the advantage of supporting multiple
variant formats.  I might be tempted to use "octets" for the non-hex
form with "%" or other escapes, and "hexstr" (or similar) for the hex
form.

-- 
    Viktor.

From liuyiyun at terpmail.umd.edu  Wed Aug 25 20:16:01 2021
From: liuyiyun at terpmail.umd.edu (Yiyun Liu)
Date: Wed, 25 Aug 2021 16:16:01 -0400
Subject: How to set idScope properly when converting LhsExpr GhcPs to CoreExpr?
Message-ID: <d022261b-cb2b-2ca2-cee2-27fa6b237d97@terpmail.umd.edu>

Hi all,

We have a function in Liquidhaskell's code base for converting
refinement expressions into GHC's core expressions using the GHC API.
Its implementation is based on tcRnExpr
<https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-8.10.6-release/compiler/typecheck/TcRnDriver.hs#L2358>except
we keep the typechecked expression and desugar it before returning.

However, our function fails to set the idScope information properly when
LiquidHaskell is invoked as a plugin (installed as a
typeCheckResultAction). This repo
<https://github.com/yiyunliu/ghc-elaboration-test>contains a minimal
example that demonstrates the issue. In the CoreExpr returned by
elabRnExpr
<https://github.com/yiyunliu/ghc-elaboration-test/blob/cb7397884b7949e6b7fb6617ded10e86ee5dcad2/src/Test/Plugin.hs#L71>,
every symbol from the current module that's being compiled is labeled as
local. The README.md file shows how the exported symbol testPlus is
marked as local in QQQ.hs, the module where it's defined.

Is there a function we should call to set the idScope information properly?

Thanks,

-Yiyun


From zubin at well-typed.com  Thu Aug 26 22:13:15 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Fri, 27 Aug 2021 03:43:15 +0530
Subject: [Haskell] [ANNOUNCE] GHC 8.10.7 released
Message-ID: <20210826221315.tumzvm3q2p24qa4x@zubin-msi>

The GHC team is very pleased to announce the availability of GHC
8.10.7. Source and binary distributions are available at the [usual
place](https://downloads.haskell.org/ghc/8.10.7/).

Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html
Blog Post: https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html

This is a small bugfix release, fixing one linking portability
issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64
macOS toolchains, which resulted in undefined symbol errors for
`___darwin_check_fd_set_overflow`.

Issue #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).

We claimed to have fixed this in GHC 8.10.6, but alas this wasn't the
case. The fix was originally tested on the master branch, which uses a
different build configuration from the 8.10 branch. We have now tested
the fix on the GHC 8.10 branch and finally squashed the bug.

We would like to thank 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. We
would also like to thank the hundreds of open-source contributors whose
work makes GHC possible.

A complete list of bug fixes and
improvements can be found in the [release
notes](https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8.
10.7-notes.html).

As always, feel free to report any issues you encounter via
[gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210827/86531f16/attachment.sig>

From Gergo.Erdi at sc.com  Fri Aug 27 06:41:52 2021
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Fri, 27 Aug 2021 06:41:52 +0000
Subject: Registering orphan instances and filling the `deps` field of ModIface
 [RE: Where (else) do I need to register instances from loaded
 modules?]
Message-ID: <HK0PR03MB48676561551C79928303C310E9C89@HK0PR03MB4867.apcprd03.prod.outlook.com>

PUBLIC

Re: #1., I've simplified the code by removing all the Unit shuffling: everything is now in mainUnit. Unfortunately, this doesn't change anything other than cutting a cool 100 lines from the MWE code; I'm attaching the new smaller & simpler version. It is based on GHC 9.0.1 with an extra patch to export the first half of mkIfaceTc, just before calling mkFullIface. With this change, it really should be filling everything in ModIface the same way as the real GHC (so e.g. `deps` should be properly filled), modulo the fingerprints. 

Unfortunately, the `deps` field of the `ModIface`s created this way still doesn't contain any orphan instance modules: `Class.src`'s deps are empty (which is what I'd expect), `Instance.src` has a dependency in dep_mods (but not in dep_orphs) on `Class {-# SORUCE #-}` (I'm not sure why it's marked as a source import when `Class` module was already loaded into the module providers map before typechecking `Instance`...), and of course `Use.src` still fails so I can't get to its dependencies.

It is confusing to me that the problem should be because of the dep_orphs, because `Instance.src` does NOT use any orphan instances from `Class.src; merely, it provides a new orphan instance for other modules to depend on. Can someone explain this part to me?

Thanks,
	Gergo

-----Original Message-----
From: Erdi, Gergo 
Sent: Wednesday, August 25, 2021 10:37 AM
To: Matthew Pickering <matthewtpickering at gmail.com>
Cc: GHC <ghc-devs at haskell.org>; gergo at erdi.hu; Montelatici, Raphael Laurent <Raphael.Montelatici at sc.com>
Subject: Re: Where (else) do I need to register instances from loaded modules?

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 at gmail.com> 
Sent: Tuesday, August 24, 2021 5:16 PM
To: Erdi, Gergo <Gergo.Erdi at sc.com>
Cc: GHC <ghc-devs at haskell.org>; gergo at erdi.hu; Montelatici, Raphael Laurent <Raphael.Montelatici at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.hs
Type: application/octet-stream
Size: 8094 bytes
Desc: Main.hs
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210827/baf2e413/attachment.obj>

From alexis.praga at gmail.com  Fri Aug 27 17:15:26 2021
From: alexis.praga at gmail.com (Alexis Praga)
Date: Fri, 27 Aug 2021 19:15:26 +0200
Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
Message-ID: <CAH3o9gzh99J8SWPebkKsykEf+UD59S7-bSZi9OPQY1WxC_tE=w@mail.gmail.com>

Hi,

As a complete beginner in regards to GHC, I tried to build GHC 9.2 as it
looked like the latest stable from git.I failed to build 9.0.1 before that.

After checking out the ghc-9.2 branch, I ran (following the wiki):

> ./boot
> set LOCALBASE=/usr/local
> ./configure --with-gmp-includes=$LOCALBASE/include
--with-gmp-libraries=$LOCALBASE/lib --disable-large-address-space
> hadrian/build -j

This failed with :

> | Configure package 'rts'
> | Configure package 'haddock'
> | Configure package 'ghc-bin'
> # cabal-configure (for _build/stage0/utils/haddock/setup-config)
> # cabal-configure (for _build/stage0/ghc/setup-config)
> hadrian: Encountered missing or private dependencies:
> ghc ==9.3.*
>
> Error when running Shake build system:
>   at action, called at src/Rules.hs:40:19 in main:Rules
>   at need, called at src/Rules.hs:62:5 in main:Rules
> * Depends on: _build/stage0/bin/haddock
>   at apply1, called at
src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle
> * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package =
Package {pkgType = Program, pkgName = "haddock", pkgPath =
"utils/haddock"}, way = v}))
>   at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in
main:Hadrian.Oracles.Cabal.Rules
> * Depends on: _build/stage0/utils/haddock/setup-config
> * Raised the exception:
> ExitFailure 1

The config.log is attached.

Any tips on how to proceed would be appreciated, thanks !

-- 

   Alexis Praga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210827/19dc99ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log
Type: text/x-log
Size: 263230 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210827/19dc99ff/attachment-0001.bin>

From ietf-dane at dukhovni.org  Fri Aug 27 17:42:16 2021
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Fri, 27 Aug 2021 13:42:16 -0400
Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
In-Reply-To: <CAH3o9gzh99J8SWPebkKsykEf+UD59S7-bSZi9OPQY1WxC_tE=w@mail.gmail.com>
References: <CAH3o9gzh99J8SWPebkKsykEf+UD59S7-bSZi9OPQY1WxC_tE=w@mail.gmail.com>
Message-ID: <YSkj+ClaT8et1Mlx@straasha.imrryr.org>

On Fri, Aug 27, 2021 at 07:15:26PM +0200, Alexis Praga wrote:

> As a complete beginner in regards to GHC, I tried to build GHC 9.2 as it
> looked like the latest stable from git.I failed to build 9.0.1 before that.
> 
> After checking out the ghc-9.2 branch, I ran (following the wiki):
> 
> > ./boot
> > set LOCALBASE=/usr/local
> > ./configure --with-gmp-includes=$LOCALBASE/include --with-gmp-libraries=$LOCALBASE/lib --disable-large-address-space
> > hadrian/build -j
> 

The attached script works for me on FreeBSD 12.2.  Perhaps it'll
work for you as well (you many to tweek some of the configured
paths).

-- 
    Viktor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.sh
Type: application/x-sh
Size: 989 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210827/b97c8b4b/attachment.sh>

From jeff.young at tweag.io  Fri Aug 27 17:57:45 2021
From: jeff.young at tweag.io (Jeffrey Young)
Date: Fri, 27 Aug 2021 10:57:45 -0700
Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
In-Reply-To: <mailman.9649.1630084105.2543.ghc-devs@haskell.org>
References: <mailman.9649.1630084105.2543.ghc-devs@haskell.org>
Message-ID: <ae8a37d2-58b8-b3a4-f367-de78ac28d069@tweag.io>

Hi Alexis,

This line shows the error:

> | Configure package 'ghc-bin'
> # cabal-configure (for _build/stage0/utils/haddock/setup-config)
> # cabal-configure (for _build/stage0/ghc/setup-config)
> hadrian: Encountered missing or private dependencies:
> ghc ==9.3.*

A package had a constraint on the ghc api to only accept ghc == 9.3.*. 
Since you are trying to build ghc 9.2 this fails. The package in 
question is printed by hadrian in this bit of your log:


> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
> shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle

> * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package =

> Package {pkgType = Program, pkgName = "haddock", pkgPath =
> "utils/haddock"}, way = v}))

>    at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in

Notice the `pkgName` field in the `Package` record in the error that 
hadrian produced. It shows us that haddock was the cuplrit. Not sure 
why/how that cabal file got mixed up but I bet if you went to 
`${GHC_HOME}/utils/haddock/haddock.cabal` you'll find the constraint in 
question and should be able to switch it to `ghc==9.2.*` and rebuild 
according to the wiki.


Hope this helps,


Jeff


On 8/27/21 10:08 AM, ghc-devs-request at haskell.org wrote:
> Send ghc-devs mailing list submissions to
> 	ghc-devs at haskell.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> or, via email, send a message with subject or body 'help' to
> 	ghc-devs-request at haskell.org
>
> You can reach the person managing the list at
> 	ghc-devs-owner at haskell.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ghc-devs digest..."
>
>
> Today's Topics:
>
>     1. Failed to build latest stable GHC on FreeBSD with Hadrian
>        (Alexis Praga)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 Aug 2021 19:15:26 +0200
> From: Alexis Praga <alexis.praga at gmail.com>
> To: ghc-devs at haskell.org
> Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
> Message-ID:
> 	<CAH3o9gzh99J8SWPebkKsykEf+UD59S7-bSZi9OPQY1WxC_tE=w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> As a complete beginner in regards to GHC, I tried to build GHC 9.2 as it
> looked like the latest stable from git.I failed to build 9.0.1 before that.
>
> After checking out the ghc-9.2 branch, I ran (following the wiki):
>
>> ./boot
>> set LOCALBASE=/usr/local
>> ./configure --with-gmp-includes=$LOCALBASE/include
> --with-gmp-libraries=$LOCALBASE/lib --disable-large-address-space
>> hadrian/build -j
> This failed with :
>
>> | Configure package 'rts'
>> | Configure package 'haddock'
>> | Configure package 'ghc-bin'
>> # cabal-configure (for _build/stage0/utils/haddock/setup-config)
>> # cabal-configure (for _build/stage0/ghc/setup-config)
>> hadrian: Encountered missing or private dependencies:
>> ghc ==9.3.*
>>
>> Error when running Shake build system:
>>    at action, called at src/Rules.hs:40:19 in main:Rules
>>    at need, called at src/Rules.hs:62:5 in main:Rules
>> * Depends on: _build/stage0/bin/haddock
>>    at apply1, called at
> src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
> shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle
>> * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package =
> Package {pkgType = Program, pkgName = "haddock", pkgPath =
> "utils/haddock"}, way = v}))
>>    at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in
> main:Hadrian.Oracles.Cabal.Rules
>> * Depends on: _build/stage0/utils/haddock/setup-config
>> * Raised the exception:
>> ExitFailure 1
> The config.log is attached.
>
> Any tips on how to proceed would be appreciated, thanks !
>

From alexis.praga at gmail.com  Fri Aug 27 19:31:41 2021
From: alexis.praga at gmail.com (Alexis Praga)
Date: Fri, 27 Aug 2021 21:31:41 +0200
Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
In-Reply-To: <ae8a37d2-58b8-b3a4-f367-de78ac28d069@tweag.io>
References: <mailman.9649.1630084105.2543.ghc-devs@haskell.org>
 <ae8a37d2-58b8-b3a4-f367-de78ac28d069@tweag.io>
Message-ID: <CAH3o9gw4Y2k0CYy5eM=Jcc3fTGe6V8vD99QydhrTnGS+Lo-M0g@mail.gmail.com>

Thanks Viktor for the script.
Actually, building finished without issue after cleaning the whole
directory and starting from a fresh git clone. I used the same commands as
on my first message.

Sorry about that and thanks for taking the time to answer quickly !

On Fri, Aug 27, 2021 at 7:59 PM Jeffrey Young <jeff.young at tweag.io> wrote:

> Hi Alexis,
>
> This line shows the error:
>
> > | Configure package 'ghc-bin'
> > # cabal-configure (for _build/stage0/utils/haddock/setup-config)
> > # cabal-configure (for _build/stage0/ghc/setup-config)
> > hadrian: Encountered missing or private dependencies:
> > ghc ==9.3.*
>
> A package had a constraint on the ghc api to only accept ghc == 9.3.*.
> Since you are trying to build ghc 9.2 this fails. The package in
> question is printed by hadrian in this bit of your log:
>
>
> > src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
> >
> shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle
>
> > * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package =
>
> > Package {pkgType = Program, pkgName = "haddock", pkgPath =
> > "utils/haddock"}, way = v}))
>
> >    at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in
>
> Notice the `pkgName` field in the `Package` record in the error that
> hadrian produced. It shows us that haddock was the cuplrit. Not sure
> why/how that cabal file got mixed up but I bet if you went to
> `${GHC_HOME}/utils/haddock/haddock.cabal` you'll find the constraint in
> question and should be able to switch it to `ghc==9.2.*` and rebuild
> according to the wiki.
>
>
> Hope this helps,
>
>
> Jeff
>
>
> On 8/27/21 10:08 AM, ghc-devs-request at haskell.org wrote:
> > Send ghc-devs mailing list submissions to
> >       ghc-devs at haskell.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >       http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > or, via email, send a message with subject or body 'help' to
> >       ghc-devs-request at haskell.org
> >
> > You can reach the person managing the list at
> >       ghc-devs-owner at haskell.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of ghc-devs digest..."
> >
> >
> > Today's Topics:
> >
> >     1. Failed to build latest stable GHC on FreeBSD with Hadrian
> >        (Alexis Praga)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 27 Aug 2021 19:15:26 +0200
> > From: Alexis Praga <alexis.praga at gmail.com>
> > To: ghc-devs at haskell.org
> > Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
> > Message-ID:
> >       <CAH3o9gzh99J8SWPebkKsykEf+UD59S7-bSZi9OPQY1WxC_tE=
> w at mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > As a complete beginner in regards to GHC, I tried to build GHC 9.2 as it
> > looked like the latest stable from git.I failed to build 9.0.1 before
> that.
> >
> > After checking out the ghc-9.2 branch, I ran (following the wiki):
> >
> >> ./boot
> >> set LOCALBASE=/usr/local
> >> ./configure --with-gmp-includes=$LOCALBASE/include
> > --with-gmp-libraries=$LOCALBASE/lib --disable-large-address-space
> >> hadrian/build -j
> > This failed with :
> >
> >> | Configure package 'rts'
> >> | Configure package 'haddock'
> >> | Configure package 'ghc-bin'
> >> # cabal-configure (for _build/stage0/utils/haddock/setup-config)
> >> # cabal-configure (for _build/stage0/ghc/setup-config)
> >> hadrian: Encountered missing or private dependencies:
> >> ghc ==9.3.*
> >>
> >> Error when running Shake build system:
> >>    at action, called at src/Rules.hs:40:19 in main:Rules
> >>    at need, called at src/Rules.hs:62:5 in main:Rules
> >> * Depends on: _build/stage0/bin/haddock
> >>    at apply1, called at
> > src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
> >
> shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle
> >> * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package
> =
> > Package {pkgType = Program, pkgName = "haddock", pkgPath =
> > "utils/haddock"}, way = v}))
> >>    at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in
> > main:Hadrian.Oracles.Cabal.Rules
> >> * Depends on: _build/stage0/utils/haddock/setup-config
> >> * Raised the exception:
> >> ExitFailure 1
> > The config.log is attached.
> >
> > Any tips on how to proceed would be appreciated, thanks !
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 

   Alexis Praga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210827/f9ba90a8/attachment.html>

From zubin at well-typed.com  Sat Aug 28 06:44:37 2021
From: zubin at well-typed.com (Zubin Duggal)
Date: Sat, 28 Aug 2021 12:14:37 +0530
Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
In-Reply-To: <CAH3o9gw4Y2k0CYy5eM=Jcc3fTGe6V8vD99QydhrTnGS+Lo-M0g@mail.gmail.com>
References: <mailman.9649.1630084105.2543.ghc-devs@haskell.org>
 <ae8a37d2-58b8-b3a4-f367-de78ac28d069@tweag.io>
 <CAH3o9gw4Y2k0CYy5eM=Jcc3fTGe6V8vD99QydhrTnGS+Lo-M0g@mail.gmail.com>
Message-ID: <20210828064437.qxegolonypzy64m7@zubin-msi>

It sounds like you had an old checkout of the haddock submodules. You
can update all submodules to the correct checkout by running `git
submodule update`.

On 21/08/27 21:31, Alexis Praga wrote:
>Thanks Viktor for the script.
>Actually, building finished without issue after cleaning the whole
>directory and starting from a fresh git clone. I used the same commands as
>on my first message.
>
>Sorry about that and thanks for taking the time to answer quickly !
>
>On Fri, Aug 27, 2021 at 7:59 PM Jeffrey Young <jeff.young at tweag.io> wrote:
>
>> Hi Alexis,
>>
>> This line shows the error:
>>
>> > | Configure package 'ghc-bin'
>> > # cabal-configure (for _build/stage0/utils/haddock/setup-config)
>> > # cabal-configure (for _build/stage0/ghc/setup-config)
>> > hadrian: Encountered missing or private dependencies:
>> > ghc ==9.3.*
>>
>> A package had a constraint on the ghc api to only accept ghc == 9.3.*.
>> Since you are trying to build ghc 9.2 this fails. The package in
>> question is printed by hadrian in this bit of your log:
>>
>>
>> > src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
>> >
>> shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle
>>
>> > * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package =
>>
>> > Package {pkgType = Program, pkgName = "haddock", pkgPath =
>> > "utils/haddock"}, way = v}))
>>
>> >    at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in
>>
>> Notice the `pkgName` field in the `Package` record in the error that
>> hadrian produced. It shows us that haddock was the cuplrit. Not sure
>> why/how that cabal file got mixed up but I bet if you went to
>> `${GHC_HOME}/utils/haddock/haddock.cabal` you'll find the constraint in
>> question and should be able to switch it to `ghc==9.2.*` and rebuild
>> according to the wiki.
>>
>>
>> Hope this helps,
>>
>>
>> Jeff
>>
>>
>> On 8/27/21 10:08 AM, ghc-devs-request at haskell.org wrote:
>> > Send ghc-devs mailing list submissions to
>> >       ghc-devs at haskell.org
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> >       http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> > or, via email, send a message with subject or body 'help' to
>> >       ghc-devs-request at haskell.org
>> >
>> > You can reach the person managing the list at
>> >       ghc-devs-owner at haskell.org
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of ghc-devs digest..."
>> >
>> >
>> > Today's Topics:
>> >
>> >     1. Failed to build latest stable GHC on FreeBSD with Hadrian
>> >        (Alexis Praga)
>> >
>> >
>> > ----------------------------------------------------------------------
>> >
>> > Message: 1
>> > Date: Fri, 27 Aug 2021 19:15:26 +0200
>> > From: Alexis Praga <alexis.praga at gmail.com>
>> > To: ghc-devs at haskell.org
>> > Subject: Failed to build latest stable GHC on FreeBSD with Hadrian
>> > Message-ID:
>> >       <CAH3o9gzh99J8SWPebkKsykEf+UD59S7-bSZi9OPQY1WxC_tE=
>> w at mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > Hi,
>> >
>> > As a complete beginner in regards to GHC, I tried to build GHC 9.2 as it
>> > looked like the latest stable from git.I failed to build 9.0.1 before
>> that.
>> >
>> > After checking out the ghc-9.2 branch, I ran (following the wiki):
>> >
>> >> ./boot
>> >> set LOCALBASE=/usr/local
>> >> ./configure --with-gmp-includes=$LOCALBASE/include
>> > --with-gmp-libraries=$LOCALBASE/lib --disable-large-address-space
>> >> hadrian/build -j
>> > This failed with :
>> >
>> >> | Configure package 'rts'
>> >> | Configure package 'haddock'
>> >> | Configure package 'ghc-bin'
>> >> # cabal-configure (for _build/stage0/utils/haddock/setup-config)
>> >> # cabal-configure (for _build/stage0/ghc/setup-config)
>> >> hadrian: Encountered missing or private dependencies:
>> >> ghc ==9.3.*
>> >>
>> >> Error when running Shake build system:
>> >>    at action, called at src/Rules.hs:40:19 in main:Rules
>> >>    at need, called at src/Rules.hs:62:5 in main:Rules
>> >> * Depends on: _build/stage0/bin/haddock
>> >>    at apply1, called at
>> > src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in
>> >
>> shake-0.19.4-9f51719be46f95213676da51d6a6626f69f0cfa15957aab44867ff78b757df38:Development.Shake.Internal.Rules.Oracle
>> >> * Depends on: OracleQ (ContextDataKey (Context {stage = Stage0, package
>> =
>> > Package {pkgType = Program, pkgName = "haddock", pkgPath =
>> > "utils/haddock"}, way = v}))
>> >>    at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in
>> > main:Hadrian.Oracles.Cabal.Rules
>> >> * Depends on: _build/stage0/utils/haddock/setup-config
>> >> * Raised the exception:
>> >> ExitFailure 1
>> > The config.log is attached.
>> >
>> > Any tips on how to proceed would be appreciated, thanks !
>> >
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>-- 
>
>   Alexis Praga

>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From alexis.praga at gmail.com  Sun Aug 29 16:42:38 2021
From: alexis.praga at gmail.com (Alexis Praga)
Date: Sun, 29 Aug 2021 18:42:38 +0200
Subject: Trying to create a regression test for #20261
Message-ID: <86a6l0i4n5.fsf@ecchi.mail-host-address-is-not-set>


Hi,

As a intermediate beginner in Haskell, I want to try to tackle a small
issue for contributing to GHC.

I've looked into https://gitlab.haskell.org/ghc/ghc/-/issues/20261, but
it's not clear how to integrate a running time in a regression test.

>From what I understand, regression tests should be compared against
sucess/failure or a given output.
Should there be a hard-coded limit ? If that's the case, how could I
create such a test ?  I could not find a similar test in the source
code.

Any help is appreciated, thanks !

-- 
Alexis Praga

From adam at well-typed.com  Sun Aug 29 19:56:33 2021
From: adam at well-typed.com (Adam Gundry)
Date: Sun, 29 Aug 2021 20:56:33 +0100
Subject: Trying to create a regression test for #20261
In-Reply-To: <86a6l0i4n5.fsf@ecchi.mail-host-address-is-not-set>
References: <86a6l0i4n5.fsf@ecchi.mail-host-address-is-not-set>
Message-ID: <8ade7367-e5cf-a771-a0a1-5d3ada8d75f2@well-typed.com>

Hi Alexis,


On 29/08/2021 17:42, Alexis Praga wrote:
> As a intermediate beginner in Haskell, I want to try to tackle a small
> issue for contributing to GHC.

Welcome! Thanks for trying your hand at contributing to GHC.


> I've looked into https://gitlab.haskell.org/ghc/ghc/-/issues/20261, but
> it's not clear how to integrate a running time in a regression test.
> 
> From what I understand, regression tests should be compared against
> sucess/failure or a given output.
> Should there be a hard-coded limit ? If that's the case, how could I
> create such a test ?  I could not find a similar test in the source
> code.

Have a look in testsuite/tests/perf/compiler. That directory contains a
number of compiler performance tests, which work by having the test
runner compare metrics about the compilation run for the current commit
vs. previous commits. The all.T file lists the tests to run and the
metrics to collect.

There's more details on the wiki:
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-tests/adding#performance-tests

Hope this helps,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

From lists at richarde.dev  Tue Aug 31 19:25:34 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 31 Aug 2021 19:25:34 +0000
Subject: How to set idScope properly when converting LhsExpr GhcPs to
 CoreExpr?
In-Reply-To: <d022261b-cb2b-2ca2-cee2-27fa6b237d97@terpmail.umd.edu>
References: <d022261b-cb2b-2ca2-cee2-27fa6b237d97@terpmail.umd.edu>
Message-ID: <010f017b9dac8553-3728260b-a26f-4ecf-a5c2-0de232b711c1-000000@us-east-2.amazonses.com>

I took a look at this today. I found

> Note [GlobalId/LocalId]
> ~~~~~~~~~~~~~~~~~~~~~~~
> A GlobalId is
>   * always a constant (top-level)
>   * imported, or data constructor, or primop, or record selector
>   * has a Unique that is globally unique across the whole
>     GHC invocation (a single invocation may compile multiple modules)
>   * never treated as a candidate by the free-variable finder;
>         it's a constant!
> 
> A LocalId is
>   * bound within an expression (lambda, case, local let(rec))
>   * or defined at top level in the module being compiled
>   * always treated as a candidate by the free-variable finder
> 
> After CoreTidy, top-level LocalIds are turned into GlobalIds

This suggests that the output you're seeing -- with "lid" in QQQ and "gid" in PPP -- is correct. What has drawn your attention to this problem? Is there something else that's misbehaving?

Thanks,
Richard

> On Aug 25, 2021, at 4:16 PM, Yiyun Liu <liuyiyun at terpmail.umd.edu> wrote:
> 
> Hi all,
> 
> We have a function in Liquidhaskell's code base for converting
> refinement expressions into GHC's core expressions using the GHC API.
> Its implementation is based on tcRnExpr
> <https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-8.10.6-release/compiler/typecheck/TcRnDriver.hs#L2358>except
> we keep the typechecked expression and desugar it before returning.
> 
> However, our function fails to set the idScope information properly when
> LiquidHaskell is invoked as a plugin (installed as a
> typeCheckResultAction). This repo
> <https://github.com/yiyunliu/ghc-elaboration-test>contains a minimal
> example that demonstrates the issue. In the CoreExpr returned by
> elabRnExpr
> <https://github.com/yiyunliu/ghc-elaboration-test/blob/cb7397884b7949e6b7fb6617ded10e86ee5dcad2/src/Test/Plugin.hs#L71>,
> every symbol from the current module that's being compiled is labeled as
> local. The README.md file shows how the exported symbol testPlus is
> marked as local in QQQ.hs, the module where it's defined.
> 
> Is there a function we should call to set the idScope information properly?
> 
> Thanks,
> 
> -Yiyun
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From lists at richarde.dev  Tue Aug 31 19:32:49 2021
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 31 Aug 2021 19:32:49 +0000
Subject: GHC plugin authors?
Message-ID: <010f017b9db32a02-ec72e9c8-4c81-46c6-ac00-bf936ef2647c-000000@us-east-2.amazonses.com>

Hi all,

I have seen a few posts from Sam Derbyshire here asking for feedback about plugin API design, and the responses have been minimal. This poses a design challenge, because the GHC folk who design the interface are sometimes distinct from the people who use the interface. We're trying to be good, seeking feedback from real, live clients. Is there a better way to do so than this mailing list? Example: we could create a Category on discourse.haskell.org, if that would reach the audience better. Or we could make a repo with issue trackers somewhere simply to track plugin design. What would work?

(I recognize that I'm asking in a perhaps-ineffective channel for advice, but I really don't have a better idea right now. Maybe some of you plugin authors are here and will point us in a better direction.)

Thanks,
Richard