May 2021 - ghc-devs - Haskell.org

GHC head, profiling with -O2 does not work
by Harendra Kumar 23 May '21

23 May '21

Hi, I am trying to build a small program with profiling using a ghc built from haskell gitlab master branch. When I use -O2 I run into: $ ghc/inplace/bin/ghc-stage2 --make -O2 -prof -fprof-auto -rtsopts Main.hs Linking Main ... ./StreamD.o(.text+0x1b9f2): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' ./MArray.o(.text+0xbe83): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' Main.o(.text+0x6fdb): error: undefined reference to 'StreamK_mkStreamFromStream_HPC_cc' collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) It builds fine without the -O2 option. On ghc-8 it builds fine even with -O2. Is that a bug in the head GHC or just something to do with how I built it? Thanks, Harendra

2 1

Darwin CI Status
by Matthew Pickering 20 May '21

20 May '21

Hi all, The darwin pipelines are gumming up the merge pipeline as they are taking over 4 hours to complete on average. I am going to disable them - https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785 Please can someone give me access to one of the M1 builders so I can debug why the tests are taking so long. Once I have fixed the issue then I will enable the pipelines. Cheers, Matt

2 2

Second Call for Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 16 May '21

16 May '21

Call for 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: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 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. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. 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 Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins 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. 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. 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 <xnning at hku.hk>

1 0

an issue tracker for better error messages
by Richard Eisenberg 13 May '21

13 May '21

Hi devs, I've just posted https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-… <https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-…>, a description of an idea to create an issue tracker dedicated only to error messages. My hope is that the tracker is used to boil issues users have with error messages down to a concrete suggestion for a wording change -- and that only when we have that concrete suggestion will a ticket be made on the GHC tracker. What do we think here of this idea? If you have a thought about the overall idea, I invite you to comment on Discourse; if you have a thought about GHC's response to this, this list seems like the best venue. Thanks, Richard

1 0

ZuriHac 2021 - GHC Track - Call for Contributions
by Andreas Herrmann 11 May '21

11 May '21

Dear GHC developers, This year's ZuriHac 2021 [1], online Friday 18th June to Sunday 20th June, will again feature a dedicated GHC track to foster contributions to GHC and teach newcomers how to participate in GHC's development. For that we need your help: We would like to invite you to organize a session in the GHC track. This could be in form of a presentation, a workshop, or a hack session with topics centered around GHC. For some inspiration, these are the subjects from last year's track: - Write a GHC extension in 30 minutes, by Richard Eisenberg - A tour of linear types and linear base, by Divesh Otwani - QualifiedDo: customizable 'do' syntax without fuss, by Facundo Dominguez - On "simple" constraints for typechecker plugins, by Nicolas Frisby Please let us know if you'd be interested in leading a session or a workshop. You can contact either Niklas or myself, on this list or by private message. Best, Andreas and Niklas ZuriHac 2021 GHC track coordinators [1]: https://zfoh.ch/zurihac2021/

2 2

Warnings
by Simon Peyton Jones 04 May '21

04 May '21

If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? Simon "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id transformers-0.5.6.2 -hide-all-packages -package-env - -i -ilibraries/transformers/. -ilibraries/transformers/dist-boot/build -Ilibraries/transformers/dist-boot/build -ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/dist-boot/build/./autogen -Ilibraries/transformers/. -optP-include -optPlibraries/transformers/dist-boot/build/./autogen/cabal_macros.h -package-id base-4.14.1.0 -XHaskell98 -no-user-package-db -rtsopts -fno-warn-unused-matches -fno-warn-unused-imports -fno-warn-deprecated-flags -outputdir libraries/transformers/dist-boot/build -c libraries/transformers/./Control/Applicative/Lift.hs -o libraries/transformers/dist-boot/build/Control/Applicative/Lift.o libraries/transformers/Control/Monad/Trans/Error.hs:98:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => Alternative (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 98 | instance (Error e) => Alternative (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... libraries/transformers/Control/Monad/Trans/Error.hs:103:1: warning: [-Worphans] Orphan instance: instance [safe] Error e => MonadPlus (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. | 103 | instance (Error e) => MonadPlus (Either e) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

2 1

structured error messages
by Richard Eisenberg 03 May '21

03 May '21

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=<filename> 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 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533>. Thanks! Richard

3 3

linting GHC
by Richard Eisenberg 01 May '21

01 May '21

Hi devs, I see in CI that we're now linting the GHC source code. In order to avoid CI failure, I would like to lint locally, and I somehow know (though I forget where I learned it) that hadrian/build lint:compiler is the way to do this. After building hlint, I am able to do this. But the output is surprising; here is the tail: # hlint (for lint:compiler) compiler/GHC/Tc/Utils/Unify.hs:2:1-36: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE MultiWayIf #-} Perhaps you should remove it. compiler/stage1/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE ViewPatterns #-} Perhaps you should remove it. compiler/stage1/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE LambdaCase #-} Perhaps you should remove it. compiler/stage1/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports Found: import Control.Monad ( unless, liftM, when, (<=<) ) import Control.Monad ( ap ) Perhaps: import Control.Monad ( unless, liftM, when, (<=<), ap ) compiler/stage1/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports Found: import GHC.Prelude import GHC.Prelude Perhaps: import GHC.Prelude compiler/stage1/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer imports Found: import GHC.StgToCmm.Prof import GHC.StgToCmm.Prof Perhaps: import GHC.StgToCmm.Prof compiler/stage1/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer imports Found: import Control.Monad import Control.Monad ( ap ) Perhaps: import Control.Monad compiler/stage2/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE ViewPatterns #-} Perhaps you should remove it. compiler/stage2/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE pragma Found: {-# LANGUAGE LambdaCase #-} Perhaps you should remove it. compiler/stage2/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports Found: import Control.Monad ( unless, liftM, when, (<=<) ) import Control.Monad ( ap ) Perhaps: import Control.Monad ( unless, liftM, when, (<=<), ap ) compiler/stage2/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports Found: import GHC.Prelude import GHC.Prelude Perhaps: import GHC.Prelude compiler/stage2/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer imports Found: import GHC.StgToCmm.Prof import GHC.StgToCmm.Prof Perhaps: import GHC.StgToCmm.Prof compiler/stage2/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer imports Found: import Control.Monad import Control.Monad ( ap ) Perhaps: import Control.Monad 13 hints Error when running Shake build system: at want, called at src/Main.hs:104:30 in main:Main * Depends on: lint:compiler at cmd_, called at src/Rules/Lint.hs:70:3 in main:Rules.Lint * Raised the exception: Development.Shake.cmd, system command failed Command line: hlint -j --cpp-define x86_64_HOST_ARCH --cpp-include=includes --cpp-include=_build/stage1/lib --cpp-include=compiler --cpp-include=_build/stage1/lib/ghcplatform.h --cpp-include=_build/stage1/compiler/build -h compiler/.hlint.yaml compiler Exit code: 1 Stderr: There are several curiosities here: * I introduced one of these errors, in GHC.Tc.Utils.Unify; the other errors are in files I have not modified. Will these affect CI? * Hadrian crashes at the end. Is that expected? It says "system command failed" with a bunch of gobbledegook. Is this an error within Hadrian? Or is this just Hadrian's way of saying that it encountered an error when linting? If it's the latter, the current message is hard to read. * As you may be able to see, I use a dark-background terminal window. The colors output by the hlint process are nigh impossible to read when describing redundant LANGUAGE pragmas. Are these colors configurable? Thanks! Richard

2 1