- ghc-devs - Haskell.org

Shadowing in toIface* output
by ÉRDI Gergő 04 Apr '22

04 Apr '22

Hi, I'm trying to save (Prep'd) Core bindings right next to the serialized `ModIface` (so basically `put_`ing them into the same bytestream, after the `ModIface`), and that's exactly what the functions in `GHC.CoreToIface` seem to be for, so I expected it to Just Work. However, I noticed that I very frequently get problems with shadowing. For example, Core that looks like `\v{u1} v{u2} -> v{u1}` would get translated to `\v v -> v`, which is disastrous since these locally bound `Var`s are represented as just their `getOccFS` (i.e. the `FastString` `"v"`). But this can't be right: if `toIfaceExpr` &c. would fail this blatently, then the unfoldings couldn't be saved & restored, which is something GHC itself does as part of normal `.hi` file handling. So clearly I must be doing something wrong. So I guess my question could be, what could be causing `toIfaceExpr` (a pure function!) to behave this way for my Cores? But then, if I look at the implementation of `toIface*`, I can see that it really doesn't do anything smarter than just storing `getOccFS` in the interface (no uniques in sight)-- so maybe my *real* question is, what is GHC itself doing so that it doesn't have this same problem? Thanks, Gergo

5 5

Windows CI instability
by Matthew Pickering 01 Apr '22

01 Apr '22

Hi all, Currently the windows CI issue is experiencing high amounts of instability so if your patch fails for this reason then don't worry. We are attempting to fix it. Cheers, Matt

1 0

devel2 build flavour thoughts
by Matthew Pickering 31 Mar '22

31 Mar '22

Hi all, In semi-private I have been making very bold claims about the unsuitability of the devel2 as a build flavour of choice for the aspiring developer. In order to bolster my claim I set out to find out some statistics about 1. devel2 flavour 2. default+no_profiled_libs+omit_pragmas+assertions flavour The difference between the two is essentially that flavour (2) builds each module with optimisation but disables cross-module optimisation (in particular inlining) In short the difference between the two flavours is negligible from my testing apart from one larger difference when building larger packages. Full build + test: Near identical Testsuite run: Near identical Recompile: Near identical - (2) is slower Build Cabal: 167s vs 259s So if you want to build packages use flavour 2 but otherwise it seems to make little difference. Cheers, Matt

2 1

question about mapSuccessors in GHC.Cmm.Node
by Norman Ramsey 29 Mar '22

29 Mar '22

Does anyone know why the continuations of CmmCall and CmmForeignCall are not considered successors for the purpose of `mapSuccessors`? Norman

1 0

safe maps within GHC?
by Norman Ramsey 28 Mar '22

28 Mar '22

A blog post of lexi-lambda's recently put me onto Matt Noonan's technique "Ghosts of Departed Proofs" [1], which appeared in the 2018 Haskell Symposium. One example that intrigued me was a safe `Map`, which uses the type system to guarantee that lookup does not fail. Maps are used pretty extensively in Cmm-land; for example, I recently have been using them to get information like the dominator set or the reverse postorder number of every node in a `CmmGraph`. In these maps, every `Label` that appears in the `CmmGraph` is expected to have an entry. For the moment, I am just using the standard lookup function; if an entry should be missing, my code calls `panic`. The idea of eliminating these calls and getting compile-time type safety is intriguing, but I'm not sure the game is worth the candle. What do other GHC devs think? Norman [1] https://iohk.io/en/research/library/papers/ghosts-of-departed-proofsfunctio…

3 3

Call for Talks: Haskell Implementors' Workshop 2022
by Alejandro Serrano Mena 23 Mar '22

23 Mar '22

(apologies for multiple copies of this message) ACM SIGPLAN Haskell Implementors' Workshop https://icfp22.sigplan.org/home/hiw-2022 Ljubljana, Slovenia, 11 September 2022 Co-located with ICFP 2022 https://icfp22.sigplan.org/ Important dates --------------- Deadline: 11 July, 2022 (AoE) Notification: 11 August, 2022 Workshop: 11 September, 2022 The 14th Haskell Implementors' Workshop is to be held alongside ICFP 2022 this year in Ljubljana. 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 2022. 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 can be made via HotCRP at https://icfphiw22.hotcrp.com until July 11th (anywhere on earth). 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. Program Committee ----------------- * Pepe Iborra (Meta) * Gabrielle Keller (Utrecht University) * Emily Pilmore (Kadena) * Vladislav Zavialov (Serokell) * Alejandro Serrano (Tweag) Contact ------- * Alejandro Serrano <trupill at gmail.com>

