GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-02-06T23:54:14Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17797Lexer errors for newer unicode characters2020-02-06T23:54:14ZdminuosoLexer errors for newer unicode charactersIt appears that character from Unicode 6.0 and above lead to lexer errors.
```
unicode.hs:1:2: error: lexical error at character '\129315'
|
1 | (🤣) = ()
| ^
```It appears that character from Unicode 6.0 and above lead to lexer errors.
```
unicode.hs:1:2: error: lexical error at character '\129315'
|
1 | (🤣) = ()
| ^
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/17633Closed type family declaration accepts any name in LHS2020-01-03T21:33:08ZMaxim KoltsovClosed type family declaration accepts any name in LHS## Summary
Closed type family declaration will accept (almost) any name instead of family's name left of `=`.
## Steps to reproduce
```haskell
{-# LANGUAGE TypeFamilies #-}
module WTF where
type family Bar (a :: *) :: * where
Bar ...## Summary
Closed type family declaration will accept (almost) any name instead of family's name left of `=`.
## Steps to reproduce
```haskell
{-# LANGUAGE TypeFamilies #-}
module WTF where
type family Bar (a :: *) :: * where
Bar Int = ()
type family Foo (a :: *) :: * where
Bar Int = Bool
Bar Bool = Int
Bar a = a
```
When loaded to ghci, this file not only compiles, but works as if `Foo` were defined the normal way:
```
λ> :kind! Bar Int
Bar Int :: *
= ()
λ> :kind! Bar Bool
Bar Bool :: *
= Bar Bool
λ> :kind! Foo Int
Foo Int :: *
= Bool
λ> :kind! Foo Bool
Foo Bool :: *
= Int
λ> :kind! Foo Char
Foo Char :: *
= Char
```
It's clear that `Foo` is defined as it should be and that `Bar` is not broken by this definition.
## Expected behavior
GHC should emit an error in this case, as this code seems very strange.
Curiously, if `Bar` is not in scope GHC detects an error at `Foo`'s definition:
```
<interactive>:5:3: error:
Not in scope: type constructor or class ‘Bar’
```
Moreover, if I try to use some family from another module, it fails as well:
```
> import GHC.Generics
> :{
| type family Foo (a :: *) where
| Rep Bool = Maybe
| :}
<interactive>:6:3: error:
• Mismatched type name in type family instance.
Expected: Foo
Actual: Rep
```
## Environment
* GHC version used:
```console
$ stack exec -- ghc -V
The Glorious Glasgow Haskell Compilation System, version 8.6.3
```
* Operating System: macOS8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/17140Inifinite inlining loop2019-09-13T09:45:01ZSimon Peyton JonesInifinite inlining loopGanesh Sittampalam [reports](https://mail.haskell.org/pipermail/glasgow-haskell-users/2019-August/026866.html):
The code below (also attached - unzip and run go.sh) triggers the GHC panic "Simplifier ticks exhausted", and I'm unsure whe...Ganesh Sittampalam [reports](https://mail.haskell.org/pipermail/glasgow-haskell-users/2019-August/026866.html):
The code below (also attached - unzip and run go.sh) triggers the GHC panic "Simplifier ticks exhausted", and I'm unsure whether I should view it as an instance of the [known infelicity in the inliner](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#bugs-ghc)
My code does have a recursive datatype, but the recursion isn't contravariant, which is the case described in ["Secrets of the GHC inliner", Section 4](https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf).
It's cut down from some real code where I have a mutually recursive datatype that I want to define across two modules for code structuring reasons, meaning I need a .hs-boot file. I haven't been able to reproduce it without the .hs-boot file - if I put everything in one module it stops happening.
I've tried with a range of GHC versions from 8.2.x to an early version of 8.8. It happens with -O1 and not -O0, but I haven't managed to find a specific optimisation that triggers it.
Is this just an instance of the known problem in a different guise, or is it something different and worth a bug report?
Cheers,
Ganesh
```
T2.hs-boot
-----------
module T2 where
data T2
mapP_T2 :: (Int -> Int) -> T2 -> T2
T1.hs
-----
module T1 where
import {-# SOURCE #-} T2
data T1 = T1 T2
mapP_T1 :: (Int -> Int) -> T1 -> T1
mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)
T2.hs
-----
module T2 where
import T1
data T2 = T2 T1
mapP_T2 :: (Int -> Int) -> T2 -> T2
mapP_T2 f (T2 t) = T2 (mapP_T1 f t)
go :: T1 -> T1
go = mapP_T1 id
```
Here is the GHC output
```
$ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...]
ghc.exe: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
Simplifier ticks exhausted
When trying UnfoldingDone mapP_T2
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
Total ticks: 61203
24481 PreInlineUnconditionally
6121 ds_i17h
6120 f_a16p
6120 ds_d17d
6120 ds1_i17i
12241 UnfoldingDone
6121 mapP_T1
6120 mapP_T2
24481 BetaReduction
6121 ds_i17h
6120 f_a16p
6120 ds_d17d
6120 ds1_i17i
```8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17091GHC-8.8 branch has Cabal-3.0.0.0-rc3, not Cabal-3.0.0.02019-08-21T11:55:45ZOleg GrenrusGHC-8.8 branch has Cabal-3.0.0.0-rc3, not Cabal-3.0.0.0```
% git log Cabal-v3.0.0.0-rc3..Cabal-v3.0.0.0 --oneline
b0e52fa17 (tag: Cabal-v3.0.0.0, origin/3.0) Update AUTHORS. [ci skip]
e91d2ec50 Changelog update. [ci skip]
af7de53f3 Merge pull request #5451 from nh2/issue-4925-pass-ld-options...```
% git log Cabal-v3.0.0.0-rc3..Cabal-v3.0.0.0 --oneline
b0e52fa17 (tag: Cabal-v3.0.0.0, origin/3.0) Update AUTHORS. [ci skip]
e91d2ec50 Changelog update. [ci skip]
af7de53f3 Merge pull request #5451 from nh2/issue-4925-pass-ld-options-to-ghc
1b324a1df (3.0) Merge pull request #6174 from haskell/backports-ignore-msg-spdx
d7ff6d1b5 (origin/backports-ignore-msg-spdx, backports-ignore-msg-spdx) parser: Clearly state that invalid fields are ignored
f1911a662 Update to SPDX License List 3.6 2019-07-10
0a69501ca Changelog update.
3ede184e7 Merge pull request #6161 from haskell/gb/parse-config-multiline
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16990ghc-8.8.1 RC1 build no longer detects llc-7.02019-11-03T20:24:50ZJens Petersenghc-8.8.1 RC1 build no longer detects llc-7.0## Summary
Due to 71aca77c, llvm7.0 is no longer detected on Fedora.
I think a change was needed since Debian llvm-7 now ships `/usr/bin/llc-7` (compared to Fedora still providing `/usr/bin/llc-7.0`).
The problem is after the above fix I...## Summary
Due to 71aca77c, llvm7.0 is no longer detected on Fedora.
I think a change was needed since Debian llvm-7 now ships `/usr/bin/llc-7` (compared to Fedora still providing `/usr/bin/llc-7.0`).
The problem is after the above fix I think Debian now detects it's llc-7 correctly but now ghc needs to be patched to detect llc-7.0 on Fedora at least.
BTW It might be better to use `Data.Version` for `LlvmVersion`? Then it would be easy to `read` "7" or "7.0" etc (some distro or system could even have bindir/llc-7.1 or bindir/llc-7.0.1, etc).
(I kind of miss the old `--with-llc` (and `--with-opt`) configure options here - were they so bad? :slight_smile:)
## Steps to reproduce
Try to configure ghc-8.8.1 RC1 on Fedora ARM (32 or 64 bit) with llvm7.0
## Expected behavior
llc-7.0 and opt-7.0 to be detected like for the alpha releases.
## Actual behavior
llvm not detected.
## Environment
* GHC version used: 8.4.4
Optional:
* Operating System: Fedora
* System Architecture: armv7hl/aarch64
ps I worked around this for now with:
https://src.fedoraproject.org/rpms/ghc/blob/694ee07680e4618076b71efa4cc5279984c73e43/f/ghc-8.8-configure-llvm-7.0.patch
but we should really detect both llc-7 and llc-7.0 out of the box in my opinion.
I filed a [Fedora RFE](https://bugzilla.redhat.com/show_bug.cgi?id=1733421) asking if our llvm7.0 package can provide llc-7 and opt-7 symlinks but there may be other distros shipping llc-7.0. Hopefully in the future Fedora llvm8 package would provide llc-8...8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16968Packaging error: GHC 8.8.1-rc1 doesn't contain any source code2019-08-10T10:37:08Zofrytim4job@bmail.ruPackaging error: GHC 8.8.1-rc1 doesn't contain any source code## Summary
GHC 8.8.1-rc1 doesn't contain any source code
## Steps to reproduce
https://downloads.haskell.org/ghc/8.8.1-rc1/ghc-8.8.0.20190721-src.tar.xz doesn't contain any source.
## Expected behavior
There should be source code.
...## Summary
GHC 8.8.1-rc1 doesn't contain any source code
## Steps to reproduce
https://downloads.haskell.org/ghc/8.8.1-rc1/ghc-8.8.0.20190721-src.tar.xz doesn't contain any source.
## Expected behavior
There should be source code.
## Environment
* GHC version used: 8.8.1-rc1
Optional:
* Operating System:
* System Architecture:8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16964Documentation of RuntimeRep is wrong about 64-bit integer reps2022-02-12T03:28:41ZÖmer Sinan AğacanDocumentation of RuntimeRep is wrong about 64-bit integer repsDocumentation of `Int64Rep` and `Word64Rep` currently have the note "on 32-bit only" which seems wrong. Here's an example (this is on a 64-bit system):
```
~ $ cat Main.hs
{-# LANGUAGE TypeApplications, MagicHash #-}
import Type.Reflec...Documentation of `Int64Rep` and `Word64Rep` currently have the note "on 32-bit only" which seems wrong. Here's an example (this is on a 64-bit system):
```
~ $ cat Main.hs
{-# LANGUAGE TypeApplications, MagicHash #-}
import Type.Reflection
import GHC.Types
import GHC.Prim
import Data.Int
main = do
print (splitApps (typeRepKind (typeRep @Int64#)))
print (splitApps (typeRepKind (typeRep @Int#)))
~ $ ghc Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
~ $ ./Main
(TYPE,['Int64Rep])
(TYPE,['IntRep])
```
The documentation seems to suggest that `Int64Rep` should only be used on 32-bit systems, and we should get `IntRep` for `Int64#` on 64-bit.
[(Link to `RuntimeRep`)](https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#t:RuntimeRep)
(The same comments exist in GHC HEAD source tree too)
(cc @rae)8.8.1Carter SchonwaldJohn EricsonCarter Schonwaldhttps://gitlab.haskell.org/ghc/ghc/-/issues/16959Release tracking ticket for GHC 8.8.12022-02-11T16:59:45ZBen GamariRelease tracking ticket for GHC 8.8.1This is the release checklist for the %8.8.1 milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [x] Remove the release notes for the previous release (e.g. `docs/users_guide/8.6.*-notes.rst`)
*...This is the release checklist for the %8.8.1 milestone. See #16816 for the template that this was derived from.
# Pre-release checklist
* [x] Remove the release notes for the previous release (e.g. `docs/users_guide/8.6.*-notes.rst`)
* [x] Make release branch (e.g. `ghc-8.8`)
* [x] Make post-release branch (e.g. `ghc-8.9-start`)
* [x] Submodules on released tags:
* [x] `libraries/Cabal`: version 3.0.0.0 (on -rc3)
* [x] `libraries/Win32`: version 2.6.1.0
* [x] `libraries/binary`: version 0.8.7.0
* [x] `libraries/bytestring`: version 0.10.10.0
* [x] `libraries/containers`: version 0.6.2.1
* [x] `libraries/deepseq`: version 1.4.4.0 ([ ] revision pushed)
* [x] `libraries/directory`: version 1.3.3.2 ([ ] revision pushed)
* [x] `libraries/filepath`: version 1.4.2.1 ([ ] revision pushed)
* [x] `libraries/haskeline`: version 0.7.5.0 ([ ] revision pushed)
* [x] `libraries/mtl`: version 2.2.2
* [x] `libraries/parsec`: version 3.1.14.0 (on -rc)
* [x] `libraries/pretty`: version 1.1.3.6
* [x] `libraries/process`: version 1.6.5.1 ([x] tag pushed)
* [x] `libraries/terminfo`: version 0.4.1.4
* [x] `libraries/text`: version 1.2.4.0 (on -rc)
* [x] `libraries/time`: version 1.9.3
* [x] `libraries/transformers`: version 0.5.6.2
* [x] `libraries/unix`: version 2.7.2.2
* [x] `libraries/xhtml`: version 3000.2.2.1
* [ ] `utils/haddock`: version *todo*
* [ ] `utils/hsc2hs`: version *todo*
* Non-released submodules up-to-date:
* [x] `nofib`
* [x] `libffi-tarballs`
* [x] `libraries/integer-gmp/gmp/gmp-tarballs`
* [x] Release notes written
* [x] Release notes linked in `index.rst`
* [x] `autoconf` scripts [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [x] `LlvmVersion` in `configure.ac` is targetting intended LLVM version
* [x] Release notes mentions LLVM version requirement
* [x] `llvm-targets` file [updated](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#updating-the-tree)
* [x] Changelogs updated:
* [x] `libraries/ghc-prim`
* [x] `libraries/integer-gmp`
* [x] `libraries/integer-simple`
* [x] `libraries/hpc`
* [x] `libraries/base`: Version 4.13.0.0
* [x] `libraries/ghc-boot`
* [x] `libraries/ghc-boot-th`
* [x] Verify that the ~"backport needed" label has no more issues/merge requests needing backport
* [x] Verify that all CI builds are green before moving to *release checklist*
# Release checklist
* [x] [Make tag](https://gitlab.haskell.org/ghc/ghc/wikis/making-releases#tagging-the-release)
* [x] Wait until builds finish
* [x] Fetch release artifacts TODO: documentation
* [x] Sign and push release artifacts to `downloads.haskell.org` [TODO: documentation]
* [ ] Release/revise GHC-maintained libraries on Hackage [TODO: documentation]
* [ ] `libraries/base`
* [ ] `libraries/ghc-prim`
* [ ] `libraries/array`
* [ ] `libraries/stm`
* [ ] `libraries/ghc-heap`
* [ ] `libraries/ghc-compact`
* [ ] `libraries/ghc-boot`
* [ ] `libraries/ghc-boot-th`
* [ ] `libraries/hpc`
* [ ] `libraries/libiserv`
* [ ] `libraries/template-haskell`
* [ ] `libraries/integer-gmp`
* [ ] `libraries/integer-simple`
* [ ] Update ghc/homepage>:
* [x] Write download page (see ghc/homepage>)
* [x] Add news item to [`index.html`](https://gitlab.haskell.org/ghc/homepage/blob/master/index.shtml)
* [x] Add link to [`download.shtml`](https://gitlab.haskell.org/ghc/homepage/blob/master/download.shtml)
* [x] Look over changes locally
* [x] Add release announcement to [GHC blog](https://gitlab.haskell.org/ghc/homepage/tree/master/blog)
* [x] Push changes to `master`
* [x] Announce on: `GHC developers <ghc-devs@haskell.org>, GHC Users <glasgow-haskell-users@haskell.org>, Haskell Cafe <haskell-cafe@haskell.org>`
* [x] Announce on: [Haskell Discourse](https://discourse.haskell.org/), [/r/haskell](https://reddit.com/r/haskell), [Twitter](https://twitter.com/)
* [x] Update `latest` symlink on `downloads.haskell.org`
* [ ] Ensure that the [Migration](https://gitlab.haskell.org/ghc/ghc/wikis/migration/) page is up-to-date
# Post-release checklist
* [ ] Update the Wiki [status page](https://gitlab.haskell.org/ghc/ghc/wikis/status)
* [ ] Update the [language pragma history](https://gitlab.haskell.org/ghc/ghc/wikis/language-pragma-history)
* [ ] Mark milestone as *closed*
* [ ] Update the [VersionHistory](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/libraries/version-history) wiki page
* [ ] Set `RELEASE=NO`8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16939TemplateHaskell with StrictData and -funbox-strict-fields panics2019-07-14T10:09:05ZErik de Castro LopoTemplateHaskell with StrictData and -funbox-strict-fields panics## Summary
Compiler panics with the following trivial example.
## Steps to reproduce
Only required package is `vector-th-unbox` and code is:
```
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE StrictData #-}
{-# LANGUAGE Template...## Summary
Compiler panics with the following trivial example.
## Steps to reproduce
Only required package is `vector-th-unbox` and code is:
```
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE StrictData #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -funbox-strict-fields #-}
import Data.Vector.Unboxed.Deriving (derivingUnbox)
newtype X
= X { unX :: Word }
deriving (Eq, Ord, Show)
data Y = Y
{ yX :: X
, yD :: Double
} deriving (Eq, Show)
derivingUnbox "Y"
[t| Y -> (Word, Double) |]
[| \ y -> (unX (yX y), yD y) |]
[| \ (x, d) -> Y (X x) d |]
main :: IO ()
main = putStrLn "Hello!"
```
which results in:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
mkNewTyConRhs
MV_Y [Int#, MVector s_a5Mc[sk:1] Word, MVector s_a5Mc[sk:1] Double]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/iface/BuildTyCl.hs:65:27 in ghc:BuildTyCl
```
Removing the `StrictData` language pragma or the `-funbox-strict-fields` option allows this to compile.
## Expected behavior
This code should panic the compiler.
## Environment
* GHC version used: 8.6.5
Optional:
* Operating System: Linux
* System Architecture: x86_648.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16857clang should be used on OpenBSD2020-01-24T23:46:20Zrolandclang should be used on OpenBSD```shell
$ uname -sr
OpenBSD 6.4
$ export AUTOCONF_VERSION=2.69
$ export AUTOMAKE_VERSION=1.16...```shell
$ uname -sr
OpenBSD 6.4
$ export AUTOCONF_VERSION=2.69
$ export AUTOMAKE_VERSION=1.16
$ ./boot
$ ./configure
[...]
checking version of gcc... configure: error: Need at least gcc version 4.4 (4.7+ recommended)
```
Indeed OpenBSD's included gcc appears to be too old:
```shell
$ gcc --version
gcc (GCC) 4.2.1 20070719
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
But luckily it also ships with `clang`, which could be used instead:
```
$ clang --version
OpenBSD clang version 6.0.0 (tags/RELEASE_600/final) (based on LLVM 6.0.0)
Target: amd64-unknown-openbsd6.4
Thread model: posix
InstalledDir: /usr/bin
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16846RTS STM Segmentation fault on Linux/MacOS2020-05-29T05:40:02ZPhilip KamenarskyRTS STM Segmentation fault on Linux/MacOS# Summary
[stm-bug.tar.gz](/uploads/f391344d67b7de42182ba9cbe672b968/stm-bug.tar.gz)
Compiling and running the attached project segfaults on both Linux and MacOs on GHC 8.0 through 8.6. I tried minimising the code as much as possible, ...# Summary
[stm-bug.tar.gz](/uploads/f391344d67b7de42182ba9cbe672b968/stm-bug.tar.gz)
Compiling and running the attached project segfaults on both Linux and MacOs on GHC 8.0 through 8.6. I tried minimising the code as much as possible, but I've reached a point where even inlining terms masks the segfault. Also, not using STM `retry` masks the segfault. Also, the code has to be spread across two modules, the segfault doesn't occur if everything is in e.g. Main.hs.
Sometimes, the RTS manages to shut down before a hard crash, i.e.:
```
stm-bug-0.1.0.0: unregistering (local file changes: src/Lib.hs)
stm-bug-0.1.0.0: build (lib + exe)
Preprocessing library for stm-bug-0.1.0.0..
Building library for stm-bug-0.1.0.0..
[2 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/Lib.o )
Preprocessing executable 'stm-bug-exe' for stm-bug-0.1.0.0..
Building executable 'stm-bug-exe' for stm-bug-0.1.0.0..
[1 of 2] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/stm-bug-exe/stm-bug-exe-tmp/Main.o ) [Lib changed]
Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/stm-bug-exe/stm-bug-exe ...
stm-bug-0.1.0.0: copy/register
Installing library in /home/phil/Projects/stm-bug/.stack-work/install/x86_64-linux/lts-13.26/8.6.5/lib/x86_64-linux-ghc-8.6.5/stm-bug-0.1.0.0-FnTyJxtuwWMDN9Vt5S3LQp
Installing executable stm-bug-exe in /home/phil/Projects/stm-bug/.stack-work/install/x86_64-linux/lts-13.26/8.6.5/bin
Registering library for stm-bug-0.1.0.0..
stm-bug-exe: internal error: evacuate: strange closure type 9435472
(GHC version 8.6.5 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
Other error messages while isolating the test case where included references to `strange closure type 4325519`, `stg_ap_p_ret`, and `stg_END_STM_WATCH_QUEUE_closure`.
# Steps to reproduce
```
stack build && stack exec stm-bug-exe
```
# Expected behavior
Not segfault.
# Environment
* GHC version used: 8.0.* - 8.6.* (didn't test with 7.*)
* gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10), Apple LLVM version 10.0.0 (clang-1000.11.45.5)
# Optional:
* Operating System: Linux, MacOS, maybe Windows
* System Architecture:8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16842References to unloaded CAFs due to stale static flag field2019-06-26T17:46:37ZBen GamariReferences to unloaded CAFs due to stale static flag fieldThis issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (...This issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (which set the static link field to 3) and thus were ignored by GC. Because of that, during the next GC, checkUnload determined that these ObjectCode struct can be freed despite the references into those ObjectCodes still existing. Next GC cycle would trigger crash while GC is trying to evacuate the mentioned CAFs.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16832panic: getIdFromTrivialExpr | Type families, generics, fundeps2019-06-19T03:12:30ZSiddharthpanic: getIdFromTrivialExpr | Type families, generics, fundepsThis is on `GHCi, version 8.6.5`, in the file [`WorkingGenerics.hs`](https://github.com/bollu/paper-deltas/blob/master/src/WorkingGenerics.hs)
```
*Main> :load WorkingGenerics
[1 of 1] Compiling WorkingGenerics ( /home/bollu/work/pap...This is on `GHCi, version 8.6.5`, in the file [`WorkingGenerics.hs`](https://github.com/bollu/paper-deltas/blob/master/src/WorkingGenerics.hs)
```
*Main> :load WorkingGenerics
[1 of 1] Compiling WorkingGenerics ( /home/bollu/work/paper-deltas/src/WorkingGenerics.hs, interpreted )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-unknown-linux):
getIdFromTrivialExpr
(case a'_alGi of { })
`cast` (Sym (Nth:2
(Nth:3
(Inst (Sym (N:GDiff[0] (Rep_Void[0])) ; N:GDiff[0]
<Rep Void>_N) (Coh <Void>_N
(Sym (Nth:0
(Sym (N:GDiff[0]
(Rep_Void[0])) ; N:GDiff[0]
<Rep
Void>_N)))))))
:: Rep Void Void
~R# D1 ('MetaData "Void" "WorkingGenerics" "main" 'False) V1 Void)
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreUtils.hs:977:18 in ghc:CoreUtils
```
How to reproduce:
1. Clone [bollu/paper-deltas](https://github.com/bollu/paper-deltas/)
2. Run `stack ghci`
3. run `:load WorkingGenerics` in `GHCi`
I'm sorry, I have _no idea how to reduce_ this kind of bug.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16825[hadrian] stack dependencies build broken2019-08-10T10:43:49ZShayne Fletchershayne@shaynefletcher.org[hadrian] stack dependencies build brokenCommit `381c3ae31b68019177f1cd20cb4da2f9d3b7d6c6` "bump Cabal submodule" breaks the stack/hadrian build.
Steps to reproduce:
```bash
git clone https://gitlab.haskell.org/ghc/ghc.git
cd ghc
git submodule update --init --recursive
stack bu...Commit `381c3ae31b68019177f1cd20cb4da2f9d3b7d6c6` "bump Cabal submodule" breaks the stack/hadrian build.
Steps to reproduce:
```bash
git clone https://gitlab.haskell.org/ghc/ghc.git
cd ghc
git submodule update --init --recursive
stack build --stack-yaml=hadrian/stack.yaml --only-dependencies
```
The error produced reads:
```
Setup.lhs:48:22: error:
Variable not in scope:
rawSystemProgramConf
:: Distribution.Verbosity.Verbosity -> t -> ProgramDb -> t1
|
48 | let runProgram p = rawSystemProgramConf (fromFlagOrDefault normal (buildVerbosity flags))
| ^^^^^^^^^^^^^^^^^^^^
```8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16784PLT is mapped in too far from code2019-06-12T12:48:01ZBen GamariPLT is mapped in too far from codeThe procedure linkage table (PLT) is mapped too far from code on AArch64. This is the cause of #16776.
It should be using similar logic to that which is used on x86-64, where we take particular care to feed `mmap` an unmapped hint addre...The procedure linkage table (PLT) is mapped too far from code on AArch64. This is the cause of #16776.
It should be using similar logic to that which is used on x86-64, where we take particular care to feed `mmap` an unmapped hint address in the lower 2GB of address space.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16779elf_got remaps GOT region as read-only too early2019-06-12T12:45:24ZBen Gamarielf_got remaps GOT region as read-only too early67c422ca0e7b94e021430e3dfc9b19f3de21ed16 taught the linker to remap regions as read-only after linking where appropriate. However, it is a bit overzealous in the case of GOTs (as I originally noted in https://gitlab.haskell.org/ghc/ghc/i...67c422ca0e7b94e021430e3dfc9b19f3de21ed16 taught the linker to remap regions as read-only after linking where appropriate. However, it is a bit overzealous in the case of GOTs (as I originally noted in https://gitlab.haskell.org/ghc/ghc/issues/16776#note_204499). Specifically, `elf_got.c:makeGot` `mprotect`s the GOT region after partially filling it. However, `elf_got.c:fillGot` also needs to write to the GOT region and is called *after* the `mprotect`. Consequently we crash.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16751Cabal-3.0.0.0 breaks cabal012019-06-07T14:33:21ZBen GamariCabal-3.0.0.0 breaks cabal01When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16737cpp is not run when building .c or .cpp files2023-10-05T09:35:28ZZejun Wucpp is not run when building .c or .cpp files# Summary
C pre-processor is not run and `-D` or `-optP` flags are not respected when building `.c` or `.cpp` files.
# Steps to reproduce
```bash
$ cat test.c
#ifndef TEST
#define TEST 0
#endif
#include <stdio.h>
int main(void) {
pr...# Summary
C pre-processor is not run and `-D` or `-optP` flags are not respected when building `.c` or `.cpp` files.
# Steps to reproduce
```bash
$ cat test.c
#ifndef TEST
#define TEST 0
#endif
#include <stdio.h>
int main(void) {
printf("%d\n", TEST);
return 0;
}
$ ghc -DTEST=9 test.c -no-hs-main && ./a.out
0
```
or
```bash
$ mkdir -p x && touch x/x.h
$ echo '#include "x.h"' > y.c
$ ghc -Ix -c y.c
$ ghc -optP=-Ix -c y.c
y.c:1:10: error:
fatal error: x.h: No such file or directory
#include "x.h"
^~~~~
|
1 | #include "x.h"
| ^
compilation terminated.
`gcc' failed in phase `C Compiler'. (Exit code: 1)
```
# Expected behavior
Output `9` for the first example.
Both `ghc -Ix -c y.c` and `ghc -optP=-Ix -c y.c` work in the second example.
This is because we don't run cpp for `Cc`, `Ccxx`, `Cobjc` and `Cobjcxx` phase and we probably should do so.
For `HCc` phase, we usually run cpp in previous phase and probably don't want to run it again.8.8.1Zejun WuZejun Wuhttps://gitlab.haskell.org/ghc/ghc/-/issues/16690Update 8.8 libraries2019-07-20T02:56:47ZOleg GrenrusUpdate 8.8 librariesIn current 8.8 tip 334dd6da47326f47ba3425376728feda6245c7c1, these libraries don't point to a release tag (or old release):
- `binary`: currently at 0.8.6.0 + commits
- `bytestring` 13 commits since 0.10.8.2
- `containers` 10 commits sin...In current 8.8 tip 334dd6da47326f47ba3425376728feda6245c7c1, these libraries don't point to a release tag (or old release):
- `binary`: currently at 0.8.6.0 + commits
- `bytestring` 13 commits since 0.10.8.2
- `containers` 10 commits since 0.6.0.1
- `deepseq` 1 commit since 1.4.4.0
- `directory` 1 commit since 1.3.3.2
- `haskeline` 1 commit since 0.7.5.0
- `parallel`4 commits since 3.2.2.0
- `parsec` 6 commits since 3.1.13.0
- `process` 5 commits since 1.6.5.0
- `stm` 4 commits since 2.5.0.0
- `terminfo` points to commit which looks like `0.4.1.4` but isn't the actual tagged commit. https://github.com/judah/terminfo/issues/34
- `text` 4 commits since 1.2.3.1
- `time` is at 1.9.2, but there is 1.9.3
- `unix` 5 commits since 2.7.2.2
- And as a bonus `Cabal`, which is partly tracked by https://gitlab.haskell.org/ghc/ghc/issues/16637
IMHO it would be clearer if each boot library had a PATCH release, so `git submodule foreach git describe --always` would tell which versions are there. Currently some of the packages have some not-essential `.travis.yml` churn; some have a little of metadata change (e.g. relaxed base, time etc bounds), or actual unreleased changes (e.g. binary and text at least).
---
From https://gitlab.haskell.org/ghc/ghc/issues/16602
> In general, actionable things like bumping Cabal should have a ticket otherwise they are destined to fall through the cracks. It looks like in this case I failed to open one and no one else did so either.8.8.1Ben GamariHerbert Valerio Riedelhvr@gnu.orgBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16689Safe Haskell warnings don't recognize pragmas2019-07-07T18:00:05ZSamuel MaySafe Haskell warnings don't recognize pragmas# Summary
When compiled with `-Wsafe` or `-Wunsafe`, the warning will be printed whenever a module is inferred as either (untested, but that might be every module). This includes when an explicit safety annotation has been included in ...# Summary
When compiled with `-Wsafe` or `-Wunsafe`, the warning will be printed whenever a module is inferred as either (untested, but that might be every module). This includes when an explicit safety annotation has been included in the file, in which case the author can be presumed to know whether or not it's safe.
Glaringly, the warning message says "[the module] has been inferred as safe!" when it is actually *explicitly* safe, no inference necessary. While this is mostly just an annoyance, if `-Werror` is also passed, there is no way to actually make the compilation succeed.
# Steps to reproduce
Add either the `{-# LANGUAGE Safe #-}` or the `{-# LANGUAGE Unsafe #-}` pragma to any module according to its safety, and rebuild with `-Wsafe` or `-Wunsafe` passed to GHC.
# Expected behavior
Assuming the annotation is correct for the module, it should be compiled with no warnings (or at least no more than it does without the flag).
# Environment
* GHC version used: 8.6.48.8.1