GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-02-08T13:45:05Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/178958.8.3 release build on osx incorrectly configured? (missing ac_cv_func_cl...2023-02-08T13:45:05ZCarter Schonwald8.8.3 release build on osx incorrectly configured? (missing ac_cv_func_clock_gettime=no ?)## Summary
oleg (@phadej) reports that he's seeing
```
Undefined symbols for architecture x86_64:
"_utimensat", referenced from:
_LcaBW_info in libHSdirectory-1.3.6.0.a(Posix.o)
```
on a pre `10.13` OSX.
would this be due to ...## Summary
oleg (@phadej) reports that he's seeing
```
Undefined symbols for architecture x86_64:
"_utimensat", referenced from:
_LcaBW_info in libHSdirectory-1.3.6.0.a(Posix.o)
```
on a pre `10.13` OSX.
would this be due to incorrect autconf flags for the release build?
cc @bgamari8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17586Changing debug level does not result in recompilation2020-01-07T04:30:58ZBen GamariChanging debug level does not result in recompilationChanging the debug level with the `-g` flag does not result in recompilation.Changing the debug level with the `-g` flag does not result in recompilation.8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/17395`tcMatchTy` is terribly broken2019-11-01T09:28:24ZSimon Peyton Jones`tcMatchTy` is terribly brokenSuppose `(T :: forall k. k -> Type)` and we are matching
```
tcMatchTy (T k (a::k)) (T j (b::j))
```
Then we'll match `k :-> j`, as expected. But then in `TcUnify.unify_tys`
we invoke
```
unify_tys env (a::k) (b::j) (Refl k)
```
D...Suppose `(T :: forall k. k -> Type)` and we are matching
```
tcMatchTy (T k (a::k)) (T j (b::j))
```
Then we'll match `k :-> j`, as expected. But then in `TcUnify.unify_tys`
we invoke
```
unify_tys env (a::k) (b::j) (Refl k)
```
Despite `Note [Kind coercions in Unify]` it's not clear to
me why we need that Refl coercion.
But, assuming we need it, very very bad things now happen.
In `uUnrefined` we end up adding the binding `a :-> (b |> Refl k)`.
Alas! Alack! `k` is one of the template variables, which we are
substituting away, so it's **terrible** if `k` appears in the
range of the substitution -- it belongs only in the range.
A one-line (actually one-character) fix is this:
```
- = do { unify_ty env x y (mkNomReflCo $ typeKind x)
+ = do { unify_ty env x y (mkNomReflCo $ typeKind y)
```
But I am hard-pressed to explain exactly why this is the correct fix.
@rae, help?
This actually bit me when working on `mkCastTy` in #17323.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17181Provide a link to 'A reflection on types' in Type.Reflection2019-09-24T17:08:20ZKoz RossProvide a link to 'A reflection on types' in Type.Reflection## Motivation
Currently, the [documentation page for ``Type.Reflection`` on Hackage][1] mentions the paper 'A reflection on types', but does not link it. Given that [a public-facing copy][2] is available, it seems like a missed opportun...## Motivation
Currently, the [documentation page for ``Type.Reflection`` on Hackage][1] mentions the paper 'A reflection on types', but does not link it. Given that [a public-facing copy][2] is available, it seems like a missed opportunity to direct people more, well, _directly_ to the original write-up of the ideas behind ``Type.Reflection``.
## Proposal
Include a link to [the public-facing copy][2] of the paper. Ideally, this should be done in the first section of the ``Type.Reflection`` page (where the paper is mentioned but currently not linked).
[1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Type-Reflection.html
[2]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/dynamic.pdf8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17179The 'Bug tracker' link on the Hackage page for base 404s2019-09-12T11:39:11ZKoz RossThe 'Bug tracker' link on the Hackage page for base 404s## Summary
On [Hackage's page for base][1], there is a link under 'Bug tracker'. Currently, that link 404s.
## Steps to reproduce
1. Go to [this page][1].
2. Click the link under 'Bug tracker'.
3. Watch the 404.
## Expected behavior
...## Summary
On [Hackage's page for base][1], there is a link under 'Bug tracker'. Currently, that link 404s.
## Steps to reproduce
1. Go to [this page][1].
2. Click the link under 'Bug tracker'.
3. Watch the 404.
## Expected behavior
This should probably aim at [the GHC issues page][2] instead.
## Environment
* GHC version used: This does not involve GHC.
Optional:
* Operating System: Artix GNU/Linux
* System Architecture: x86_64
[1]: http://hackage.haskell.org/package/base
[2]: https://gitlab.haskell.org/ghc/ghc/issues8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17177GHCi segmentation fault when use readv system call2019-09-11T13:53:54ZYoshikuni JujoGHCi segmentation fault when use readv system call## Summary
Error occur when calling system call readv and writev in GHCi.
## Steps to reproduce
[TryVectoredIo.hsc](/uploads/07098291ec7f09e5cbea24c8aeac71bd/TryVectoredIo.hsc)
```haskell
{-# OPTIONS_GHC -Wall -fno-warn-tabs #-}
mod...## Summary
Error occur when calling system call readv and writev in GHCi.
## Steps to reproduce
[TryVectoredIo.hsc](/uploads/07098291ec7f09e5cbea24c8aeac71bd/TryVectoredIo.hsc)
```haskell
{-# OPTIONS_GHC -Wall -fno-warn-tabs #-}
module TryVectoredIo (tryWritev, tryReadv) where
import Foreign.Ptr (Ptr)
import Foreign.Storable (Storable(..))
import Foreign.Marshal (alloca, allocaBytes)
import Foreign.C.Types (CInt(..), CChar)
import Foreign.C.String (peekCStringLen, withCStringLen)
import Control.Exception (bracket)
import Data.Int (Int64)
import System.Posix (
Fd(..), FileMode, openFd, createFile, closeFd,
OpenMode(..), defaultFileFlags,
unionFileModes,
ownerReadMode, ownerWriteMode, groupReadMode, otherReadMode )
#include <sys/uio.h>
foreign import ccall "readv"
c_readv :: Fd -> Ptr Iovec -> CInt -> IO #type ssize_t
tryReadv :: IO ()
tryReadv = withOpenReadModeFd "foo.txt" $ \fd ->
allocaBytes 5 $ \pc -> alloca $ \piov -> do
poke piov $ Iovec (pc, 5)
print =<< c_readv fd piov 1
print =<< peekCStringLen (pc, 5)
withOpenReadModeFd :: FilePath -> (Fd -> IO a) -> IO a
withOpenReadModeFd fp =
bracket (openFd fp ReadOnly Nothing defaultFileFlags) closeFd
tryWritev :: IO ()
tryWritev = withCreateFile "foo.txt" fm644 $ \fd ->
withCStringLen "hello" $ \(pc, ln) -> alloca $ \piov -> do
poke piov $ Iovec (pc, fromIntegral ln)
print =<< c_writev fd piov 1
foreign import ccall "writev"
c_writev :: Fd -> Ptr Iovec -> CInt -> IO #type ssize_t
newtype {-# CTYPE "sys/uio.h" "struct iovec" #-} Iovec = Iovec (Ptr CChar, CInt) deriving Show
instance Storable Iovec where
sizeOf _ = #size struct iovec
alignment _ = #alignment struct iovec
peek p = Iovec <$> ((,) <$> #{peek struct iovec, iov_base} p <*> #{peek struct iovec, iov_len} p)
poke p (Iovec (pc, n)) = #{poke struct iovec, iov_base} p pc >> #{poke struct iovec, iov_len} p n
withCreateFile :: FilePath -> FileMode -> (Fd -> IO a) -> IO a
withCreateFile fp fm = bracket (createFile fp fm) closeFd
fm644 :: FileMode
fm644 = foldr1 unionFileModes
[ownerReadMode, ownerWriteMode, groupReadMode, otherReadMode]
```
```
% hsc2hs --version
hsc2hs version 0.68.1
% hsc2hs mydir/TryVectoredIO.hsc
% ./inplace/bin/ghc-stage2 --version
The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190909
% ./inplace/bin/ghc-stage2 --interactive mydir/TryVectoredIO.hs
> tryWritev
20873216
> tryWritev
46202880
> tryReadv
-1
"Ew"
> tryReadv
zsh: segmentation fault ...
% ./inplace/bin/ghc-stage2 --interactive mydir/TryVectoredIO.hs
> tryWritev
54775808
> tryReadv
<intractive>: internal error: stg_ap_pv_ret
(GHC version 8.9.0.20190909 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
zsh: abort ./inplace/bin/ghc-stage2 --interactive mydir/TryVectoredIo.hs
% ./inplace/bin/ghc-stage2 --interactive mydir/TryVectoredIO.hs
> tryWritev
21291008
> tryReadv
zsh: segmentation fault ...
% ls -l foo.txt
-rw-r--r-- 1 bar baz 21291008 Sep 11 17:59 foo.txt
```
## Expected behavior
```
% ./inplace/bin/ghc-stage2 --interactive mydir/TryVectoredIO.hs
> tryWritev
5
> tryReadv
5
"hello"
> :quit
% cat foo.txt
hello
```
## Environment
* GHC version used: The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190909
* gcc version used: gcc (Gentoo 8.3.0-r1 p1.1) 8.3.0
* glibc version used: 2.29-r2
* hsc2hs version used: 0.68.1
* OS version used: Linux version 4.19.66-gentoo
Optional:
* Operating System: Gentoo GNU/Linux
* System Architecture:8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17115Turn on -fobject-code in GHCi when UnboxedSums in enabled2019-09-26T18:33:40ZAndrew MartinTurn on -fobject-code in GHCi when UnboxedSums in enabledGHC 8.8.1 introduced a wonderful improvement to GHCi: automatically turning on `-fobject-code` when `UnboxedTuples` is enabled. However, `UnboxedSums`, which also requires `-fobject-code`, was overlooked. Fixing this is trivial and requi...GHC 8.8.1 introduced a wonderful improvement to GHCi: automatically turning on `-fobject-code` when `UnboxedTuples` is enabled. However, `UnboxedSums`, which also requires `-fobject-code`, was overlooked. Fixing this is trivial and requires changing one or two lines of code.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17060Compiler ignores Typeable constraint2019-10-08T09:44:26ZRobert PeszekCompiler ignores Typeable constraint## Summary
Compiler allows passing types with no `Typeable` instance to functions declared with `Typeable` constraint.
## Steps to reproduce
The following compiles (no pragmas needed)
```haskell
import Data.Typeable
brokenGhc :: Ty...## Summary
Compiler allows passing types with no `Typeable` instance to functions declared with `Typeable` constraint.
## Steps to reproduce
The following compiles (no pragmas needed)
```haskell
import Data.Typeable
brokenGhc :: Typeable a => a -> a
brokenGhc = id
tst = brokenGhc (Foo "bar")
brokenGhc2 :: (Typeable a) => a -> String
brokenGhc2 = show . typeOf
tst2 = brokenGhc2 (Foo "Bar")
-- ghci> tst2
-- "Foo"
data Foo = Foo String
```
Possibly related to #10770?
## Expected behavior
`tst` and `tst2` should not compile. Note `Foo` has no instances!
## Environment
* GHC version used:
Tested with ghc-8.6.5/lts-14.0, ghc-8.2.2/lts-12.22
Optional:
* Operating System:
Ubuntu 18.04 and Ubuntu 18.10
* System Architecture:
## Suggested Labels:
~Typeable
~bug
~"program incorrectly accepted"8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17031Potential optimization when quotRem divisor is a power of 22019-08-16T08:50:22ZÖmer Sinan AğacanPotential optimization when quotRem divisor is a power of 2Reported by @cocreature on Twitter: https://twitter.com/cocreature/status/1158643061121015808
- Original reproducer: https://gist.github.com/cocreature/822114257227473ecff1638a88f07788
- Actual change in a project: https://github.com/di...Reported by @cocreature on Twitter: https://twitter.com/cocreature/status/1158643061121015808
- Original reproducer: https://gist.github.com/cocreature/822114257227473ecff1638a88f07788
- Actual change in a project: https://github.com/digital-asset/daml/pull/2350/commits/fbde3f500aaaccb86c12bf249730d56aefc891c7
Here's a smaller reproducer: https://gist.github.com/osa1/391be0dfdf0f291468f750a0d2859e50
Comment out the `quotRem` line and uncomment the next two lines. Results:
```
-- quotRem:
benchmarking mangling new
time 918.8 ns (916.1 ns .. 922.3 ns)
1.000 R² (1.000 R² .. 1.000 R²)
mean 919.6 ns (916.8 ns .. 923.1 ns)
std dev 10.39 ns (7.976 ns .. 13.56 ns)
-- shift + mask
benchmarking mangling new
time 405.3 ns (404.0 ns .. 406.6 ns)
1.000 R² (1.000 R² .. 1.000 R²)
mean 405.7 ns (404.4 ns .. 407.1 ns)
std dev 4.365 ns (3.488 ns .. 5.456 ns)
```
So the shift + mask implementation is twice as fast.
As far as I can see we don't have any optimizations when quotRem divisor is a power of 2, and the implementation on `Int` uses a primop, which is lowered to a `div` instruction on x86.
It may worth adding a rewrite rule for this case and generate a shift + mask.
## Environment
* GHC version used: 8.6.5
8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17007Pattern variables bound by type synonyms; or, how long is "due course" anyway?2020-04-20T16:56:38ZRyan ScottPattern variables bound by type synonyms; or, how long is "due course" anyway?If you compile the following code:
```hs
{-# LANGUAGE ScopedTypeVariables #-}
module Bug where
type ItemColID a b = Int -- Discards a,b
get :: ItemColID a b -> ItemColID a b
get (x :: ItemColID a b) = x :: ItemColID a b
```
Then sur...If you compile the following code:
```hs
{-# LANGUAGE ScopedTypeVariables #-}
module Bug where
type ItemColID a b = Int -- Discards a,b
get :: ItemColID a b -> ItemColID a b
get (x :: ItemColID a b) = x :: ItemColID a b
```
Then surprisingly, GHC will reject it:
```
$ /opt/ghc/8.6.5/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:7:6: error:
• The type variables ‘a, b’
should be bound by the pattern signature ‘ItemColID a b’
but are actually discarded by a type synonym
To fix this, expand the type synonym
[Note: I hope to lift this restriction in due course]
• In the pattern: x :: ItemColID a b
In an equation for ‘get’:
get (x :: ItemColID a b) = x :: ItemColID a b
|
7 | get (x :: ItemColID a b) = x :: ItemColID a b
| ^^^^^^^^^^^^^^^^^^
```
Wow. The error message suggests that this restriction will be lifted in "due course". The funny thing is, this error message was added _nine years ago_ in f670c47f9f93ffd6d06b331cd40554cd5e92484c? Surely that's long enough to constitute "due course"?
Indeed, if you look at #3406, the original issue which inspired this commit, @simonpj notes in https://gitlab.haskell.org/ghc/ghc/issues/3406#note_35880 that "With the planned new "outside-in" type inference algorithm, however, this problem will go away." Well, OutsideIn(X) is certainly a thing now, so does that mean the problem really has gone away? I claim the answer is "yes", and there are two pieces of evidence to support this claim.
One piece of evidence is that if you switch `ItemColID` from a type synonym to a type family, like so:
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
type family ItemColID a b where ItemColID a b = Int -- Discards a,b
get :: ItemColID a b -> ItemColID a b
get (x :: ItemColID a b) = x :: ItemColID a b
```
Then GHC 8.6.5 is able to compile it without issue. You can see what happens at the Core level with `-ddump-ds-preopt`:
```
$ /opt/ghc/8.6.5/bin/ghc Bug.hs -fforce-recomp -ddump-ds-preopt -dsuppress-coercions
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
==================== Desugar (before optimization) ====================
Result size of Desugar (before optimization)
= {terms: 15, types: 32, coercions: 26, joins: 0/2}
Rec {
-- RHS size: {terms: 5, types: 0, coercions: 0, joins: 0/0}
Bug.$trModule :: GHC.Types.Module
[LclIdX]
Bug.$trModule
= GHC.Types.Module
(GHC.Types.TrNameS "main"#) (GHC.Types.TrNameS "Bug"#)
-- RHS size: {terms: 8, types: 21, coercions: 26, joins: 0/2}
get :: forall a b. ItemColID a b -> ItemColID a b
[LclIdX]
get
= \ (@ a_a16U) (@ b_a16V) (ds_d185 :: ItemColID a_a16U b_a16V) ->
let {
ds_d189 :: ItemColID GHC.Types.Any GHC.Types.Any
[LclId]
ds_d189 = ds_d185 `cast` <Co:13> } in
let {
x_aVQ :: ItemColID GHC.Types.Any GHC.Types.Any
[LclId]
x_aVQ = ds_d189 } in
x_aVQ `cast` <Co:13>
end Rec }
```
As you can see, `a` and `b` simply get instantiated in `Any`, and everything works out fine.
The second piece of evidence is that I ripped out the code which throws the "`I hope to lift this restriction in due course`" error message in GHC and ran the test suite, and all tests pass. The error message for `T3406` changes slightly:
```diff
diff --git a/testsuite/tests/typecheck/should_fail/T3406.stderr b/testsuite/tests/typecheck/should_fail/T3406.stderr
index 4525bba5d6..69834d15f6 100644
--- a/testsuite/tests/typecheck/should_fail/T3406.stderr
+++ b/testsuite/tests/typecheck/should_fail/T3406.stderr
@@ -1,10 +1,10 @@
-T3406.hs:11:6:
- The type variables ‘a, b’
- should be bound by the pattern signature ‘ItemColID a b’
- but are actually discarded by a type synonym
- To fix this, expand the type synonym
- [Note: I hope to lift this restriction in due course]
- In the pattern: x :: ItemColID a b
- In an equation for ‘get’:
- get (x :: ItemColID a b) = x :: ItemColID a b
+T3406.hs:11:28: error:
+ • Couldn't match type ‘Int’ with ‘a -> ItemColID a b’
+ Expected type: a -> ItemColID a b
+ Actual type: ItemColID a1 b1
+ • In the expression: x :: ItemColID a b
+ In an equation for ‘get’:
+ get (x :: ItemColID a b) = x :: ItemColID a b
+ • Relevant bindings include
+ get :: ItemColID a b -> a -> ItemColID a b (bound at T3406.hs:11:1)
```
But that is to be expected.
In light of this, is the time for "due course" now?8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/17003./hadrian/build.sh docs-haddock fails complaining on llvm-targets2019-10-07T16:01:50ZArtem Pelenitsyn./hadrian/build.sh docs-haddock fails complaining on llvm-targetsWith the current master:
```
$ ./boot && ./configure && ./hadrian/build.sh docs-haddock
...
/--------------------------------------------------------------------------\
| Successfully built program 'haddock' (Stage1). ...With the current master:
```
$ ./boot && ./configure && ./hadrian/build.sh docs-haddock
...
/--------------------------------------------------------------------------\
| Successfully built program 'haddock' (Stage1). |
| Executable: _build/stage1/bin/haddock |
| Program synopsis: A documentation-generation tool for Haskell libraries. |
\--------------------------------------------------------------------------/
| Run Haddock BuildPackage: libraries/ghc-prim/GHC/CString.hs (and 9 more) => _build/docs/html/libraries/ghc-prim/ghc-prim.haddock
Error when running Shake build system:
at want, called at src/Main.hs:89:30 in main:Main
* Depends on: docs-haddock
at need, called at src/Rules/Documentation.hs:77:9 in main:Rules.Documentation
* Depends on: _build/docs/html/libraries/index.html
at need, called at src/Rules/Documentation.hs:164:9 in main:Rules.Documentation
* Depends on: _build/docs/html/libraries/ghc-prim/ghc-prim.haddock
* Raised the exception:
user error (Development.Shake.cmd, system command failed
Command line: _build/stage1/bin/haddock --verbosity=0 -B_build/stage1/lib --lib=_build/stage1/lib --odir=_build/docs/html/libraries/ghc-prim --no-tmp-comp-dir --dump-interface=_build/docs/html/libraries/ghc-prim/ghc-prim.haddock --html --hyperlinked-source --hoogle --quickjump '--title=ghc-prim-0.6.1: GHC primitives' --prologue=_build/docs/html/libraries/ghc-prim/haddock-prologue.txt --optghc=-D__HADDOCK_VERSION__=2220 --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-hide-all-packages --optghc=-no-user-package-db '--optghc=-this-unit-id ghc-prim-0.6.1' '--optghc=-package-id rts-1.0' --optghc=-i --optghc=-i_build/stage1/libraries/ghc-prim/build --optghc=-i_build/stage1/libraries/ghc-prim/build/autogen --optghc=-ilibraries/ghc-prim/. --optghc=-Iincludes --optghc=-I_build/generated --optghc=-I_build/stage1/libraries/ghc-prim/build --optghc=-I/home/artem/Dev/ghc/wt-haddock/_build/stage1/lib/x86_64-linux-ghc-8.9.0.20190728/rts-1.0/include --optghc=-I_build/generated --optghc=-optc-I_build/generated --optghc=-optP-include --optghc=-optP_build/stage1/libraries/ghc-prim/build/autogen/cabal_macros.h --optghc=-outputdir --optghc=_build/stage1/libraries/ghc-prim/build --optghc=-this-unit-id --optghc=ghc-prim --optghc=-XHaskell2010 --optghc=-ghcversion-file=/home/artem/Dev/ghc/wt-haddock/_build/generated/ghcversion.h --optghc=-Wno-deprecated-flags --optghc=-Wno-trustworthy-safe libraries/ghc-prim/GHC/CString.hs libraries/ghc-prim/GHC/Classes.hs libraries/ghc-prim/GHC/Debug.hs libraries/ghc-prim/GHC/IntWord64.hs libraries/ghc-prim/GHC/Magic.hs libraries/ghc-prim/GHC/Prim/Ext.hs _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs libraries/ghc-prim/GHC/Tuple.hs libraries/ghc-prim/GHC/Types.hs _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs +RTS -t_build/stage1/haddock-timing-files/ghc-prim.t --machine-readable -RTS
Exit code: 1
Stderr:
)
```
```
$ _build/stage1/bin/haddock --verbosity=0 -B_build/stage1/lib --lib=_build/stage1/lib --odir=_build/docs/html/libraries/ghc-prim --no-tmp-comp-dir --dump-interface=_build/docs/html/libraries/ghc-prim/ghc-prim.haddock --html --hyperlinked-source --hoogle --quickjump '--title=ghc-prim-0.6.1: GHC primitives' --prologue=_build/docs/html/libraries/ghc-prim/haddock-prologue.txt --optghc=-D__HADDOCK_VERSION__=2220 --optghc=-hisuf --optghc=dyn_hi --optghc=-osuf --optghc=dyn_o --optghc=-hcsuf --optghc=dyn_hc --optghc=-fPIC --optghc=-dynamic --optghc=-hide-all-packages --optghc=-no-user-package-db '--optghc=-this-unit-id ghc-prim-0.6.1' '--optghc=-package-id rts-1.0' --optghc=-i --optghc=-i_build/stage1/libraries/ghc-prim/build --optghc=-i_build/stage1/libraries/ghc-prim/build/autogen --optghc=-ilibraries/ghc-prim/. --optghc=-Iincludes --optghc=-I_build/generated --optghc=-I_build/stage1/libraries/ghc-prim/build --optghc=-I/home/artem/Dev/ghc/wt-haddock/_build/stage1/lib/x86_64-linux-ghc-8.9.0.20190728/rts-1.0/include --optghc=-I_build/generated --optghc=-optc-I_build/generated --optghc=-optP-include --optghc=-optP_build/stage1/libraries/ghc-prim/build/autogen/cabal_macros.h --optghc=-outputdir --optghc=_build/stage1/libraries/ghc-prim/build --optghc=-this-unit-id --optghc=ghc-prim --optghc=-XHaskell2010 --optghc=-ghcversion-file=/home/artem/Dev/ghc/wt-haddock/_build/generated/ghcversion.h --optghc=-Wno-deprecated-flags --optghc=-Wno-trustworthy-safe libraries/ghc-prim/GHC/CString.hs libraries/ghc-prim/GHC/Classes.hs libraries/ghc-prim/GHC/Debug.hs libraries/ghc-prim/GHC/IntWord64.hs libraries/ghc-prim/GHC/Magic.hs libraries/ghc-prim/GHC/Prim/Ext.hs _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hs libraries/ghc-prim/GHC/Tuple.hs libraries/ghc-prim/GHC/Types.hs _build/stage1/libraries/ghc-prim/build/GHC/Prim.hs +RTS -t_build/stage1/haddock-timing-files/ghc-prim.t --machine-readable -RTS
haddock: internal error: _build/stage1/lib/llvm-targets: openFile: does not exist (No such file or directory)
```8.10.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16995Core Lint error with type families2019-10-07T16:06:29ZKrzysztof GogolewskiCore Lint error with type familiesThe following file, found during investigation of #16979, fails `-dcore-lint`. I've checked 8.4, 8.6 and my old copy of master.
```
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
type family Param :: Type -> Type
ty...The following file, found during investigation of #16979, fails `-dcore-lint`. I've checked 8.4, 8.6 and my old copy of master.
```
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
type family Param :: Type -> Type
type family LookupParam (a :: Type) :: Type where
LookupParam (_ Char) = Bool
LookupParam _ = Int
foo :: LookupParam (Param Bool)
foo = undefined
```
The error is:
```
*** Core Lint errors : in result of Desugar (before optimization) ***
Min_w_inc.hs:15:1: warning:
[RHS of foo :: LookupParam (Param Bool)]
Bad axiom application (inconsistent with LookupParam
(_ Char) = Bool
-- Defined at Min_w_inc.hs:11:3)
D:R:LookupParam[1] <Param Bool>_N
<snip>
foo :: LookupParam (Param Bool)
[LclIdX]
foo
= (undefined @ 'LiftedRep @ Int $dIP_a20S)
`cast` (Sub (Sym (D:R:LookupParam[1] <Param Bool>_N))
:: Int ~R# LookupParam (Param Bool))
```8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16984Hadrian CI build doesn't build stage 1 compiler with assertions enabled2020-01-23T19:03:52ZSebastian GrafHadrian CI build doesn't build stage 1 compiler with assertions enabledI find that the hadrian first-level CI build for whatever reason don't build a stage 1 compiler with assertions enabled. At least the make-based CI validate build gets tripped up by them when the hadrian-based doesn't. Here's an example ...I find that the hadrian first-level CI build for whatever reason don't build a stage 1 compiler with assertions enabled. At least the make-based CI validate build gets tripped up by them when the hadrian-based doesn't. Here's an example https://gitlab.haskell.org/ghc/ghc/pipelines/8636.8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16958Derive instances without making the user explicitly demand constraints the co...2019-07-22T17:04:42ZAsad SaeeduddinDerive instances without making the user explicitly demand constraints the compiler already knows about## Motivation
Consider the following code:
```
{-# LANGUAGE
KindSignatures
, DataKinds
, TypeFamilies
, StandaloneDeriving
, PartialTypeSignatures
, TypeFamilyDependencies
, FlexibleInstances
, FlexibleContexts
, Un...## Motivation
Consider the following code:
```
{-# LANGUAGE
KindSignatures
, DataKinds
, TypeFamilies
, StandaloneDeriving
, PartialTypeSignatures
, TypeFamilyDependencies
, FlexibleInstances
, FlexibleContexts
, UndecidableInstances
, TypeApplications
#-}
module Main where
data Idx = Foo | Bar
type family F (a :: Idx) b where
F Foo String = Int
F Foo Int = String
F Bar String = String
F Bar Int = Int
data Test (i :: Idx) = Test { userId :: F i String, userName :: F i Int }
-- deriving Show -- this won't work
deriving instance
-- _ => -- this won't work either
(Show (F i String), Show (F i Int)) => -- this works
Show (Test i)
main :: IO ()
main = print $ Test @Foo (1 :: Int) "foo"
```
(sorry if the example has a few red herrings, just translating something from slack).
You can see that the constraints in the standalone deriving declaration duplicate the fields of the `Test` ADT. The compiler is actually aware of all the constraints it would need to demand in order to provide a derived instance of `Show` for `Test i`, it just won't go ahead and infer them.
## Proposal
Provide some mechanism (doesn't necessarily have to be `data Test = ... deriving Show` or `deriving instance _ => Show (Test i)`) that allows us to just say "yeah, about those missing constraints, just go ahead and demand them and give me an instance".
NB: The type family stuff might be a little bit of a red herring, I think the inability to derive `data Test f i = Test { userId :: f i String, userName :: f i Int } deriving Show` is the same underlying issue.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16951TcCoercibleFail times out in a DEBUG compiler (again)2019-07-23T18:23:34ZRichard Eisenbergrae@richarde.devTcCoercibleFail times out in a DEBUG compiler (again)The test `typecheck/should_fail/TcCoercibleFail` is timing out on my machine (a Mac) on a DEBUG compiler.
Curiously, the `all.T` says
```
# TcCoercibleFail times out with the compiler is compiled with -DDEBUG.
# This is expected (see ...The test `typecheck/should_fail/TcCoercibleFail` is timing out on my machine (a Mac) on a DEBUG compiler.
Curiously, the `all.T` says
```
# TcCoercibleFail times out with the compiler is compiled with -DDEBUG.
# This is expected (see comment in source file).
test('TcCoercibleFail', [when(compiler_debugged(), skip)], compile_fail, [''])
```
So it seems the `when(compiler_debugged(), skip)` bit isn't doing its job.
Note that the long running time itself was #11518, but I really think the current bug I'm reporting is about the testsuite scripts, not about the type-checker (or that ticket, really).8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16949Unevaluated values in strict fields.2022-06-13T12:23:22ZAndreas KlebingerUnevaluated values in strict fields.## Summary
For a constructor of the form `MkT !a` I would expect all fields to be evaluated, even if the actual pointer at runtime might reference a indirection to the evaluated object.
However in parts of cabal we get these definition...## Summary
For a constructor of the form `MkT !a` I would expect all fields to be evaluated, even if the actual pointer at runtime might reference a indirection to the evaluated object.
However in parts of cabal we get these definitions (core output)
```haskell
-- RHS size: {terms: 17, types: 28, coercions: 0, joins: 0/0}
lvl113_rF5y :: Data.ByteString.Internal.ByteString
[GblId]
lvl113_rF5y
= case ghc-prim-0.6.1:GHC.Prim.newMutVar#
@ GHC.ForeignPtr.Finalizers
@ ghc-prim-0.6.1:GHC.Prim.RealWorld
GHC.ForeignPtr.NoFinalizers
ghc-prim-0.6.1:GHC.Prim.realWorld#
of
{ (# ipv_atj5, ipv1_atj6 #) ->
case {__pkg_ccall bytestring-0.10.9.0 Addr#
-> State# RealWorld -> (# State# RealWorld, Word# #)}_atj4
addr#40_rF5x ipv_atj5
of
{ (# ds_atja, ds2_atjb #) ->
Data.ByteString.Internal.PS
addr#40_rF5x
(GHC.ForeignPtr.PlainForeignPtr ipv1_atj6)
0#
(ghc-prim-0.6.1:GHC.Prim.word2Int# ds2_atjb)
}
}
-- RHS size: {terms: 5, types: 3, coercions: 0, joins: 0/0}
lvl197_rFaq :: Data.Set.Internal.Set FieldName
[GblId, Str=m1, Unf=OtherCon []]
lvl197_rFaq
= Data.Set.Internal.Bin
@ FieldName
1#
lvl113_rF5y
(Data.Set.Internal.Tip @ FieldName)
(Data.Set.Internal.Tip @ FieldName)
```
In particular `lvl197_rFaq` is a `Bin` constructor with all strict fields ` Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a)`
`lvl197_rFaq` is also marked as being in WHNF (`Unf=OtherCon []`). However it clearly contains the binding `lvl113_rF5y` which is NOT in WHNF.
As far as I can tell this violates the semantics defined in the Haskell Report.
## Steps to reproduce
This happens when compiling FieldGrammar.hs file bundled with the cabal submodule for GHC commit `2fd1ed54` using -O
Also reproduceable with:
```
git clone https://github.com/haskell/cabal
cd cabal
cabal new-build Cabal --ghc-options="-ddump-simpl -ddump-to-file"
```
locate the "FieldGrammar.dump-simpl" file
look for top level `Bin` constructors with a lvl* argument. This pattern seems pretty common in this module.
## Expected behavior
I would expect lvl197_rFaq to evaluate lvl113_rF5y before constructing the Bin.
## Environment
* GHC version used: Commit 2fd1ed54, reproduced with 8.6.5
Optional:
* Operating System: Windows
* System Architecture: x648.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16937Cache information gathered about external ids in getCgIdInfo.2021-10-29T13:40:24ZAndreas KlebingerCache information gathered about external ids in getCgIdInfo.In getCgIdInfo we lookup (or generate) information required by the code generator for Ids.
Local ids are already cached.
However information about external Ids is instead recreated each time we come across them.
```haskell
getCgIdInfo ...In getCgIdInfo we lookup (or generate) information required by the code generator for Ids.
Local ids are already cached.
However information about external Ids is instead recreated each time we come across them.
```haskell
getCgIdInfo :: Id -> FCode CgIdInfo
getCgIdInfo id
= do { dflags <- getDynFlags
; local_binds <- getBinds -- Try local bindings first
; case lookupVarEnv local_binds id of {
Just info -> return info ;
Nothing -> do {
-- Should be imported; make up a CgIdInfo for it
let name = idName id
; if isExternalName name then
let ext_lbl
| isUnliftedType (idType id) =
-- An unlifted external Id must refer to a top-level
-- string literal. See Note [Bytes label] in CLabel.
ASSERT( idType id `eqType` addrPrimTy )
mkBytesLabel name
| otherwise = mkClosureLabel name $ idCafInfo id
in return $
litIdInfo dflags id (mkLFImported id) (CmmLabel ext_lbl)
else
cgLookupPanic id -- Bug
}}}
```
For GHC itself out of on average ~380 external Ids referenced per module
over half are `True`/`False`/`[]`, so this should definitely be worthwhile.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16930Add a flag to dump all cmm stages and split into separate files2020-06-03T16:10:35ZAlex DAdd a flag to dump all cmm stages and split into separate files## Motivation
I was reading [Overview of GHC's code generator](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen/overview) and noticed a reference to [this TODO](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/co...## Motivation
I was reading [Overview of GHC's code generator](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen/overview) and noticed a reference to [this TODO](https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen/overview)
```
dumpWith :: DynFlags -> DumpFlag -> String -> SDoc -> IO ()
dumpWith dflags flag txt sdoc = do
-- ToDo: No easy way of say "dump all the cmm, *and* split
-- them into files." Also, -ddump-cmm-verbose doesn't play
-- nicely with -ddump-to-file, since the headers get omitted.
dumpIfSet_dyn dflags flag txt sdoc
when (not (dopt flag dflags)) $
dumpIfSet_dyn dflags Opt_D_dump_cmm_verbose txt sdoc
```
## Proposal
Add a new flag (something like `-ddump-cmm-verbose-grouped`) that would dump all the cmm stages and split everything into files, stage per file respectively.8.10.1Alex DAlex Dhttps://gitlab.haskell.org/ghc/ghc/-/issues/16897T13615 segfaults on CI with threaded1 way2019-10-09T21:22:03ZÖmer Sinan AğacanT13615 segfaults on CI with threaded1 waySee https://gitlab.haskell.org/ghc/ghc/-/jobs/115770
Would be good to investigate more.See https://gitlab.haskell.org/ghc/ghc/-/jobs/115770
Would be good to investigate more.8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16895Panic when splicing a malformed InfixE2019-07-07T17:59:56ZArtyom KazakPanic when splicing a malformed InfixE# Summary
GHC panics when splicing `InfixE a op b` or `UInfixE a op b` where `op` is not a variable. Related issue: https://gitlab.haskell.org/ghc/ghc/issues/4877.
# Steps to reproduce
Compiling the following file results in a panic:
...# Summary
GHC panics when splicing `InfixE a op b` or `UInfixE a op b` where `op` is not a variable. Related issue: https://gitlab.haskell.org/ghc/ghc/issues/4877.
# Steps to reproduce
Compiling the following file results in a panic:
```haskell
-- panic.hs
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
main = print $(uInfixE [|1|] [|id id|] [|2|])
```
```
$ stack ghc --compiler=ghc-8.6.5 -- -fforce-recomp panic.hs
[1 of 1] Compiling Main ( panic.hs, panic.o )
Linking panic ...
Undefined symbols for architecture x86_64:
"_Main_main_closure", referenced from:
_ZCMain_main_info in panic.o
_u4lI_srt in panic.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
```
The behavior is slightly different when using GHCi:
```
> :set -XTemplateHaskell
> import Language.Haskell.TH
> $(uInfixE [|1|] [|id id|] [|2|])
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.5 for x86_64-apple-darwin):
nameModule
internal it_a4n5
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Name.hs:240:3 in ghc:Name
```
# Expected behavior
Not panicking.
# Environment
* GHC version used: 8.6.5
Optional:
* Operating System: macOS Mojave
* System Architecture: x648.10.1Alex DAlex D