Commit 56738617 authored by Ben Gamari's avatar Ben Gamari 🐢

Rewrite superfluous issue links

Many issues in the wiki were unnecessarily links:
```
... patch posted in [\#1346](ghc#1346).
```
This rewrites these as `#1346` using
```bash
sed -i -r -e 's/\[\\#([0-9]+)\]\([^)]+\/\1\)/#\1/g' $(find -iname '*.md')
```
And manually eyeballing the result.
parent 33352ae3
......@@ -36,7 +36,7 @@ These branches are not merged, but they are also not totally dead ended, and the
- `wip/nested-cpr`: **Nested CPR**. Works, but results where underwhelming. See [NestedCPR](nested-cpr). Joachim Breitner.
- `wip/cbv-conv-thunk`: **Opportunistic evaluation of thunks**. This is a side-line of `wip/nested-cpr`: Nested CPR requires a convergence analysis, and it might be worth evaluating them ([\#7596](https://gitlab.haskell.org/ghc/ghc/issues/7596)). Seems to be not as useful as hoped. Joachim Breitner.
- `wip/cbv-conv-thunk`: **Opportunistic evaluation of thunks**. This is a side-line of `wip/nested-cpr`: Nested CPR requires a convergence analysis, and it might be worth evaluating them (#7596). Seems to be not as useful as hoped. Joachim Breitner.
- `wip/common-context`: **Common context transformation** which can reduce code size and possibly produce more join points. See [NestedCPR](nested-cpr#common-context). Joachim Breitner.
......
# Overview
This page documents a proposed syntactical extension called `ArgumentDo`. The feature request is tracked at [\#10843](https://gitlab.haskell.org/ghc/ghc/issues/10843).
This page documents a proposed syntactical extension called `ArgumentDo`. The feature request is tracked at #10843.
......
......@@ -61,9 +61,9 @@ The path /usr/local/lib/hugs/packages is in fact where the Prelude lives, howeve
Anyone know what could be wrong here?
## New Update on [\#1346](https://gitlab.haskell.org/ghc/ghc/issues/1346)
## New Update on #1346
[\#1346](https://gitlab.haskell.org/ghc/ghc/issues/1346), the bug tracking having bootstrapping working again, has had its milestone changed from 6.10.1 to 6.12, as the build system overhaul has grown into too large of a project and 6.10 needs to be released before it will be completed.
#1346, the bug tracking having bootstrapping working again, has had its milestone changed from 6.10.1 to 6.12, as the build system overhaul has grown into too large of a project and 6.10 needs to be released before it will be completed.
......@@ -88,7 +88,7 @@ All developers, what ARM-based devices do you have available for testing?
### Another False Start
I had to install 6.6.1 on my system to compile 6.6.1, first off. Then I apparent need an older gcc (have 4.3.0). Rather than dive deeper into that (it would require an old gcc on the scratchbox dev environment too, too much pain when I have an alternative), I'm just going to try to build an unregisterised 6.8.2 with the patch posted in [\#1346](https://gitlab.haskell.org/ghc/ghc/issues/1346). The results for that build attempt follow, after the info for the failed 6.6.1 one.
I had to install 6.6.1 on my system to compile 6.6.1, first off. Then I apparent need an older gcc (have 4.3.0). Rather than dive deeper into that (it would require an old gcc on the scratchbox dev environment too, too much pain when I have an alternative), I'm just going to try to build an unregisterised 6.8.2 with the patch posted in #1346. The results for that build attempt follow, after the info for the failed 6.6.1 one.
### Original 6.6.1 Build Intro
......@@ -138,7 +138,7 @@ making it accept 5.10 too. Then I ran autoreconf, and ./configure ran to complet
## Third Unregistered Build - GHC 6.8.2
Using the patch posted at [\#1346](https://gitlab.haskell.org/ghc/ghc/issues/1346), I'm trying to build 6.8.2.
Using the patch posted at #1346, I'm trying to build 6.8.2.
### Target-side
......@@ -182,7 +182,7 @@ make: Leaving directory `/home/braden/ghc/ghc-6.8.2/libraries'
### Why it doesn't work
On discussion with Igloo (Ian Lynagh) on \#haskell, it turns out that hc-file bootstrapping has been broken in 6.8 since the beginning, meaning that only platforms with a working GHC prior to 6.8 can build a 6.8 or later. This undercuts the porting effort until [\#1346](https://gitlab.haskell.org/ghc/ghc/issues/1346) is fixed. I may try the "quick hack" diff attached to see if it works out. The comment from the user who posted it seems to imply that it's incomplete, though.
On discussion with Igloo (Ian Lynagh) on \#haskell, it turns out that hc-file bootstrapping has been broken in 6.8 since the beginning, meaning that only platforms with a working GHC prior to 6.8 can build a 6.8 or later. This undercuts the porting effort until #1346 is fixed. I may try the "quick hack" diff attached to see if it works out. The comment from the user who posted it seems to imply that it's incomplete, though.
### The original attempt
......
......@@ -8,7 +8,7 @@ Apart from the tickets below, there are a number of things that need doing
- There no single place that describes all the moving parts of the arrow implementation, including both the typechecking and desugaring rules -- and it's very hard to work it out from the code. Simply writing out the typechecking and desugaring rules, with some commentary, would be really helpful. There is a tiny start in `Note [Arrow overview]` in `TcArrows`.
- [\#13547](https://gitlab.haskell.org/ghc/ghc/issues/13547): work out if existential and GADT pattern matches are allowed. If so, fix the desugarer; if not, reject them with a decent error message, not a Core Lint crash.
- #13547: work out if existential and GADT pattern matches are allowed. If so, fix the desugarer; if not, reject them with a decent error message, not a Core Lint crash.
- See the discussion on this [Dec 16 ghc-devs thread](https://mail.haskell.org/pipermail/ghc-devs/2016-December/013317.html). It started with a desire to support rebindable syntax.
......
......@@ -72,7 +72,7 @@ real loop optimisations, described below.
We often see tail-recursive functions that include a heap or stack
check purely for the exit case of the loop. See [\#1498](https://gitlab.haskell.org/ghc/ghc/issues/1498). For example, if the
check purely for the exit case of the loop. See #1498. For example, if the
function looks something like this:
......@@ -124,7 +124,7 @@ GCC has a framework for gathering and using branch prediction information to imp
So the suggestion is that GHC could have a similar framework including explicit user annotations. It is believed that this could make a significant difference to the speed of some low level code like ByteString.
See ticket [\#849](https://gitlab.haskell.org/ghc/ghc/issues/849) for more details.
See ticket #849 for more details.
## Improving and refactoring the native code generator
......
......@@ -47,7 +47,7 @@ Some more out-of-date documents:
**Can I use this with the C preprocessor?** Yes; this used to be buggy but the fix is released in the latest version of GHC.
**Make sure cabal-version is recent enough.** ([\#4448](https://github.com/haskell/cabal/issues/4448)) If you set the `cabal-version` of your package too low, you may get this error:
**Make sure cabal-version is recent enough.** (#4448) If you set the `cabal-version` of your package too low, you may get this error:
```wiki
Error:
......
......@@ -20,7 +20,7 @@ In order to solve this problem a solution was proposed by Simon in [9122](https:
>
>
> I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught [\#9035](https://gitlab.haskell.org/ghc/ghc/issues/9035).
> I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught #9035.
>
>
......
......@@ -32,7 +32,7 @@ Things we'd likely want to change, though it wouldn't greatly matter if the old
## Typechecking
See [\#1537](https://gitlab.haskell.org/ghc/ghc/issues/1537) (do notation translation); make the obvious extensions to alternate base packages.
See #1537 (do notation translation); make the obvious extensions to alternate base packages.
## Derivings
......@@ -41,5 +41,5 @@ The derivings, as they are, clearly wouldn't work too well for changed classes.
## See Also
- [\#1580](https://gitlab.haskell.org/ghc/ghc/issues/1580) (our bug)
- #1580 (our bug)
- [PackageReorg: the base package](commentary/packages/package-reorg#the-base-package).
......@@ -162,7 +162,7 @@ instance Monoid MyType where
## Implementation
### Phase 1 (GHC 8.0) [\#10365](https://gitlab.haskell.org/ghc/ghc/issues/10365)
### Phase 1 (GHC 8.0) #10365
- Move `Data.Semigroup` & `Data.List.NonEmpty` from `semigroups-0.18` to `base`.
......
......@@ -4,7 +4,7 @@
For now, this page is focused on installing and using a stock x86 (i386) binary GHC distribution on x86_64 (amd64) Ubuntu computers. But, in principle, compiling for 32 bits on 64 bits should be possible on any architecture and OS that has multi-arch capabilities. The problems and workarounds may be similar, too (and similar to problems with cross-compilation). Please add your experience reports here. So far, this is known to work on Ubuntu precise, LTS 12.04.4, GHC 7.8.3, cabal 1.20.
Compiling i386 Haskell programs on a x86_64 system can be accomplished by building a proper [cross-compiler](cross-compilation). The method described below doesn't involve building GHC with different host and target, but does involve running a (stock binary distribution of) GHC with i386 target (and intended host) on a by-default x86_64 OS (the actual host). See [\#9421](https://gitlab.haskell.org/ghc/ghc/issues/9421) for context and common problems. Please report any new spotted problems there.
Compiling i386 Haskell programs on a x86_64 system can be accomplished by building a proper [cross-compiler](cross-compilation). The method described below doesn't involve building GHC with different host and target, but does involve running a (stock binary distribution of) GHC with i386 target (and intended host) on a by-default x86_64 OS (the actual host). See #9421 for context and common problems. Please report any new spotted problems there.
## Installing the i386 GHC
......
......@@ -12,7 +12,7 @@ This page describes how to do cross-compilation with GHC. That is:
- [TakeoffGW](http://takeoffgw.sourceforge.net/) is a distribution of Unix tools for Windows, built by cross-compiling on a Linux machine. They would like to be able to build and distribute GHC this way. It might be useful for us to be able to cross-compile a Windows GHC from Linux too.
- build a 64-bit GHC on OS X, by cross-compiling using the 32-bit version.
- We could port to Win64 ([\#1884](https://gitlab.haskell.org/ghc/ghc/issues/1884)) by cross-compiling using a 32-bit Windows GHC.
- We could port to Win64 (#1884) by cross-compiling using a 32-bit Windows GHC.
- Other porting tasks might be easier, given a suitable cross-compilation toolchain.
## Terminology and background
......
......@@ -240,7 +240,7 @@ Outstanding issues we should fix in rough priority order.
- Would be nice to not have to disable dead-code removal. (Simon Marlow says "we have special hacks so that you don't have to disable dead-code removal on OS X, in the native code generator and (I presume) in the LLVM backend. Perhaps this just needs to be adapted to work on iOS too?") (done by angerman, part of 7.10)
- Fix the copious link warnings
- Stop llvm generating an unnecessary 'bx lr' (return) instruction after the GHC calling convention (which is actually a goto)
- Programs outputting substantial text to the console can cause hangs in the RTS. (fixed by lukexi in ticket [\#8307](https://gitlab.haskell.org/ghc/ghc/issues/8307)).
- Programs outputting substantial text to the console can cause hangs in the RTS. (fixed by lukexi in ticket #8307).
## Wish List
......
......@@ -22,7 +22,7 @@ Requires small **gcc** patch to fix sdata overflow: [https://gcc.gnu.org/ml/gcc-
# 2010-2011 update
As of this time (2010-2011) some linux distros provides just GHC 6.8.2 build as binary package(s) on IA64 Itanium platform. To upgrade to GHC 7.x you will need to perform manual bootstrap of either GHC 6.10.x or GHC 6.12.x. The problem is that both show several critical issues which make them unbuildable or unstable. See [\#3891](https://gitlab.haskell.org/ghc/ghc/issues/3891) for example, although it's closed, it's not solved neither in 6.10.x nor in 6.12.x source tree.
As of this time (2010-2011) some linux distros provides just GHC 6.8.2 build as binary package(s) on IA64 Itanium platform. To upgrade to GHC 7.x you will need to perform manual bootstrap of either GHC 6.10.x or GHC 6.12.x. The problem is that both show several critical issues which make them unbuildable or unstable. See #3891 for example, although it's closed, it's not solved neither in 6.10.x nor in 6.12.x source tree.
As a solution, nice Gentoo Linux folks provide their own set of patches for IA64 GHC build and you can use them to compile either GHC 6.10.4 or GHC 6.12.3 on IA64 platform. Download and apply all **ghc-\<version\>-ia64\*patch** patches for your preferred GHC version from [here](http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/ghc/files/).
......
......@@ -116,7 +116,7 @@ Here is a random list of thoughts about things that are good to know when workin
- The GHC source code have an in-tree version of `libffi` and `gmp` which may work by accident -- especially if the version of `libgmp.so` and `libffi.so` matches the version installed by the ports. But using them is not recommended as they could result in various strange build and run-time errors. See the `configure` options to work around them.
- In an extremely high-speed environment it might happen that `gmake` restarts multiple times, c.f. [\#7592](https://gitlab.haskell.org/ghc/ghc/issues/7592). This is because timestamp precision for the VFS layer is set to a POSIX-friendly value by default. Adjusting the `vfs.timestamp_precision` sysctl(3) variable can help.
- In an extremely high-speed environment it might happen that `gmake` restarts multiple times, c.f. #7592. This is because timestamp precision for the VFS layer is set to a POSIX-friendly value by default. Adjusting the `vfs.timestamp_precision` sysctl(3) variable can help.
- Building GHC sources and Haskell sources in general could be sped up by setting up a [tmpfs(5)](http://www.freebsd.org/cgi/man.cgi?query=tmpfs&apropos=0&sektion=0&manpath=FreeBSD+9.1-stable&arch=default&format=html) partition. (This is not created by the default install.) Just replace the `/tmp` partition with a tmpfs-backed entry in `/etc/fstab`:
......
......@@ -56,7 +56,7 @@ Firstly, you need to install the Xcode Command Line tools from Apple. You can do
Get the most recent version of Apple's Xcode tools that you can. Your OS X CD has a version on it. You may be able to download a newer version from the [Apple Developer Connection](http://developer.apple.com/tools/xcode) website. You may need to sign up for a free membership in the Apple Developer Connection, and downloading may still cost a little money. In later versions of OS X (10.6 / 10.7), Apple added the "App Store". Xcode is available within the App Store for "Free".
Successful builds of older GHC sources have been reported using Xcode 3.0, 2.4 and 2.4.1 on Intel Macs. Xcode 2.2.1 is known *not* to work out of the box on Intel Macs, and Xcode 3.0 is known *not* to work out of the box on PowerPC Macs ([\#2887](https://gitlab.haskell.org/ghc/ghc/issues/2887)). Versions prior to 3.1 may build GHC successfully, but choke on certain libraries.
Successful builds of older GHC sources have been reported using Xcode 3.0, 2.4 and 2.4.1 on Intel Macs. Xcode 2.2.1 is known *not* to work out of the box on Intel Macs, and Xcode 3.0 is known *not* to work out of the box on PowerPC Macs (#2887). Versions prior to 3.1 may build GHC successfully, but choke on certain libraries.
## GHC
......@@ -100,7 +100,7 @@ to you `mk/build.mk` file (which hosts all your other build system config prefe
Running a command like `export MACOSX_DEPLOYMENT_TARGET=10.7` before building will imply setting `-mmacosx-version-min=version` for clang and friends, and will result in a GHC build that can run on any OS X `>= version` (where version can be older than the host machine's OS X version).
Note that this the deployment target does not affect library availability. This means that builds performed on Sierra (macOS 10.12) systems (which have `clock_gettime`), will be incompatible with previous OS X releases (see [\#12858](https://gitlab.haskell.org/ghc/ghc/issues/12858)). If you need to build a binary distribution on Sierra which is compatible with previous releases, it's best to simply disable `clock_gettime` support at configuration time, such as by setting the environment variables as follows
Note that this the deployment target does not affect library availability. This means that builds performed on Sierra (macOS 10.12) systems (which have `clock_gettime`), will be incompatible with previous OS X releases (see #12858). If you need to build a binary distribution on Sierra which is compatible with previous releases, it's best to simply disable `clock_gettime` support at configuration time, such as by setting the environment variables as follows
```wiki
export MACOSX_DEPLOYMENT_TARGET=10.7
......
......@@ -5,7 +5,7 @@
The NoFib benchmark suite is a collection of (mostly old) Haskell programs that we use for benchmarking GHC.
Trac [\#5793](https://gitlab.haskell.org/ghc/ghc/issues/5793) is about improving NoFib.
Trac #5793 is about improving NoFib.
## Prerequisites
......@@ -162,7 +162,7 @@ because those contain repeated patterns and aren't indicative of typical code.
### Stability wrt. GC paramerisations
Don't try to play around with large Gen 0 or Gen 1 heaps, they make benchmarks highly unstable wrt. small changes in allocations, caused by i.e. a new optimisation that you want to test, leading into a world of pain with unexplicable improvements and regressions. Benchmarks were carefully adjusted to show 'reasonable' behavior for such small changes (e.g. less allocations should lead to improvements in productivity). The details are in [\#15999](https://gitlab.haskell.org/ghc/ghc/issues/15999). This is also very important when adding new benchmarks.
Don't try to play around with large Gen 0 or Gen 1 heaps, they make benchmarks highly unstable wrt. small changes in allocations, caused by i.e. a new optimisation that you want to test, leading into a world of pain with unexplicable improvements and regressions. Benchmarks were carefully adjusted to show 'reasonable' behavior for such small changes (e.g. less allocations should lead to improvements in productivity). The details are in #15999. This is also very important when adding new benchmarks.
### Measuring backend performance
......
......@@ -7,7 +7,7 @@ This page is a working document to capture the ongoing work on migrating the cur
- [https://github.com/ndmitchell/shake/blob/master/docs/Manual.md\#readme](https://github.com/ndmitchell/shake/blob/master/docs/Manual.md#readme) (User manual)
Somewhat related, [\#5793](https://gitlab.haskell.org/ghc/ghc/issues/5793) suggests using `Shake` for `nofib`, and there's some code attached as well: [attachment:Main.2.hs:ticket:5793](/trac/ghc/attachment/ticket/5793/Main.2.hs)[](/trac/ghc/raw-attachment/ticket/5793/Main.2.hs)
Somewhat related, #5793 suggests using `Shake` for `nofib`, and there's some code attached as well: [attachment:Main.2.hs:ticket:5793](/trac/ghc/attachment/ticket/5793/Main.2.hs)[](/trac/ghc/raw-attachment/ticket/5793/Main.2.hs)
## The goal
......
......@@ -35,13 +35,13 @@ benl@greyarea:~/tmp$ ghc --make Main.hs
GCC version 4.3.x produces assembly files that GHC's "evil mangler" does not yet deal with.
GCC version 4.2.x works but takes hours and hours to build the large `.hc` files that GHC generates. It is reported ([\#1293](https://gitlab.haskell.org/ghc/ghc/issues/1293), [\#2906](https://gitlab.haskell.org/ghc/ghc/issues/2906)) that particular modules can take upwards of 5 hours and the overall build takes a couple days. This is due to complexity issues with respect to GCC moving to a unit-at-a-time compilation scheme instead of function-at-a-time.
GCC version 4.2.x works but takes hours and hours to build the large `.hc` files that GHC generates. It is reported (#1293, #2906) that particular modules can take upwards of 5 hours and the overall build takes a couple days. This is due to complexity issues with respect to GCC moving to a unit-at-a-time compilation scheme instead of function-at-a-time.
GCC version 4.0.2 does not support thread local state (TLS), at least on SPARC.
GCC version 3.4.x is reported ([\#951](https://gitlab.haskell.org/ghc/ghc/issues/951)) to mis-compile the runtime system leading to a runtime error `schedule: re-entered unsafely`.
GCC version 3.4.x is reported (#951) to mis-compile the runtime system leading to a runtime error `schedule: re-entered unsafely`.
But such a gcc version is sufficient for most user programs in case you just installed a ghc binary distribution.
### Using the wrong assembler
......
......@@ -36,7 +36,7 @@ then it could mean you have introduced a build system bug, causing an infinite l
This can also happen (although we don't know precisely why) if you modify something in a built tree, and then re-run `make`. In this case the error is just overly conservative, and restarting is the right workaround.
It can also happen if you are building the sources on FreeBSD in a really fast environment, e.g. on a multi-core Xeon with multiple parallel threads (`make -j`) or a memory-backed file system (`mfs`, `tmpfs`) (see [\#7592](https://gitlab.haskell.org/ghc/ghc/issues/7592)). It is because precision of file timestamps is not fine-grained enough by default (due to the common VFS layer). You can change this granularity by adjusting the value of the `vfs.timestamp_precision` sysctl(3) variable (`sudo sysctl -w vfs.timestamp_precision=1`).
It can also happen if you are building the sources on FreeBSD in a really fast environment, e.g. on a multi-core Xeon with multiple parallel threads (`make -j`) or a memory-backed file system (`mfs`, `tmpfs`) (see #7592). It is because precision of file timestamps is not fine-grained enough by default (due to the common VFS layer). You can change this granularity by adjusting the value of the `vfs.timestamp_precision` sysctl(3) variable (`sudo sysctl -w vfs.timestamp_precision=1`).
If you encounter this without touching any files after typing 'make', then it's probably a bug in the build system. The `make -d` output will be useful in tracking it down, but depending on when it happens there might be a lot of it!
......@@ -143,7 +143,7 @@ rm libraries/*/*/doc/*/*/*.haddock
### ar: Bad file number
**Fixed in 6.12.1**. See [\#3201](https://gitlab.haskell.org/ghc/ghc/issues/3201). Workaround: add `SplitObjs=NO` to `mk/build.mk`.
**Fixed in 6.12.1**. See #3201. Workaround: add `SplitObjs=NO` to `mk/build.mk`.
### chr: bad argument
......@@ -469,7 +469,7 @@ then you have probably not got `automake` installed (or at least findable).
Vista has a "feature" called "installer detection" which tries to elevate permissinos for executables named things like `Setup` and `Install`. There are lots of programs called `Setup` in a GHC build, and if you see permission-denied errors relating to programs called `Setup` you may need to disable installer detection. Go to `Start -> All Programs -> Accessories > Run` and enter `secpol.msc`. Then under `Security Settings -> Local Policies -> Security Options`, disable `UAC: Detect application installations and prompt for elevation`. Then reboot.
We added a workaround for install-detection in GHC 6.8.1 (see [\#1271](https://gitlab.haskell.org/ghc/ghc/issues/1271)), so if you're using that version or later you shouldn't encounter this issue.
We added a workaround for install-detection in GHC 6.8.1 (see #1271), so if you're using that version or later you shouldn't encounter this issue.
### Cygwin: failure to use native path to `gcc` when configuring
......
......@@ -2,7 +2,7 @@
This page describes language extension proposal to extend Haskell FFI with support for C structures.
See also the [\#9700](https://gitlab.haskell.org/ghc/ghc/issues/9700).
See also the #9700.
## The issue we are trying to solve
......
This page describes how GHC depends on and makes use of Cabal. It describes the situation
after the changes implemented in [\#8244](https://gitlab.haskell.org/ghc/ghc/issues/8244) are complete.
after the changes implemented in #8244 are complete.
## Design of GHC-library's non-dependency on Cabal
......@@ -166,7 +166,7 @@ It uses the class to convert to/from the on disk UTF8 representation, and the in
# History: Removal of the GHC library dependency on the Cabal library
See ticket [\#8244](https://gitlab.haskell.org/ghc/ghc/issues/8244)
See ticket #8244
The GHC library used to depend on the Cabal library directly, for the representation of installed packages. This was convenient for implementation but had a number of drawbacks:
......
......@@ -2,7 +2,7 @@
These are Joachim’s random scribblings in order to solve [\#9291](https://gitlab.haskell.org/ghc/ghc/issues/9291). This is wip, but of course if you want to comment on this, let me know.
These are Joachim’s random scribblings in order to solve #9291. This is wip, but of course if you want to comment on this, let me know.
## The problem
......
# Class Framework for Collections : Draft
This page describes a proposal for a class framework for collection types. Related ticket: [\#666](https://gitlab.haskell.org/ghc/ghc/issues/666)
This page describes a proposal for a class framework for collection types. Related ticket: #666
Please give feedback on libraries at haskell.org.
......
......@@ -69,7 +69,7 @@ See the [CollectionClassFramework](collection-class-framework) for details.
## Short terms plans
- Have a consistent performance checker. [\#676](https://gitlab.haskell.org/ghc/ghc/issues/676)
- Have a consistent performance checker. #676
......
......@@ -111,7 +111,7 @@ The above commentary covers the source code of GHC. For material that doesn't co
- Notes on implemented GHC features:
- [Evaluation order and state tokens](https://www.fpcomplete.com/tutorial-preview/4431/z0KpB0ai2R): notes written by Michael Snoyberg in response to [\#9390](https://gitlab.haskell.org/ghc/ghc/issues/9390).
- [Evaluation order and state tokens](https://www.fpcomplete.com/tutorial-preview/4431/z0KpB0ai2R): notes written by Michael Snoyberg in response to #9390.
- [Notes on fusion](foldr-build-notes) (eg foldr/build)
- [Overloaded list syntax](overloaded-lists) allows you to use list notation for things other than lists.
- [Kind polymorphism and data type promotion](ghc-kinds)
......@@ -145,9 +145,9 @@ The above commentary covers the source code of GHC. For material that doesn't co
- [Improving pattern-match overlap and exhaustiveness checks](pattern-match-check)
- [Source-locations on HsSyn](ghc-ast-annotations)
- [How GHC inter-operates with Cabal](cabal-dependency) and [Backpack](backpack)
- [StaticValues](static-values) and ticket [\#7015](https://gitlab.haskell.org/ghc/ghc/issues/7015)
- [Partial type signatures](partial-type-signatures) and its ticket [\#9478](https://gitlab.haskell.org/ghc/ghc/issues/9478)
- [Late lambda-lifting](late-lam-lift), and its ticket [\#9476](https://gitlab.haskell.org/ghc/ghc/issues/9476)
- [StaticValues](static-values) and ticket #7015
- [Partial type signatures](partial-type-signatures) and its ticket #9478
- [Late lambda-lifting](late-lam-lift), and its ticket #9476
- [Roles in Haskell](roles)
- [Dependent types in Haskell](dependent-haskell)
- [Nested CPR analysis](nested-cpr)
......
......@@ -26,11 +26,11 @@ Some higher level languages provide facilities to handle these exceptions, inclu
There has been at least one problem in GHC that would benefit from exception handling--in some cases, for `Integral`s. See bug ticket [\#1042](https://gitlab.haskell.org/ghc/ghc/issues/1042). The bug occurs in `show`ing the number, in \[GhcFile(libraries/base/GHC/Show.lhs) GHC.Show\], `showSignedInt`, before conversion from base_2 to base_10, where a negative `Int` (always `Int32`) is negated in order to process it as a positive value when converting it to a string, base_10, causing an overflow error on some architectures. (Bear in mind that it would show up here in the example for [\#1042](https://gitlab.haskell.org/ghc/ghc/issues/1042) because the function would be evaluated in GHCi here; the negation is the problem and the exception shows up in the *next* instruction on that operand, here `DIV`.)
There has been at least one problem in GHC that would benefit from exception handling--in some cases, for `Integral`s. See bug ticket #1042. The bug occurs in `show`ing the number, in \[GhcFile(libraries/base/GHC/Show.lhs) GHC.Show\], `showSignedInt`, before conversion from base_2 to base_10, where a negative `Int` (always `Int32`) is negated in order to process it as a positive value when converting it to a string, base_10, causing an overflow error on some architectures. (Bear in mind that it would show up here in the example for #1042 because the function would be evaluated in GHCi here; the negation is the problem and the exception shows up in the *next* instruction on that operand, here `DIV`.)
The exception example in [\#1042](https://gitlab.haskell.org/ghc/ghc/issues/1042) does not occur on PowerPC machines, which dutifully print the two's complement of `(-2147483648::Int) `div` (-1::Int)`: `0`. (`-2147483648` is the minimum bound for signed Ints, so negating it should properly become, bitwise, a positive `2147483647` (all but bit 31 set); once negated again when divided by `-1` this would be `0`; `-0` is converted to `0`.) On some architectures such as Intel 64 and IA-32, negating the minimum bound does not wrap around to `0` but overflows, which is reported as a floating point "overflow" (`#O`) exception: the `NEG` instruction modifies the `OF` flag (bit 11) in the `EFLAGS` register--curiously enough, the `DIV` and `IDIV` instructions have *undefined* effects on the `OF` flag.
The exception example in #1042 does not occur on PowerPC machines, which dutifully print the two's complement of `(-2147483648::Int) `div` (-1::Int)`: `0`. (`-2147483648` is the minimum bound for signed Ints, so negating it should properly become, bitwise, a positive `2147483647` (all but bit 31 set); once negated again when divided by `-1` this would be `0`; `-0` is converted to `0`.) On some architectures such as Intel 64 and IA-32, negating the minimum bound does not wrap around to `0` but overflows, which is reported as a floating point "overflow" (`#O`) exception: the `NEG` instruction modifies the `OF` flag (bit 11) in the `EFLAGS` register--curiously enough, the `DIV` and `IDIV` instructions have *undefined* effects on the `OF` flag.
......
......@@ -213,12 +213,12 @@ splitting the block, etc.
## Tuning LLVM IR Passes
The optimization pass sequence in LLVM is well tested for languages like C/C++, but not Haskell. See [\#11295](https://gitlab.haskell.org/ghc/ghc/issues/11295) for details and progress updates.
The optimization pass sequence in LLVM is well tested for languages like C/C++, but not Haskell. See #11295 for details and progress updates.
## Improving Heap Checks
See [\#8905](https://gitlab.haskell.org/ghc/ghc/issues/8905) and [\#12231](https://gitlab.haskell.org/ghc/ghc/issues/12231) and \[Compiling case expressions\] in StgCmmExpr
See #8905 and #12231 and \[Compiling case expressions\] in StgCmmExpr
---
......@@ -281,5 +281,5 @@ rightSide:
### Other Performance Bugs To Consider
- [\#12798](https://gitlab.haskell.org/ghc/ghc/issues/12798)
- [\#12808](https://gitlab.haskell.org/ghc/ghc/issues/12808)
- #12798
- #12808
......@@ -4,7 +4,7 @@
This page tracks the information and progress relevant to improving the alias analysis pass for the LLVM backend of GHC.
This correspond to bug [\#5567](https://gitlab.haskell.org/ghc/ghc/issues/5567).
This correspond to bug #5567.
## LLVM Alias Analysis Infrastructure
......@@ -180,7 +180,7 @@ As a quick experiment, I hacked LLVM to accept "safe" annotations on loads and t
### GHC Heap Check (case merging)
See bug [\#1498](https://gitlab.haskell.org/ghc/ghc/issues/1498)
See bug #1498
**Following is from Roman Leshchinskiy**
......
......@@ -8,9 +8,9 @@ However, there are a few ways that the LLVM backend needs to be improved before
1. Compilation speed. LLVM approximately doubles compilation time. Avoiding going via the textual intermediate syntax would probably help here.
1. Shared library support ([\#4210](https://gitlab.haskell.org/ghc/ghc/issues/4210), [\#5786](https://gitlab.haskell.org/ghc/ghc/issues/5786)). It works (or worked?) on a couple of platforms. But even on those platforms it generated worse code than the NCG due to using dynamic references for \*all\* symbols, whereas the NCG knows which symbols live in a separate package and need to use dynamic references.
1. Shared library support (#4210, #5786). It works (or worked?) on a couple of platforms. But even on those platforms it generated worse code than the NCG due to using dynamic references for \*all\* symbols, whereas the NCG knows which symbols live in a separate package and need to use dynamic references.
1. Some low-level optimisation problems ([\#4308](https://gitlab.haskell.org/ghc/ghc/issues/4308), [\#5567](https://gitlab.haskell.org/ghc/ghc/issues/5567)). The LLVM backend generates bad code for certain critical bits of the runtime, perhaps due to lack of good aliasing information. This hasn't been revisited in the light of the new codegen, so perhaps it's better now.
1. Some low-level optimisation problems (#4308, #5567). The LLVM backend generates bad code for certain critical bits of the runtime, perhaps due to lack of good aliasing information. This hasn't been revisited in the light of the new codegen, so perhaps it's better now.
Someone should benchmark the LLVM backend against the NCG with new codegen in GHC 7.8. It's possible that the new codegen is getting a slight boost because it doesn't have to split up proc points, so it can do better code generation for let-no-escapes. It's also possible that LLVM is being penalised a bit for the same reason.
......
......@@ -61,13 +61,13 @@ The core of the Cmm pipeline is implemented by the `cpsTop` function in [compile
- inlines assignments to registers that are mentioned only once
- discards dead assignments
**This pass is optional.** It currently does not eliminate dead code in loops (#8327) and has some other minor deficiencies (eg. [\#8336](https://gitlab.haskell.org//ghc/ghc/issues/8336)).
**This pass is optional.** It currently does not eliminate dead code in loops (#8327) and has some other minor deficiencies (eg. #8336).
- **CAF analysis**, implemented in `CmmBuildInfoTables`. Computed CAF information is returned from `cmmPipeline` and used to create Static Reference Tables (SRT). See [here](commentary/rts/storage/gc/CAFs) for some more detail on CAFs and SRTs. This pass is implemented using Hoopl (see below).
- **Proc-point analysis and splitting** (only when splitting proc-points), implemented by `procPointAnalysis` in `CmmProcPoint`, takes a list of proc-points and for each block and determines from which proc-point the block is reachable. This is implemented using Hoopl.
Then the call to `splitAtProcPoints` splits the Cmm graph into multiple Cmm graphs (each represents a single function) and build info tables to each of them.
When doing this we must be prepared for the fact that a proc-point does not actually exist in the graph since it was removed by stack layout pass (see [\#8205](https://gitlab.haskell.org//ghc/ghc/issues/8205)).
When doing this we must be prepared for the fact that a proc-point does not actually exist in the graph since it was removed by stack layout pass (see #8205).
- **Attach continuations' info tables** (only when NOT splitting proc-points), implemented by `attachContInfoTables` in `CmmProcPoint` attaches info tables for the continuations of calls in the graph. *\[PLEASE WRITE MORE IF YOU KNOW WHY THIS IS DONE\]*
......
......@@ -152,7 +152,7 @@ removes all such types from consideration.
```
In addition to `foldr`, `DeriveFoldable` also generates a definition for `foldMap` as of GHC 7.8.1 (addressing [\#7436](https://gitlab.haskell.org/ghc/ghc/issues/7436)). The pseudo-definition for `$(foldMap)` would look something like this:
In addition to `foldr`, `DeriveFoldable` also generates a definition for `foldMap` as of GHC 7.8.1 (addressing #7436). The pseudo-definition for `$(foldMap)` would look something like this:
```wiki
$(foldMap 'a 'b) = \x -> mempty -- when b does not contain a
......@@ -394,7 +394,7 @@ data HigherKinded f a where
In this example, the last type variable is instantiated with `f a`, which contains one type variable `f` applied to another type variable `a`. We would *not* fold over the argument of type `f a` in this case, because the last type variable should be *simple*, i.e., contain only a single variable without any application.
For the original discussion on this proposal, see [\#10447](https://gitlab.haskell.org/ghc/ghc/issues/10447).
For the original discussion on this proposal, see #10447.
## Alternative strategy for deriving `Foldable` and `Traversable`
......
......@@ -6,7 +6,7 @@ Deriving strategies grant users finer-grained control over how instances may be
## Motivation
GHC Trac [\#10598](https://gitlab.haskell.org//ghc/ghc/issues/10598) revealed a limitation of GHC's current instance deriving mechanism. Consider the following program which uses both `DeriveAnyClass` and `GeneralizedNewtypeDeriving`:
GHC Trac #10598 revealed a limitation of GHC's current instance deriving mechanism. Consider the following program which uses both `DeriveAnyClass` and `GeneralizedNewtypeDeriving`:
```haskell
{-# LANGUAGE DeriveAnyClass, GeneralizedNewtypeDeriving #-}
......@@ -198,12 +198,12 @@ newtype T = MkT S deriving (Foo, Bar)
This code compiles without issue, and uses `GeneralizedNewtypeDeriving` to derive `Foo` and `Bar` instances for `T`. But if you turn on `-XDerivingStrategies` as well, suddenly the above code will change in semantics: it will emit a warning about `GeneralizedNewtypeDeriving` and `DeriveAnyClass` both being on, and default to `DeriveAnyClass`! The intention of `-XDerivingStrategies` is to simply enable new syntactic forms that allow strictly more code to compile, and in particular, it is not intended to change the semantics of any existing code.
In addition, having `-XDerivingStrategies` imply `-XGeneralizedNewtypeDeriving` would have Safe Haskell repercussions, since one cannot currently use `-XSafe` in combination with `-XGeneralizedNewtypeDeriving` (see Trac [\#8827](https://gitlab.haskell.org//ghc/ghc/issues/8827)).
In addition, having `-XDerivingStrategies` imply `-XGeneralizedNewtypeDeriving` would have Safe Haskell repercussions, since one cannot currently use `-XSafe` in combination with `-XGeneralizedNewtypeDeriving` (see Trac #8827).
### Alternative syntax
Several alternative syntaxes and keyword suggestions have been proposed in the original track ticket ([\#10598](https://gitlab.haskell.org//ghc/ghc/issues/10598)) and on the ghc-devs mailing list ([https://mail.haskell.org/pipermail/ghc-devs/2016-July/012442.html](https://mail.haskell.org/pipermail/ghc-devs/2016-July/012442.html)). Here is an overview of some previous ideas:
Several alternative syntaxes and keyword suggestions have been proposed in the original track ticket (#10598) and on the ghc-devs mailing list ([https://mail.haskell.org/pipermail/ghc-devs/2016-July/012442.html](https://mail.haskell.org/pipermail/ghc-devs/2016-July/012442.html)). Here is an overview of some previous ideas:
- Use pragmas instead of keywords. We could indicate the use of deriving strategies like so:
......
......@@ -221,7 +221,7 @@ Notice that
The same thing happens with two mutually recursive methods
- BUT notice that we reconstruct the `(C [a])` dictionary on
each iteration of the loop. As Ganesh points out in [\#3073](https://gitlab.haskell.org/ghc/ghc/issues/3073), that
each iteration of the loop. As Ganesh points out in #3073, that
is sometimes bad.
## The out-of-line (B) strategy
......@@ -271,10 +271,10 @@ direct recursion.
Note also that
- Typechecking `opF_aux` is a bit fragile; see [\#3018](https://gitlab.haskell.org/ghc/ghc/issues/3018). Trouble is that
- Typechecking `opF_aux` is a bit fragile; see #3018. Trouble is that
when a constraint `(C [a])` arises in its RHS there are two ways
of discharging it: by using the argument `d_as` directly, or by
calling `(dCList d_a)`. As [\#3018](https://gitlab.haskell.org/ghc/ghc/issues/3018) shows, it's hard to guarantee that
calling `(dCList d_a)`. As #3018 shows, it's hard to guarantee that
we'll do the former.
## User INLINE pragmas and out-of-line (A)
......
# FFI Exports
On this page I've collected some information about how we handle FFI exports which I found while working on [\#15808](https://gitlab.haskell.org/ghc/ghc/issues/15808).
On this page I've collected some information about how we handle FFI exports which I found while working on #15808.
It's incomplete but should hopefully make the journey less painful for these who follow my footsteps.
......
......@@ -748,7 +748,7 @@ data MyDatatype = .... deriving (Generic, GBinary)
Ultimately, this might even allow us to replace the generated code by classes such as `Eq`, `Ord`, etc. with plain generic code.
The ticket for this request is [\#5462](https://gitlab.haskell.org/ghc/ghc/issues/5462). We refer to this new feature as `DeriveAnyClass`.
The ticket for this request is #5462. We refer to this new feature as `DeriveAnyClass`.
## Which classes can be derived?
......@@ -1059,7 +1059,7 @@ instance Generic IntHash where
# Compilation performance tricks
Unfortunately, deriving `Generic` has been known to incur large compilation times. It is suspected that deriving `Generic` has both nonlinear behavior as well as a large constant overhead (see [\#5642](https://gitlab.haskell.org/ghc/ghc/issues/5642) for further discussion). This section discusses some of the tricks GHC developers have used to make deriving `Generic` faster.
Unfortunately, deriving `Generic` has been known to incur large compilation times. It is suspected that deriving `Generic` has both nonlinear behavior as well as a large constant overhead (see #5642 for further discussion). This section discusses some of the tricks GHC developers have used to make deriving `Generic` faster.
## Factoring out `M1`
......
......@@ -10,10 +10,10 @@ Here is a summary of relevant links and tickets
- Tickets:
- [\#8285](https://gitlab.haskell.org/ghc/ghc/issues/8285)
- [\#8793](https://gitlab.haskell.org/ghc/ghc/issues/8793), [\#11372](https://gitlab.haskell.org/ghc/ghc/issues/11372); see comment 15 of [\#8793](https://gitlab.haskell.org/ghc/ghc/issues/8793)) etc, where it seems that we are missing loopification for a simple IO function
- [\#8585](https://gitlab.haskell.org/ghc/ghc/issues/8585) concerned getting the loop to start *after* the stack check
- [\#13567](https://gitlab.haskell.org/ghc/ghc/issues/13567): Do loopification using join points
- #8285
- #8793, #11372; see comment 15 of #8793) etc, where it seems that we are missing loopification for a simple IO function
- #8585 concerned getting the loop to start *after* the stack check
- #13567: Do loopification using join points
## Current implementation (Apr 17)
......
......@@ -10,14 +10,14 @@ This page summarises work that Norman Ramsey, Simon M, Simon PJ, and John Dias a