- ghc-devs - Haskell.org

Getting Info Table Profiling to the finish line
by Hécate 13 Feb '23

13 Feb '23

Hello fellow devs, I am indexing the work necessary to bring Info Table Profiling to the finish line: Seamless for the user to employ. Some of the tickets refer to external ticket trackers, they have been marked as FOREIGN. Their counterpart tickets will be opened there when the situation unlocks on our side. The epic is at https://gitlab.haskell.org/groups/ghc/-/epics/3 Please feel free to link future tickets that are related to this newer, better way of doing space profiling. My thanks to Matthew Pickering, David Eichmann, and Ben Gamari. Cheers, Hécate (with a project manager hat on, apparently!) -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

[Haskell] [ANNOUNCE] GHC 9.2.6 released
by Zubin Duggal 10 Feb '23

10 Feb '23

The GHC developers are happy to announce the availability of GHC 9.2.6. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.2.6). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_6.html Blog Post: https://www.haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.5. These include: * Fixes for a number of simplifier issues typically resulting in compiler panics (#22491, #22482, #19824, #22718, #22662, #22039). * Fix for a simplifier regression in 9.2.5 that could impact runtime performance when compiling with optimisations due to duplication of expensive work (#22425). * Various stability improvments and bug fixes for the non moving and parallel GCs (#22528, #20221, #22264, #22327, #22929, #22927, #22929, #22930). * Allow certain keywords which can be used as variable names with `-XOverloadedRecordDot` (#20723). * Improvements to typechecker performance for modules with holes in type signatures (#14766) * Bump `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * ... and a few more. See the [release notes] for a full accounting. 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 [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.6/docs/html/users_guide/9.2.6-notes.…

1 0

Registering account in gitlab.haskell.org
by ccycle 06 Feb '23

06 Feb '23

Hi, I'm new to ghc-devs(a)haskell.org and would like to report a bug in GHC that I have encountered. I tried to log in with an account registered in gitlab.haskell.org to create an issue and then I got the following error: > Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error. Could someone approve my account? My account pending approval is: Username: ccycle Email: ccycle713(a)gmail.com

2 4

Preventing inert caching in TC plugin?
by Sandy Maguire 04 Feb '23

04 Feb '23

Hi all, I'm working on a little TC plugin that solves the following class: ```haskell class KnownAnnotations where rawAnnotationsVal :: [Annotation] ``` Like `HasCallStack`, the result of `KnownAnnotations` is unique to each callsite. Thus, I am trying to prevent my TC plugin from adding the solved constraint to the inert set. As an example, the following program: ``` t2 :: ([Annotation], Int) t2 = (rawAnnotationsVal, test2) t3 :: ([Annotation], Int) t3 = (rawAnnotationsVal, test3) ``` dumps this output with `-ddump-cs-trace`: ``` Step 1[l:0,d:0] Kept as inert: [WD] $dKnownAnnotations_a18UB {0}:: KnownAnnotations Step 2[l:0,d:0] Dict equal (keep inert): [WD] $dKnownAnnotations_a18UD {0}:: KnownAnnotations ``` Is there some trick to prevent the inert caching for these solved wanteds? Cheers, Sandy

2 2

LLVM Support Range Bump (dropping LLVM 10 support)
by Matthew Pickering 02 Feb '23

02 Feb '23

Hi all, We are intending to bump the range of supported LLVM versions in the 9.6, release. For 9.4 the range is 10-14 (inclusive) For 9.6 we will support 11-15 (inclusive) If dropping support for LLVM 10 is a concern for anyone please let us know. Cheers, Matt

1 0

FFI changes?
by Dominick Samperi 01 Feb '23

01 Feb '23

Hello, I have been working with a program that uses FFI to communicate with R for several years, but today there is a segmentation fault while importing functions or data from R. Before giving up on this project, I'm posting a few detail here, in case anybody has ideas...perhaps something changed with FFI? I tried going back to the version of R and ghc where it worked using stack, but no luck. The Haskell code is a modification of the code in the package hR (by Dylan Simon), and here is a function that fails that worked before. It fails with a seg fault on the call to r_install. (s = "parse" when it fails)... foreign import ccall safe "Rf_install" r_Install :: CString -> IO R_EXP rInstall :: String -> IO REXP rInstall s = withCString s r_Install >>= extREXP The types are defined as follows... extREXP :: R_EXP -> IO REXP extREXP = newForeignPtr_ data REXPREC type R_EXP = Ptr REXPREC type REXP = ForeignPtr REXPREC newtype SEXP a = SEXP { unSEXP :: REXP } deriving (Eq, Show) Please let me know if you see anything obviously wrong and in need of improvement, perhaps because of changes to the FFI. Thanks, Dominick

3 3

9.2.6 forthcoming release
by Matthew Pickering 01 Feb '23

01 Feb '23

Hi all, We are preparing potentially the final release in the 9.2.* series. Zubin is preparing the release and we hope to deliver the release in the next 1-2 weeks. The two most critical bugs which 9.2.6 will fix is * #22425 which is a performance regression introduced in 9.2.5. * #22497 which will fix 9.2.* on recent aarch64-darwin platforms. There are a few other bugs which will be fixed in the release but we are being very conservative at this stage about introducing potential breakage. The backport set is being prepared on this branch: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9775 Cheers, Matt

1 0

Slow downloads
by Simon Peyton Jones 01 Feb '23

01 Feb '23

I'm getting very low transfer rates on Git operations. Like 16 kb/s. Things that usually take a second or two are still going 10 minutes later. See below My internet connection appears to be solid at 100Mb/s upload and download. Any ideas? Simon [image: image.png]

2 1

[ANNOUNCE] GHC 9.6.1-alpha2 is now available
by Ben Gamari 30 Jan '23

30 Jan '23

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha2. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1-alpha2/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell. - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 will include: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a [migration guide] to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older `glibc` releases (namely 2.27), respectively. Please do give this release a try and open a [ticket] if you see anything amiss. Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes…

1 0

Extracting comments from the source code
by Facundo Domínguez 30 Jan '23

30 Jan '23

Dear GHC devs, I'm trying to port Liquid Haskell to ghc 9.2.5. And having much difficulty using the GHC API for a specific task, so I come here to ask about it. As you may know already, Liquid Haskell needs to read special comments from Haskell source code which have the form {-@ ... @-}. For example > module Demo.Lib where > > {-@ type Pos = {v:Int | 0 < v} @-} > > {-@ incr :: Pos -> Pos @-} > incr :: Int -> Int > incr x = h x > where > {-@ h :: Pos -> Pos @-} > h x = x - 1 Since Liquid Haskell runs as a GHC plugin, it has access to the GHC API. It used to be the case that one could find all of the comments together with their source spans in a field pm_annotations :: ParsedModule -> ApiAnns -- [1] However this field has been removed in ghc-9.2, and now the comments are all spread through the AST after parsing. I managed to collect them all again with a generic traversal: > go :: forall a. Data a => a -> [LEpaComment] > go = gmapQr (++) [] go `extQ` (id @[LEpaComment]) but I'd expect this to be rather slow. So I'd like to ask here, is there a better way to collect all of the comments? The other obvious way would be to write the traversal manually, but it would be some code to write, and it would likely need attention when porting to newer GHCs onwards. Thanks! Facundo [1]: https://hackage.haskell.org/package/ghc-9.0.2/docs/GHC.html#t:ParsedModule

3 3