1 0

Wiki page for WebAssembly support in GHC
by Cheng Shao 03 Mar '22

03 Mar '22

Hi all, We're planning to add WebAssembly support to GHC. This work will be delivered by me and Norman Ramsey, the former Asterius team at Tweag. In the past few months, we did a strategic shift and focused on growing GHC towards Asterius, leveraging existing RTS as much as possible. We've made decent progress since then, and we expect to target 9.6 release much like GHCJS. We've created the https://gitlab.haskell.org/ghc/ghc/-/wikis/WebAssembly-backend wiki page, as a central point for communication. You're welcome to take a look and ask questions (either in this thread or editing that page in place), we'll answer the questions in the FAQ section. Cheers, Cheng

2 1

9.4 release planning (& GHCJS merge process)
by Matthew Pickering 24 Feb '22

24 Feb '22

Hi all, Firstly we are anticipating branching 9.4 in about 6 weeks time (approx start of April). Most of the major features originally milestoned[1] for this release have landed and the main branch is currently in a nice state. This timeline will be solidified once the 9.2.2 release has been completed. The major outstanding work that I am aware of is Windows toolchain work (#21019) (Ben Gamari) Partial Register Stall (#20405) (Andreas Klebinger) hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) Directed Coercions (!6476) (Sam Derbyshire) Secondly, we are anticipating adding a javascript backend inspired by GHCJS as the highlight of the 9.6 release. This work is led by the team at IOHK. * The planning and progress of this process is tracked on this wiki page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend * We anticipate reviewing and merging patches incrementally into a feature branch until the point where test coverage is suitable and the patches can be merged into the main branch. Cheers, Matt [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370

3 6

Well-Typed GHC team update
by Matthew Pickering 23 Feb '22

23 Feb '22

Hi all, We have recently reorganised the structure of the Well-Typed team working on the GHC project. In short, I am now responsible for more of the management tasks that Ben has traditionally carried out. In particular I have responsibility for organising the work between us and keeping track of the tasks that need to be completed. With that in mind, if you need something doing, please email/ping me and not Ben with your request and I will make sure someone deals with it. On gitlab you can also notify me directly by using the @hq-shepard tag, which provides the level of indirection for when this changes again in the future. The team working at Well-Typed on GHC currently consists of Myself (Matthew Pickering) Ben Gamari Andreas Klebinger Sam Derbyshire Zubin Duggal Cheers, Matt

3 2

struggling to get master to build
by Norman Ramsey 18 Feb '22

18 Feb '22

I recently pulled to bring my local copy of GHC HEAD up to 67dd5724297094af93be1887ef000845722c6f2b. But I cannot seem to get it to build. I'm following these steps: git pull --ff-only --prune --recurse-submodules --force rm -r _build ./boot ./configure ./hadrian build -j The build is failing with this error message: Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o >>> referenced by _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o:(.text+0x50) collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) Command failed Build failed. The offending command is very long indeed; it is appended to this message. What am I doing wrong, and what do I need to change? Norman Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf thr_dyn_hi -osuf thr_dyn_o -hcsuf thr_dyn_hc -fPIC -dynamic -optc-DTHREADED_RTS -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/nr/asterius/ghc/_build/stage1/rts/build -i/home/nr/asterius/ghc/_build/stage1/rts/build/autogen -i/home/nr/asterius/ghc/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -dynamic -shared -dynload deploy -optl-Wl,-rpath,$ORIGIN -optl-Wl,-zorigin -fno-use-rpaths -no-auto-link-packages -rtsopts -lc -lm -lrt -ldl -lpthread -lnuma -L_build/stage1/rts/build -lffi -Wnoncanonical-monad-instances -optc-Wno-error=inline -optP-Wno-nonportable-include-path _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o _build/stage1/rts/build/c/Adjustor.thr_dyn_o _build/stage1/rts/build/c/adjustor/AdjustorPool.thr_dyn_o _build/stage1/rts/build/c/ExecPage.thr_dyn_o _build/stage1/rts/build/c/Arena.thr_dyn_o _build/stage1/rts/build/c/Capability.thr_dyn_o _build/stage1/rts/build/c/CheckUnload.thr_dyn_o _build/stage1/rts/build/c/CloneStack.thr_dyn_o _build/stage1/rts/build/c/ClosureFlags.thr_dyn_o _build/stage1/rts/build/c/ClosureSize.thr_dyn_o _build/stage1/rts/build/c/Disassembler.thr_dyn_o _build/stage1/rts/build/c/FileLock.thr_dyn_o _build/stage1/rts/build/c/ForeignExports.thr_dyn_o _build/stage1/rts/build/c/Globals.thr_dyn_o _build/stage1/rts/build/c/Hash.thr_dyn_o _build/stage1/rts/build/c/Heap.thr_dyn_o _build/stage1/rts/build/c/Hpc.thr_dyn_o _build/stage1/rts/build/c/HsFFI.thr_dyn_o _build/stage1/rts/build/c/Inlines.thr_dyn_o _build/stage1/rts/build/c/Interpreter.thr_dyn_o _build/stage1/rts/build/c/IOManager.thr_dyn_o _build/stage1/rts/build/c/LdvProfile.thr_dyn_o _build/stage1/rts/build/c/Libdw.thr_dyn_o _build/stage1/rts/build/c/LibdwPool.thr_dyn_o _build/stage1/rts/build/c/Linker.thr_dyn_o _build/stage1/rts/build/c/ReportMemoryMap.thr_dyn_o _build/stage1/rts/build/c/Messages.thr_dyn_o _build/stage1/rts/build/c/OldARMAtomic.thr_dyn_o _build/stage1/rts/build/c/PathUtils.thr_dyn_o _build/stage1/rts/build/c/Pool.thr_dyn_o _build/stage1/rts/build/c/Printer.thr_dyn_o _build/stage1/rts/build/c/ProfHeap.thr_dyn_o _build/stage1/rts/build/c/ProfilerReport.thr_dyn_o _build/stage1/rts/build/c/ProfilerReportJson.thr_dyn_o _build/stage1/rts/build/c/Profiling.thr_dyn_o _build/stage1/rts/build/c/IPE.thr_dyn_o _build/stage1/rts/build/c/Proftimer.thr_dyn_o _build/stage1/rts/build/c/RaiseAsync.thr_dyn_o _build/stage1/rts/build/c/RetainerProfile.thr_dyn_o _build/stage1/rts/build/c/RetainerSet.thr_dyn_o _build/stage1/rts/build/c/RtsAPI.thr_dyn_o _build/stage1/rts/build/c/RtsDllMain.thr_dyn_o _build/stage1/rts/build/c/RtsFlags.thr_dyn_o _build/stage1/rts/build/c/RtsMain.thr_dyn_o _build/stage1/rts/build/c/RtsMessages.thr_dyn_o _build/stage1/rts/build/c/RtsStartup.thr_dyn_o _build/stage1/rts/build/c/RtsSymbolInfo.thr_dyn_o _build/stage1/rts/build/c/RtsSymbols.thr_dyn_o _build/stage1/rts/build/c/RtsUtils.thr_dyn_o _build/stage1/rts/build/c/STM.thr_dyn_o _build/stage1/rts/build/c/Schedule.thr_dyn_o _build/stage1/rts/build/c/Sparks.thr_dyn_o _build/stage1/rts/build/c/SpinLock.thr_dyn_o _build/stage1/rts/build/c/StableName.thr_dyn_o _build/stage1/rts/build/c/StablePtr.thr_dyn_o _build/stage1/rts/build/c/StaticPtrTable.thr_dyn_o _build/stage1/rts/build/c/Stats.thr_dyn_o _build/stage1/rts/build/c/StgCRun.thr_dyn_o _build/stage1/rts/build/c/StgPrimFloat.thr_dyn_o _build/stage1/rts/build/c/Task.thr_dyn_o _build/stage1/rts/build/c/ThreadLabels.thr_dyn_o _build/stage1/rts/build/c/ThreadPaused.thr_dyn_o _build/stage1/rts/build/c/Threads.thr_dyn_o _build/stage1/rts/build/c/Ticky.thr_dyn_o _build/stage1/rts/build/c/Timer.thr_dyn_o _build/stage1/rts/build/c/TopHandler.thr_dyn_o _build/stage1/rts/build/c/Trace.thr_dyn_o _build/stage1/rts/build/c/TraverseHeap.thr_dyn_o _build/stage1/rts/build/c/TraverseHeapTest.thr_dyn_o _build/stage1/rts/build/c/WSDeque.thr_dyn_o _build/stage1/rts/build/c/Weak.thr_dyn_o _build/stage1/rts/build/c/eventlog/EventLog.thr_dyn_o _build/stage1/rts/build/c/eventlog/EventLogWriter.thr_dyn_o _build/stage1/rts/build/c/hooks/FlagDefaults.thr_dyn_o _build/stage1/rts/build/c/hooks/LongGCSync.thr_dyn_o _build/stage1/rts/build/c/hooks/MallocFail.thr_dyn_o _build/stage1/rts/build/c/hooks/OnExit.thr_dyn_o _build/stage1/rts/build/c/hooks/OutOfHeap.thr_dyn_o _build/stage1/rts/build/c/hooks/StackOverflow.thr_dyn_o _build/stage1/rts/build/c/linker/CacheFlush.thr_dyn_o _build/stage1/rts/build/c/linker/Elf.thr_dyn_o _build/stage1/rts/build/c/linker/LoadArchive.thr_dyn_o _build/stage1/rts/build/c/linker/M32Alloc.thr_dyn_o _build/stage1/rts/build/c/linker/MMap.thr_dyn_o _build/stage1/rts/build/c/linker/MachO.thr_dyn_o _build/stage1/rts/build/c/linker/macho/plt.thr_dyn_o _build/stage1/rts/build/c/linker/macho/plt_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/PEi386.thr_dyn_o _build/stage1/rts/build/c/linker/SymbolExtras.thr_dyn_o _build/stage1/rts/build/c/linker/elf_got.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt_arm.thr_dyn_o _build/stage1/rts/build/c/linker/elf_reloc.thr_dyn_o _build/stage1/rts/build/c/linker/elf_reloc_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/elf_tlsgd.thr_dyn_o _build/stage1/rts/build/c/linker/elf_util.thr_dyn_o _build/stage1/rts/build/c/sm/BlockAlloc.thr_dyn_o _build/stage1/rts/build/c/sm/CNF.thr_dyn_o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o _build/stage1/rts/build/c/sm/Evac.thr_dyn_o _build/stage1/rts/build/c/sm/Evac_thr.thr_dyn_o _build/stage1/rts/build/c/sm/GC.thr_dyn_o _build/stage1/rts/build/c/sm/GCAux.thr_dyn_o _build/stage1/rts/build/c/sm/GCUtils.thr_dyn_o _build/stage1/rts/build/c/sm/MBlock.thr_dyn_o _build/stage1/rts/build/c/sm/MarkWeak.thr_dyn_o _build/stage1/rts/build/c/sm/NonMoving.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingCensus.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingMark.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingScav.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingShortcut.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingSweep.thr_dyn_o _build/stage1/rts/build/c/sm/Sanity.thr_dyn_o _build/stage1/rts/build/c/sm/Scav.thr_dyn_o _build/stage1/rts/build/c/sm/Scav_thr.thr_dyn_o _build/stage1/rts/build/c/sm/Storage.thr_dyn_o _build/stage1/rts/build/c/sm/Sweep.thr_dyn_o _build/stage1/rts/build/c/fs.thr_dyn_o _build/stage1/rts/build/c/adjustor/NativeAmd64.thr_dyn_o _build/stage1/rts/build/c/posix/GetEnv.thr_dyn_o _build/stage1/rts/build/c/posix/GetTime.thr_dyn_o _build/stage1/rts/build/c/posix/Ticker.thr_dyn_o _build/stage1/rts/build/c/posix/OSMem.thr_dyn_o _build/stage1/rts/build/c/posix/OSThreads.thr_dyn_o _build/stage1/rts/build/c/posix/Select.thr_dyn_o _build/stage1/rts/build/c/posix/Signals.thr_dyn_o _build/stage1/rts/build/c/posix/TTY.thr_dyn_o _build/stage1/rts/build/cmm/Apply.thr_dyn_o _build/stage1/rts/build/cmm/Compact.thr_dyn_o _build/stage1/rts/build/cmm/Exception.thr_dyn_o _build/stage1/rts/build/cmm/HeapStackCheck.thr_dyn_o _build/stage1/rts/build/cmm/PrimOps.thr_dyn_o _build/stage1/rts/build/cmm/StgMiscClosures.thr_dyn_o _build/stage1/rts/build/cmm/StgStartup.thr_dyn_o _build/stage1/rts/build/cmm/StgStdThunks.thr_dyn_o _build/stage1/rts/build/cmm/Updates.thr_dyn_o _build/stage1/rts/build/cmm/AutoApply.thr_dyn_o -o _build/stage1/rts/build/libHSrts-1.0.2_thr-ghc9.3.20220217.so -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db -package-db=/home/nr/asterius/ghc/_build/stage1/lib/package.conf.d -ghcversion-file=rts/include/ghcversion.h -haddock -Irts -I_build/stage1/rts/build '-DRtsWay="rts_thr_dyn"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1

2 3