- ghc-devs - Haskell.org

PMC: addConCt and newtypes bottom info
by Rodrigo Mesquita 27 Oct '23

27 Oct '23

Dear Sebastian and GHC devs, Regarding this bit from the function addConCt in the GHC.HsToCore.Pmc.Solver module, Nothing -> do let pos' = PACA alt tvs args : pos let nabla_with bot' = nabla{ nabla_tm_st = ts{ts_facts = addToUSDFM env x (vi{vi_pos = pos', vi_bot = bot'})} } -- Do (2) in Note [Coverage checking Newtype matches] case (alt, args) of (PmAltConLike (RealDataCon dc), [y]) | isNewDataCon dc -> case bot of MaybeBot -> pure (nabla_with MaybeBot) IsBot -> addBotCt (nabla_with MaybeBot) y IsNotBot -> addNotBotCt (nabla_with MaybeBot) y _ -> assert (isPmAltConMatchStrict alt ) pure (nabla_with IsNotBot) -- strict match ==> not ⊥ My understanding is that given some x which we know e.g. cannot be bottom, if we learn that x ~ N y, where N is a newtype (NT), we move our knowledge of x not being bottom to the underlying NT Id y, since forcing the newtype in a pattern is equivalent to forcing the underlying NT Id. Additionally, we set x’s BottomInfo to MaybeBot — However, I don’t understand why we must reset x’s BotInfo to MaybeBot — couldn’t we keep it as it is while setting y’s BotInfo to the same info? An example where resetting this info on the newtype-match is important/necessary would be excellent. FWIW, I built and tested the PMC of ghc devel2 with MaybeBot -> pure (nabla_with MaybeBot) IsBot -> addBotCt (nabla_with IsBot) y IsNotBot -> addNotBotCt (nabla_with IsNotBot) y And it worked without warnings or errors… Thanks in advance! Rodrigo

2 1

How do you keep tabs on commits that fix issues?
by Bryan Richter 16 Oct '23

16 Oct '23

I am not sure of the best ways for checking if a certain issue has been fixed on a certain release. My past ways of using git run into certain problems: The commit (or commits!) that fix an issue get rewritten once by Marge as they are rebased onto master, and then potentially a second time as they are cherry-picked onto release branches. So just following the original commits doesn't work. If a commit mentions the issue it fixes, you might get some clues as to where it has ended up from GitLab. But those clues are often drowning in irrelevant mentions: each failed Marge batch, for instance, of which there can be many. The only other thing I can think to do is look at the original merge request, pluck out the commit messages, and use git to search for commits by commit message and check each one for which branches contain it. But then I also need to know the context of the fix to know whether I should also be looking for other, logically related commits, and repeat the dance. (Sometimes fixes are only partially applied to certain releases, exacerbating the need for knowing the context.) This seems like a mechanism that can't rely on trusting the author of the original set of patches (which may be your past self) and instead requires a deep understanding to be brought to bear every time you would want to double check the situation. So it's not very scalable and I wouldn't expect many people to be able to do it. Are there better mechanisms already available? As I've said before, I am used to a different git workflow and I'm still learning how to use the one used by GHC. I'd like to know how others handle it. Thanks! -Bryan

7 7

Proposal for communication with GHC API users
by Facundo Domínguez 13 Oct '23

13 Oct '23

Dear GHC devs, Your feedback is appreciated in a new proposal to streamline communication with the authors of the GHC API as GHC evolves [1]. The proposal aims to set a process to collect detailed information on how users depend on the GHC API, and how GHC developers think these dependencies should be adjusted when there are breaking changes. This proposal is related to the endeavor to stabilize the GHC API [2]. Although, rather than trying to define a stable API, it sets a process to deal with the current state of affairs where users depend on many unstable parts. Looking forward to your thoughts! Facundo [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24096 [2] https://discourse.haskell.org/t/charting-a-course-toward-a-stable-api-for-g… -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.

1 1

[ANNOUNCE] GHC 9.8.1 is now available
by Ben Gamari 09 Oct '23

09 Oct '23

The GHC developers are very pleased to announce the availability of the final release of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.8.1 GHC 9.8 brings a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes][]. Plans for GHC's future releases can be found on the [GHC Wiki][status]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-d… [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-s… [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-u… [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-w… [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-d… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [release notes]: https://downloads.haskell.org/ghc/9.8.1/docs/users_guide/9.8.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status

1 0

Darwin runners fixed on master
by Bryan Richter 05 Oct '23

05 Oct '23

Hi all, A reinstall of Darwin runners exposed https://gitlab.haskell.org/ghc/ghc/-/issues/24055, which shows up as a failure to fetch perf notes. The fix has landed on master so you may want to rebase to pick it up. -Bryan

1 0

Migrating GHC's real-time communications to Matrix? (#24010)
by Ben Gamari 02 Oct '23

02 Oct '23

Hello all, GHC's user and contributor documentation currently directs users to #ghc on irc.libera.chat for discussion of GHC development. However, for a variety of reasons the center-of-mass of discussion has been gradually shifting towards Matrix (#GHC:matrix.org). Given that Matrix appears to be both more active and more accessible to newcomers, I suggest that we recognize this shift in our documentation. If you agree or disagree with this proposal please leave a :thumbsup: or :thumbsdown: on [#24010] and feel free to leave a comment explaining your feelings. Cheers, - Ben [#24010]: https://gitlab.haskell.org/ghc/ghc/-/issues/24010

1 0

[ANNOUNCE] GHC 9.8.1-rc1 is now available
by Ben Gamari 29 Sep '23

29 Sep '23

The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-rc1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This candidate includes roughly 20 new commits relative to alpha 4, including what we believe should be nearly the last changes to GHC's boot libraries. As always, GHC's release status can be found on the GHC Wiki [status]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-d… [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-s… [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-u… [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-w… [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-d… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status

1 0

GHC 9.8.1-rc1 delayed
by Ben Gamari 29 Sep '23

29 Sep '23

Hi all, Due to a rather late-breaking boot library mix-up I will need to delay the 9.8.1 release candidate by at least two days. I will provide a more specific timeline tomorrow when there is more clarity on what needs to happen to resolve the situation. Cheers, - Ben

1 1

GitLab upgrade later today
by Ben Gamari 25 Sep '23

25 Sep '23

Hi all, I will be performing a GitLab upgrade later this evening (likely around 18:00 EDT). I expect this will take only a few minutes. Cheers, - Ben

1 1

[ANNOUNCE] GHC 9.6.3 is now available
by Bryan Richter 25 Sep '23

25 Sep '23

The GHC developers are happy to announce the availability of GHC 9.6.3. Binary distributions, source distributions, and documentation are available on the release page. https://www.haskell.org/ghc/download_ghc_9_6_3.html This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * Disable Polymorphic Specialisation (a performance optimisation) by default. It was discovered that Polymorphic Specialisation as currently implemented in GHC can lead to hard to diagnose bugs resulting in incorrect runtime results. Users wishing to use this optimisation despite the caveats will now have to explicitly enable the new `-fpolymorphic-specialisation` flag. For more details see #23469 as well as #23109, #21229, #23445. * Improve compile time and code generation performance when `-finfo-table-map` is enabled (#23103). * Make the recompilation check more robust when code generation flags are changed (#23369). * Addition of memory barriers that improve soundness on platforms with weak memory ordering. * And dozens of other fixes. A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [GHC ticket] if you see anything amiss. Enjoy! -Bryan [release notes]: https://downloads.haskell.org/~ghc/9.6.3/docs/users_guide/9.6.3-notes.html [GHC ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0