Re: Deprecating Safe Haskell, or heavily investing in it?
Thanks for writing this up!
I was a user of SafeHaskell briefly in 2011-2012, and it certainly has
theoretical benefits. That said, though, I agree that the balance of the
cost-benefit analysis is solidly against it, and I would much rather ease
the burden of GHC and library development than continue to maintain a
burdensome niche feature with limited users.
That said, I think some of the comments in this thread are unnecessarily
dismissive of SafeHaskell's usefulness and correctness. So here are a few
things worth keeping in mind:
1. The strict type safety aspect of SafeHaskell is, in fact, the mechanism
that makes SafeHaskell effective at controlling effects through limited IO
access. You simply cannot have the latter without the former. Generalized
newtype deriving, for example, is incompatible with SafeHaskell precisely
because it can be used to break restricted IO access. It looks like a lot
of the responses here ignore that SafeHaskell did a lot of work to make
runtime-cost-free safe execution reliable, then make hand-wavy references
to other systems that don't do any of that, and use that as a basis for
asserting distrust in SafeHaskell. That's entirely unfair.
2. The assertion that safety in SafeHaskell depends on the correctness of a
bunch of libraries assertions about their safety reveals a fundamental lack
of understanding of how SafeHaskell works. Safety is inferred
compositionally from the source code and the safety of the modules it uses,
and a source code annotation about safety can never compromise the safety
guarantees of SafeHaskell. The only thing that can compromise safety is a
misplaced trust decision. Trust decisions are not in the source code at
all. They are made outside the source by running `ghc-pkg trust`.
This conversation reminds me of a parable I encountered somewhere, in which
someone declares "I don't understand why this decision was ever made, and I
we should change it", and someone responds, "No, if you don't understand
the decision was made, then you don't know enough to change it. If you
learn why it was decided that way in the first place, then you will have
the understanding to decide whether to change it." Just like in the
parable, I am not disagreeing with the idea of deprecating SafeHaskell, but
I am skeptical that the decision should be made on the basis of
misrepresentations and crude analogies that completely miss what's unique
and interesting about SafeHaskell in the first place.
On Tue, Dec 27, 2022, 10:10 AM Hécate wrote:
> Hi everyone, and happy holidays.
>
> I am looking into whether or not Safe Haskell is still worth maintaining.
>
> Currently there are two sides on which Safe Haskell hurts us:
>
> 1. GHC Development
> 2. Library development
>
> For point n°1: You can easily take the measure of what Safe Haskell
> raises in GHC as of today by visiting the bug tracker¹ and see that for
> example Unboxed Types cannot be used because their home modules
> (GHC.Prim and GHC.Types) are marked as Unsafe. Moreover, interactions
> between GHC2021 and Safe make the latter quite unpleasant to work with².
>
> Regarding point n°2: Safe Haskell is badly integrated within our
> existing frameworks for API compatibility. Neither the PVP nor the
> extension's documentation mention compatibility, or define what stance
> we should take. Thus we are bound to fight on the letter versus the
> spirit of the PVP (which is not an unreasonable debate since there is no
> formalism anywhere). This provokes debates without clear resolution
> beyond "Friend don't let friends use {-# Safe #-}"³
>
> Now I am not saying that Safe Haskell does not bring any kind of good
> idea, far from it.
>
> However there are two things that live inside Safe Haskell that would
> benefit from being separated:
>
> 1. Strict type-safety
>
> 2. Restricted IO
>
> A lot of the public use-cases of Safe Haskell seem to be on the
> "Restricted IO", such as Lambdabot and other code evaluators out there.
>
> It's a fairly reasonable feature, I'd even say it's something that we
> should be publicising more when speaking about GHC's more advanced
> features. However, "Strict type-safety" seems to be the root of many
> problems that we encounter downstream. A lot of it stems from
> GeneralizedNewtypeDeriving being marked as unsafe (under point 1), which
> is fair enough, but we've had DerivingVia not marked as Safe until May
> 2021, which reveals a big problem: Options have to be marked as
> forbidden under Safe to be caught, which leaves a lot of work to the
> human factor of GHC development.
>
> Now, there are two options (convenient!) that are left to us:
>
> 1. Deprecate Safe Haskell: We remove the Safe mechanism as it exists
> today, and keep the IO restriction under another name. This will
> certainly cause much joy amongst maintainers and GHC developers alike.
> The downside is that we don't have a mechanism to enforce "Strict
> type-safety" anymore.
>
> 2. We heavily invest in Safe Haskell: T
Re: DWARF support
Just to satisfy my curiosity here, when talking about backtraces here, are you talking about a lexical call stack, or an execution stack? On Thu, Nov 18, 2021 at 11:24 AM Richard Eisenberg wrote: > > > On Nov 18, 2021, at 10:29 AM, Ben Gamari wrote: > > At this point, for backtrace support I would rather put my money is on a > native Haskell stack unwinder (such as Sven Tennie's work [3,4]). Not only > is it more portable but it is also more robust (whereas with DWARF any > single object lacking debug information would break unwinding), and is > significantly less costly since we know much more about the structure of > our stack than a DWARF unwinder would. > > > Interesting -- this is helpful to know. I had heard about DWARF support > for some years and thought that it would deliver stack traces. Now I will > look for other sources. All good -- I understand how this is hard! -- and > nice to know about. > > Thanks for the writeup, Ben. > > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Why can't arguments be levity polymorphic for inline functions?
On Fri, Oct 8, 2021 at 10:51 AM Ben Gamari wrote: > In my mind the fundamental problem with this approach is that it means > that a program's acceptance by the compiler hinges upon pragmas. > This is a rather significant departure from the status quo, where one > can remove all pragmas and still end up with a well-formed program. > In this sense, pragmas aren't really part of the Haskell language but > are rather bits of interesting metadata that the compiler may or may not > pay heed to. > I don't believe this is really the status quo. In particular, the pragmas relating to overlapping instances definitely do affect whether a program type-checks or not. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: new label: diagnostic quality
Oops, I meant to include this URL: https://github.com/google/codeworld/issues?q=label%3Aerror-message+%22code.world%2Fhaskell%22 is the full list (including closed issues) of cases where someone has reported a misleading error message at code.world/haskell On Tue, Sep 7, 2021 at 9:03 PM Chris Smith wrote: > Hi Richard, > > One thing that I've done with CodeWorld for years now was to integrate > reporting poor error messages into the core workflow by adding a report > button on the compiler output directly in the tool. This integration files > github issues with a special tag for error messages. Because CodeWorld is > targeted at younger users and already rewrites error messages, most of the > reports I get from CodeWorld itself are not directly applicable to GHC. > Here's a list of cases where someone clicked that button at > code.world/haskell, but I usually close them with no action unless there's > something egregious because I want code.world/haskell to be an > authentic GHC experience. In any case, I strongly suggest looking into > similar tooling for more standard Haskell environments with editors like > VSCode or Emacs. I don't know if this could be done in HLS, or would need > to be separately implemented for each editor. I'll happily offer to > implement a CodeWorld endpoint for filing GitLab error message reports > similar to this which such integrations could post to. The lower you can > make the friction to report a misleading message, the more likely you'll > get authentic reports from users rather than idle issue-theorizing. > > These will probably need some kind of a triage process to turn them into > actionable issues, and perhaps in my experience to just close 75% of them > where it's unclear what was meant or the user just wanted to gripe. (That > may have something to do with the fact that my users have often > procrastinated on their homework, though...) But that triage process is > something that you could easily ask for help on. I would be willing to > comb through reports now and then, for example, and look for opportunities > to do better. > > On Tue, Sep 7, 2021 at 2:51 PM Richard Eisenberg > wrote: > >> Hi devs, >> >> I've just created a new label in GitLab, called "diagnostic quality". >> (Diagnostics = errors ∪ warnings.) I intend for this label to be used when >> the report is about the quality of an error message or warning. That is, >> the existing message is not wrong, per se, but it's somehow not as helpful >> as it can be to users. I think it's helpful to separate out such issues >> from those describing error messages that are just wrong. >> >> In particular, if you spot a ticket arising from >> https://github.com/haskell/error-messages, you may want to give it the >> "diagnostic quality" label. >> >> If you disagree with the choice to make this label, please push back! >> >> Thanks, >> Richard >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: new label: diagnostic quality
Hi Richard, One thing that I've done with CodeWorld for years now was to integrate reporting poor error messages into the core workflow by adding a report button on the compiler output directly in the tool. This integration files github issues with a special tag for error messages. Because CodeWorld is targeted at younger users and already rewrites error messages, most of the reports I get from CodeWorld itself are not directly applicable to GHC. Here's a list of cases where someone clicked that button at code.world/haskell, but I usually close them with no action unless there's something egregious because I want code.world/haskell to be an authentic GHC experience. In any case, I strongly suggest looking into similar tooling for more standard Haskell environments with editors like VSCode or Emacs. I don't know if this could be done in HLS, or would need to be separately implemented for each editor. I'll happily offer to implement a CodeWorld endpoint for filing GitLab error message reports similar to this which such integrations could post to. The lower you can make the friction to report a misleading message, the more likely you'll get authentic reports from users rather than idle issue-theorizing. These will probably need some kind of a triage process to turn them into actionable issues, and perhaps in my experience to just close 75% of them where it's unclear what was meant or the user just wanted to gripe. (That may have something to do with the fact that my users have often procrastinated on their homework, though...) But that triage process is something that you could easily ask for help on. I would be willing to comb through reports now and then, for example, and look for opportunities to do better. On Tue, Sep 7, 2021 at 2:51 PM Richard Eisenberg wrote: > Hi devs, > > I've just created a new label in GitLab, called "diagnostic quality". > (Diagnostics = errors ∪ warnings.) I intend for this label to be used when > the report is about the quality of an error message or warning. That is, > the existing message is not wrong, per se, but it's somehow not as helpful > as it can be to users. I think it's helpful to separate out such issues > from those describing error messages that are just wrong. > > In particular, if you spot a ticket arising from > https://github.com/haskell/error-messages, you may want to give it the > "diagnostic quality" label. > > If you disagree with the choice to make this label, please push back! > > Thanks, > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Breaking changes to the base library
Yikes, this is going to break nearly everything. Definitely good to let people know. On Sun, Jun 20, 2021 at 7:43 AM Ben Gamari wrote: > Harendra Kumar writes: > > > I see the following errors when compiling with ghc head version: > > > > $ ghc-stage2 --version > > The Glorious Glasgow Haskell Compilation System, version 9.3.20210608 > > > > $ cabal build --with-compiler ghc-stage2 --allow-newer > > > > Data/Colour/CIE.hs:80:12: error: > > Ambiguous occurrence ‘sum’ > > It could refer to > >either ‘Prelude.sum’, > > imported from ‘Prelude’ at Data/Colour/CIE.hs:25:8-22 > > (and originally defined in ‘Data.Foldable’) > >or ‘Data.List.sum’, > > imported from ‘Data.List’ at Data/Colour/CIE.hs:41:1-16 > > (and originally defined in ‘GHC.List’) > >| > > 80 |total = sum $ map fst l > >|^^^ > > > > Can someone briefly describe this change and what's the recommended way > of > > fixing this? Just hide the Data.List definition? I do not see this > > mentioned in the release notes of 9.2/9.4 here: > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/9.2.1-notes.html > > > Indeed, this is due to the monomorphic Data.List proposal, which the > CLC decided would accompany the addition of Data.List.singleton. The > correct fix here is to either qualify the import of `Data.List` or add > an explicit import list. I'll try to remember to add a note about this > to the release notes and migration guide. > > > Cheers, > > - Ben > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Is simplified subsumption really necessary?
This might be in the "ship has sailed" territory, but I'd like to bring it up anyway. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst says: Suppose GHC lacked all four features, and someone proposed adding them. > That proposal would never leave the launchpad. > Let's test that hypothesis. I've been spending increasing amounts of time fighting against simplified subsumption while porting Haskell code to GHC 9.0. It's not that any specific instance of this problem is hard to fix; rather, it's that it completely screws up my intuition about what should be valid Haskell. It doesn't help that HLS still requires 8.10.4, so I usually don't find out I've broken my libraries for GHC 9.0 until continuous integration kicks in. At this point, it's become fairly routine that my code that works fine with 8.10.4 is broken with 9.0, and this makes me sad. Understandably, eta expansion reducing the strictness of terms is bad. But wouldn't it be possible to choose a desugaring with seq that doesn't do so? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC and the future of Freenode
Viktor, Sorry you had a bad experience. Perhaps it will help to know that these bans are automatically done by bots to prevent the channel from being flooded by nefarious users. That you were caught by it was just a false positive because you triggered the flooding detection. It doesn't mean anyone was upset at you or didn't want to talk to you. When I've seen it happen in #haskell in the past, the person involved has been able to immediately rejoin and resume the conversation. Chris On Sun, Jun 6, 2021 at 2:08 PM Viktor Dukhovni wrote: > On 19 May 2021, at 11:48 am, Carter Schonwald > wrote: > > > I personally vote for irc. Perhaps via Libera. > > Perhaps I'm too much of an IRC noob, but I still found it it rather > surprising to be banned from libera.chat (my IP is blacklisted) for > pasting a 25-line build script for building GHC via hadrian on FreeBSD > into the #ghc channel. > > This was in response to a discussion about issues with the bindist, > how the port is built, ... and while perhaps I'm expected to use a > paste bin, the abrupt ban was rather a harsh response. > > The ban appears to have been "temporary", an hour or so later I am > able to reconnect, but this does not leave a good impression. > > -- > Viktor. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC and the future of Freenode
No, unfortunately, this is not resolved. The link here is a fictitious whitewash of events posted by the person who conducted the hostile takeover of Freenode. At the moment, the state of Freenode is that it's still operating as an IRC network, but the volunteer staff who have operated the network for many years have resigned and at least many of them have moved to operating irc.libera.chat. The network is completely controlled by one person, who wasn't involved in running it at all until a few days ago. On Sat, May 22, 2021 at 2:31 AM Imants Cekusins wrote: > Was this a temporary issue with Freenode IRC, resolved by now? > > https://freenode.net/news/freenode-is-foss > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Coding style: Using StandaloneKindSignatures in GHC
On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal wrote: > > encouraging the use of a standalone signature for type declarations > where at least one parameter of the datatype does not have kind Type. > > So Dict, Eq both get a sig but Fix and Either do not? > > type Dict :: Constraint -> Type > type Eq :: Type -> Constraint > type Fix :: (Type -> Type) -> Type That's not how I understand Richard's criteria. Dict and Fix have non-Type parameters (Dict has a Constraint parameter, and Fix has a (Type -> Type) parameter. On the other hand, Eq and Either have only Types as parameters. This seems to match my intuition about when a kind signature might be helpful, as well as yours as far as I can tell from what you wrote. That's not to say I am advocating any kind of rule. As I'm not really involved in GHC development, I refrain from having any opinion. I just think you may have misread Richard's suggestion. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: structured error messages
Thanks, Richard. This is awesome! For my use case, the more exciting possibility would be to interact with error messages from JavaScript. For this reason, I'd definitely love to see a well-known structured file format (JSON, YAML, XML, or whatever) that can be read without linking against GHC. I also like the idea of producing both the structured data and the raw string, since as you mention, one shouldn't need to handle every single possible GHC diagnostic just to add some special handling for a few of them. Ultimately, if reading error messages did require linking with GHC, it wouldn't be the end of the world. I would just write my own translation layer to JSON. So consider this a weak preference. On Mon, May 3, 2021 at 3:00 PM Richard Eisenberg wrote: > Hi all, > > Alfredo and I are hard at work redesigning GHC's error-message system. It > is time for more input, though, from clients of the system -- those writing > IDEs and other tooling on top of GHC. > > The key question: How would you like your errors served? > > Right now, errors are served well-done: fully cooked into structureless > strings that can be easily given to users. The problem with this is that > IDEs cannot easily intervene between GHC and the users, as all the > nutrition (that is, detailed information) has been cooked away. > > The new design allows for *structured errors*, where error messages are > represented by elements of some error type. Different messages have > different constructors of this type, and these constructors can carry > auxiliary information. GHC will store these errors raw and cook them (that > is, turn them into readable strings) only right before printing them. If > the raw messages were somehow passed to IDEs, then IDEs could handle them > non-uniformly. (For example, if a module name and a file name are > different, the IDE could just present a dialog to the user asking whether > the user would like to change one automatically.) > > There are a few open questions: > > * In what vessel shall the raw messages be served? In other words, how do > IDEs expect to interact with this new system? > - One route would be to pass e.g. -fjson-errors, which means that GHC > presents the raw messages in a JSON format, for IDEs to parse. That's OK, > but it still means that IDEs would have to have their own raw error message > types to parse into. > - Another route would be for the IDE to link against GHC itself, and > then invoke the compiler via a function call that returns the raw messages > directly. > - Another route is some kind of middle ground, where the IDE passes e.g. > -fbinary-errors= instructing GHC to write out a binary encoding > of its messages to some file (or pipe, I suppose). These could then be > deserialized back into GHC's own error types, but running in a separate > process (linked against GHC, once again). > - I'm sure you can come up with other interaction strategies. > > * What will an IDE do with these messages? It might have special handling > for some, but GHC has a lot of different messages, and I imagine IDEs will > want many just to be printed to the user. If an IDE has only the raw > message, then the IDE is forced to do all the cooking -- no good. So there > must be a way to take a raw message and render it into a user-readable > string. > - Maybe the above methods produce both the raw error and the rendered > one? Then the IDE can choose which it prefers to use. > - GHC could easily export its pretty-printing functions that take in the > raw messages and produce rendered ones. But that (again) requires linking > against GHC. > > Note that we are not (here, yet) discussing errors served at points > between raw and well-done, though I would like to do so. Such an error > would be rendered into a format where textual bits are interleaved with > more structured bits, which would enable e.g. clicking on expressions > within error messages to get their types. That (important feature) comes > separately. > > So: what do consumers want here? > > Preview: You can take a look at some raw error messages from the driver in > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533. > > Thanks! > Richard > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: !RE: Implicit reboxing of unboxed tuple in let-patterns
I agree that the strictness there was surprising, but I think this may be a case where what is superficially expected is, in the end, inconsistent. What about: let ~(!x, !y) = undefined in () If nested bang patterns implied strictness of their parents, this valid expression seems not to make any sense. I can see a few ways to deal with that, but none of them seem intuitive to me. One could disallow it, and only allow strictness annotations on variables rather than all patterns, but this sacrifices a lot of functionality to avoid that surprise. Alternatively, one could say that upward propagation of strictness is only a default, but that definitely feels like a hack. It might make the original example behave as expected, but it is no longer for the expected reasons, and suddenly there is something even more complex going on. I don't have a strong opinion here, but I think it's important to consider more complex cases when making the decision. On Thu, Sep 10, 2020, 12:39 PM Iavor Diatchki wrote: > Ah, yes, quite right: since the projections match the whole patterns, the > bang patterns in a constructor would be forced as soon as one of the fields > in the constructor is used, so this also diverges: > > ex3 = let (x, !y) = (5,undefined) in x > > The rule is consistent, to me it just seems quite unintuitive. > > > > On Thu, Sep 10, 2020 at 9:18 AM Richard Eisenberg > wrote: > >> This whole area is clearly somewhat troublesome: >> >> On Sep 10, 2020, at 12:05 PM, Iavor Diatchki >> wrote: >> >> 3. nested bang patterns in pattern bindings should count as "uses" of the >> value and therefore should be strict. For example if I write `let ( !x, !y >> ) = undefined in ()`, I think this should be equivalent to `let (x,y) = >> undefined in x `seq` y `seq` ()`. With the current behavior the bang >> patterns don't do anything, while my guess would be that most people would >> expect the suggested behavior instead. As usual, we should not allow that >> at the top level. >> >> >> This isn't quite right. >> >> Consider >> >> ex0 = let ( !x, !y ) = undefined in () >> ex1 = let ( !x, !y ) = (5, undefined) in x >> ex2 = let ( !x, y ) = (5, undefined) in x >> >> >> ex0 converges, because let-bindings are lazy by default. >> ex1 diverges, because the bang on y means that, when the patten-match >> happens at all, x and y are bound strictly. So bangs *do* matter in nested >> patterns within pattern bindings. By contrast, ex2 converges. >> >> Again, I'm not arguing in favor of the current behavior, but I want to >> make sure we're all as informed as possible in this debate. >> >> Richard >> > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Looking for a recent error reporting change
My reason for sticking with 8.6.5 is that I don't yet trust GHCJS with later GHC versions. Thanks everyone for the pointers and suggestions. I'll look further into this when I have more time. (Alas, it's not my full-time job, so that's probably not until the weekend.) On Mon, Jun 15, 2020 at 5:11 AM Simon Peyton Jones wrote: > Is there a reason you want to stick with 8.6.5? > > > > One way to find what you want is to use git-bisect to find the commit that > made the change. I think various people have automated setups for this. > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Chris Smith > *Sent:* 14 June 2020 14:43 > *To:* ghc-devs@haskell.org > *Subject:* Looking for a recent error reporting change > > > > Hi. In GHC 8.6.5, if I compile a main module that both fails to define > `main` and also contains other errors, the other errors are not reported > because GHC aborts after realizing that there is no `main`. In GHC 8.10.1, > all errors are reported. I'm looking for where this change was made, in > the hopes that it's easy to backport to a local branch of GHC 8.6.5. Does > anyone know off-hand? > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Looking for a recent error reporting change
Hi. In GHC 8.6.5, if I compile a main module that both fails to define `main` and also contains other errors, the other errors are not reported because GHC aborts after realizing that there is no `main`. In GHC 8.10.1, all errors are reported. I'm looking for where this change was made, in the hopes that it's easy to backport to a local branch of GHC 8.6.5. Does anyone know off-hand? ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
