GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-22T13:39:10Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24566Default types vs deriving2024-03-22T13:39:10ZSylvain HenryDefault types vs deriving## Summary
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12179#note_551772 we added the following code:
```haskell
default ()
data Maybe a = Nothing | Just a
deriving ( Eq -- ^ @since base-2.01
--, Ord -- ^ ...## Summary
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12179#note_551772 we added the following code:
```haskell
default ()
data Maybe a = Nothing | Just a
deriving ( Eq -- ^ @since base-2.01
--, Ord -- ^ @since base-2.01
)
-- ???
-- A non-standalone instance will slurp the interface file for GHC.Num.Integer.
-- During simplifyInstanceContexts, a call to GHC.Tc.Utils.Env.tcGetDefaultTys
-- apparently sees mb_defaults = Nothing and thus tries to bring in the
-- default "default" types, including Integer. This seems wrong.
deriving instance Ord a => Ord (Maybe a) -- ^ @since base-2.01
```
Both standalone and non-standalone instance declarations should "see" the same default types (none here because of the `default ()`).
## Steps to reproduce
Reproduce with:
```haskell
{-# LANGUAGE NoImplicitPrelude #-}
module M where
import GHC.Classes
default ()
data Foo a = Nothing | Just a
deriving (Eq, Ord)
-- deriving instance Eq a => Eq (Foo a)
-- deriving instance Ord a => Ord (Foo a)
```
Build with:
```
strace -f -e trace=file ghc M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
```
We use `-fno-code` because the bignum interfaces seem to be loaded during codegen.
Result with standalone deriving:
```
❯ strace -f -e trace=file ghc-9.8 M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/bin/../lib/x86_64-linux-ghc-9.8.0.20230727/libHSghc-bignum-1.3-0df6-ghc9.8.0.20230727.so", O_RDONLY|O_CLOEXEC) = 3
```
Result with non-standalone deriving:
```
❯ strace -f -e trace=file ghc-9.8 M.hs -fforce-recomp -fno-code 2>&1 | grep ghc-bignum
openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/bin/../lib/x86_64-linux-ghc-9.8.0.20230727/libHSghc-bignum-1.3-0df6-ghc9.8.0.20230727.so", O_RDONLY|O_CLOEXEC) = 3
[pid 172062] stat("/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/lib/../lib/x86_64-linux-ghc-9.8.0.20230727/ghc-bignum-1.3-0df6/GHC/Num/Integer.hi", {st_mode=S_IFREG|0644, st_size=47534, ...}) = 0
[pid 172062] openat(AT_FDCWD, "/home/hsyl20/.ghcup/ghc/9.8.1-alpha1/lib/ghc-9.8.0.20230727/lib/../lib/x86_64-linux-ghc-9.8.0.20230727/ghc-bignum-1.3-0df6/GHC/Num/Integer.hi", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 13
```
## Expected behavior
Bignum interfaces shouldn't be loaded with non-standalone deriving.
## Environment
* GHC version used: 9.6, 9.8https://gitlab.haskell.org/ghc/ghc/-/issues/24565bindist configure fails when LDFLAGS contains pack-relative-locs2024-03-27T12:39:58ZGeshbindist configure fails when LDFLAGS contains pack-relative-locs## Summary
Running `./configure` from the bindist with an `LDFLAGS` containing `-Wl,-z,pack-relative-relocs` fails when trying to `determine machine word size`. I run into this issue when installing a GHC through stack within a `PKGBUIL...## Summary
Running `./configure` from the bindist with an `LDFLAGS` containing `-Wl,-z,pack-relative-relocs` fails when trying to `determine machine word size`. I run into this issue when installing a GHC through stack within a `PKGBUILD` on Arch Linux -- the default `LDFLAGS` setting there contains `-Wl,-z,pack-relative-relocs` since [last month](https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/commit/0f10f032b02bc7823b3ac11f4807b5515c996821).
Raised the issue both in [`stack`](https://github.com/commercialhaskell/stack/issues/6525) and [Arch Linux](https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/21) repos before being prodded by @maerwald that this might need to be addressed via GHC as well
GHC isn't the only Haskell program affected, I similarly have trouble building `unix` and `network`. I haven't investigated these in-depth, but suspect the issue is a similar use of autoconfig for the ffi bits which fails. Raised issue in [`cabal`](https://github.com/haskell/cabal/issues/9828) to see if they can't similarly select `$LD` based on `$LDFLAGS`.
## Steps to reproduce
With eg the [9.6.4 fedora bindist](https://downloads.haskell.org/~ghc/9.6.4/ghc-9.6.4-x86_64-fedora33-linux.tar.xz):
```bash
export LDFLAGS='-Wl,-z,pack-relative-relocs'
./configure
```
## Expected behavior
Configuration should succeed, just like it does without `LDFLAGS` set.
## Environment
* GHC version used: 9.6.4
Optional:
* Operating System: Arch Linux
* System Architecture: x86_649.8.3Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24564Types should be pretty printed as types, not via IfaceType2024-03-19T14:29:12ZMatthew PickeringTypes should be pretty printed as types, not via IfaceTypeQuite a long time ago there were two pretty printers, one for Types and one for IfaceTypes. These were then combined so that Types are converted to IfaceTypes and then printed out.
* Benefit: There is less code.
However, there are some...Quite a long time ago there were two pretty printers, one for Types and one for IfaceTypes. These were then combined so that Types are converted to IfaceTypes and then printed out.
* Benefit: There is less code.
However, there are some downsides to this approach
* Drawback: It is not very modular, because now types purporting to just be to do with interfaces have to know about user pretty printing flags and other details to do with pretty printing. For example see `IfaceFreeTyVar` in `IfaceType`, just an artifact of the pretty printing.
* Drawback: Information gets accidentally serialised to interface files which bloats interface files (see #24563)
If we are going to take steps to reduce interface file size then it is very important to be very very clear about what is going into interface files. Therefore I think we should revert this change and go back to having two pretty printers. One which prints `Type` for users and error messages, and a simpler on which prints `IfaceType` for debugging.https://gitlab.haskell.org/ghc/ghc/-/issues/24563IfaceAppArgs has inefficient Binary instance2024-03-20T02:34:47ZMatthew PickeringIfaceAppArgs has inefficient Binary instanceProblem 1: `Binary IfaceAppArgs` has it's own Binary instance which is different to [a] instance. It directly writes the linked list to the interface file rather than writing the length of the list followed by the whole list continuously...Problem 1: `Binary IfaceAppArgs` has it's own Binary instance which is different to [a] instance. It directly writes the linked list to the interface file rather than writing the length of the list followed by the whole list continuously.
In some interface files this leads to 36% of the interface being taken up by these tag bits.
Problem 2: The `ForAllTyFlag` is serialised to interface files but is not used in `tcIfaceType`.
In some interface files these additional bytes make up `19%` of the entire interface file.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24562Hide Language.Haskell.TH.Lib.Internal from hoogle/haddocks2024-03-19T14:42:24ZTeo CamarasuHide Language.Haskell.TH.Lib.Internal from hoogle/haddocksOn this mailing list thread: https://mail.haskell.org/pipermail/ghc-devs/2024-March/021569.html
@yav mentions that it's confusing that identifiers from [`Language.Haskell.TH.Lib.Internal`](https://hackage.haskell.org/package/template-has...On this mailing list thread: https://mail.haskell.org/pipermail/ghc-devs/2024-March/021569.html
@yav mentions that it's confusing that identifiers from [`Language.Haskell.TH.Lib.Internal`](https://hackage.haskell.org/package/template-haskell-2.21.0.0/docs/Language-Haskell-TH-Lib-Internal.html) come up when searching on Hoogle and in Haddocks, especially since they have the same names as identifiers from the user-facing `Language.Haskell.TH.Lib` module.
Perhaps we could hide this module from Hoogle/Haddock to avoid this confusion as this module isn't meant to be user-facing anyway?
I think the right way to do this is to add a `hide` hadddock options pragma to the file.
Alternatively we could just remove the module from `exposed-modules` but that seems like an unnecessary breaking change.
Hackage search[^1] reveals only HList depends on this module in an example. The other references are from `ghc`, `ghc-lib` and `ghc-lib-parser`, so I don't think users depend on it in practice either.
[^1]: https://hackage-search.serokell.io/?q=Language.Haskell.TH.Lib.Internal9.10.1Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24561"Relocation out of range for SUBTRACTOR" under aarch64_apple_darwin when usin...2024-03-22T18:17:13ZTeo Camarasu"Relocation out of range for SUBTRACTOR" under aarch64_apple_darwin when using Template Haskell and the external interpreter## Summary
While writing a testcase for !12191, I noticed that we get a "Relocation out of range for SUBTRACTOR" error when compiling the following module with the external interpreter under aarch64_apple_darwin.
The only other referen...## Summary
While writing a testcase for !12191, I noticed that we get a "Relocation out of range for SUBTRACTOR" error when compiling the following module with the external interpreter under aarch64_apple_darwin.
The only other reference to this error I could find was in https://gitlab.haskell.org/ghc/ghc/-/issues/24395
, but I'm not sure if this is the same or not.
I don't have access to an aarch64 machine, so I can't reduce the example any further.
I imagine using `lib:ghc` is triggering this issue because it is too large(?) and it would also trigger with any other large library.
## Steps to reproduce
Try to compile the following module:
```haskell
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE LinearTypes #-}
-- | This test shows that we can reify a bunch of primitive types.
-- Additionally it acts as a golden test to ensure that we don't
-- accidentally change our output for these types.
import Control.Monad
import Data.Char
import GHC.Exts
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
import GHC.Builtin.Types.Prim (primTyCons)
import GHC.Tc.Gen.Splice (reifyName)
main :: IO ()
main = $(do let types = map reifyName primTyCons
reified <- mapM reify types
let stripInt [] = []
stripInt (x:xs)
| isDigit x = stripInt xs
| otherwise = x:xs
-- remove _[0-9]* sequences
let stripUniques ('_':xs) = stripUniques $ stripInt xs
stripUniques (x:xs)= x:stripUniques xs
stripUniques [] = []
let output = lift $ map (stripUniques . show) reified
[| mapM_ putStrLn $output |])
```
You will get output like: https://gitlab.haskell.org/ghc/ghc/-/jobs/1801388
```
ghc-iserv: internal error: Relocation out of range for SUBTRACTOR
(GHC version 9.9.20240307 for aarch64_apple_darwin)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
<no location info>: error: External interpreter terminated (-6)
```
## Expected behavior
This should compile fine.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24560Lift instances for template-haskell types2024-03-18T13:38:18ZTeo CamarasuLift instances for template-haskell types## Summary
Types representing ASTs in `template-haskell` do not have `Lift` instances.
These are instead provided by [th-orphans](https://hackage.haskell.org/package/th-orphans) as orphan instances.
## Suggestion
Let's just add these ...## Summary
Types representing ASTs in `template-haskell` do not have `Lift` instances.
These are instead provided by [th-orphans](https://hackage.haskell.org/package/th-orphans) as orphan instances.
## Suggestion
Let's just add these to `template-haskell` instead.
Is there a reason not to do this?https://gitlab.haskell.org/ghc/ghc/-/issues/24559Lambda with invisible type pattern fails to splice with TemplateHaskell2024-03-25T19:13:15ZRyan ScottLambda with invisible type pattern fails to splice with TemplateHaskellI am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Here is an example of an expression one can write with this feature:
```hs
{-# LA...I am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Here is an example of an expression one can write with this feature:
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TypeAbstractions #-}
module Foo where
import Data.Kind
import Data.Proxy
f :: (forall (a :: Type). Proxy a) -> Proxy Bool
f k = k @Bool
g1 :: Proxy Bool
g1 = f (\ @a -> Proxy @a)
```
So far, so good. Now let's introduce a variant of `g1` where the expression is spliced in via `TemplateHaskell`:
```hs
g2 :: Proxy Bool
g2 = f $([| \ @a -> Proxy @a |])
```
I would expect this to typecheck just like `g1` does. And yet, it doesn't:
```
$ ghc-9.10 Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:16:9: error: [GHC-14964]
• Invisible type pattern a has no associated forall
• In the first argument of ‘f’, namely ‘(\ @a -> Proxy @a)’
In the expression: f (\ @a -> Proxy @a)
In an equation for ‘g2’: g2 = f (\ @a -> Proxy @a)
|
16 | g2 = f $([| \ @a -> Proxy @a |])
| ^^^^^^^^^^^^^^^^^^^^^^^^
```9.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/24558Haddock regression with respect to links of qualified identifiers2024-03-20T12:23:13ZMarcin SzamotulskiHaddock regression with respect to links of qualified identifiers## Summary
Qualified identifiers in haddock comments are not represented the right way in haddock interface files, which leads to wrong documentation output.
If a haddock comment contains `IO.newEmptyMVar` where `IO` is qualification o...## Summary
Qualified identifiers in haddock comments are not represented the right way in haddock interface files, which leads to wrong documentation output.
If a haddock comment contains `IO.newEmptyMVar` where `IO` is qualification of an import statement, `haddock-9.8.2` (ver `haddock-api-2.30.0`) the produced interface file contains the following section:
```
"second": {
"tag": "DocAppend",
"first": {
"tag": "DocIdentifierUnchecked",
"modName": "IO"
},
```
The `DocIndetifierUnchecked` is not the right constructor, it should be `DocIdentifier`. With `haddock-9.6.4` (ver `haddock-api-2.29.2`):
```
"second": {
"tag": "DocAppend",
"first": {
"tag": "DocIdentifier",
"name": "$base$GHC.MVar$newEmptyMVar"
},
```
Optional:
* Operating System: linux
* System Architecture:9.8.3Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24557TypeAbstractions doesn't parse with \case, but does parse with \cases2024-03-28T08:53:38ZRyan ScottTypeAbstractions doesn't parse with \case, but does parse with \casesI am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Based on one of the test cases added in that MR, I discovered that `TypeAbstractio...I am using GHC 9.10.1-alpha1, which introduces `@`-binders in more places in pattern contexts (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11109). Based on one of the test cases added in that MR, I discovered that `TypeAbstractions` could be combined with `LambdaCase`, e.g.,
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE TypeAbstractions #-}
module Foo where
import Data.Kind
f :: (forall (a :: Type). ()) -> ()
f k = k @Bool
g :: ()
g = f (\cases
@a -> ())
```
Great. What is surprising, however, is that if I change `\cases` to be `\case`:
```hs
g :: ()
g = f (\case
@a -> ())
```
Then GHC fails to parse it:
```
$ ghc-9.10 Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:11:8: error: [GHC-06074]
Unexpected \case expression in function application:
\case
Suggested fixes:
• Use parentheses.
• Perhaps you intended to use BlockArguments
|
11 | g = f (\case
| ^
Foo.hs:11:8: error: [GHC-66228]
View pattern in expression context: \case @a -> ()
|
11 | g = f (\case
| ^^^^^...
```
This feels inconsistent, as I would expect that if `\cases` works, then `\case` should also work. Is this intended?https://gitlab.haskell.org/ghc/ghc/-/issues/24556Constant folding integer division2024-03-19T19:51:43ZJannisConstant folding integer division## Summary
In !8392 a question about `minBound / (-1)` for integer division came up and its unboxed primop has different behavior depending on optimizations:
`let I# x = minBound in I# (quotInt# x (-1#)) == floating point exception (-O...## Summary
In !8392 a question about `minBound / (-1)` for integer division came up and its unboxed primop has different behavior depending on optimizations:
`let I# x = minBound in I# (quotInt# x (-1#)) == floating point exception (-O0) or minBound (-O1)`
As far as I can tell this happens in core, but I am pretty sure the cmm constant folding would do the same.
## Expected behavior
Both of them should crash with the floating point exception.
## Environment
* GHC version used: 8.4.4 - 9.8.2
Tested on play.haskell.org for every version available there (8.4.4 - 9.8.2) and locally on some recent version of the main branch.JannisJannishttps://gitlab.haskell.org/ghc/ghc/-/issues/24555Test failures in 9.8.2 via test bindist2024-03-23T04:00:34ZJulian OspaldTest failures in 9.8.2 via test bindisthttps://gitlab.haskell.org/-/snippets/5746
Bindist is ghc-9.8.2-x86_64-fedora33-linux.tar.xzhttps://gitlab.haskell.org/-/snippets/5746
Bindist is ghc-9.8.2-x86_64-fedora33-linux.tar.xz9.8.3Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24554ghc-9.10.0.20240313 (alpha1) does not install on macOS2024-03-27T12:34:17ZAndreas Abelghc-9.10.0.20240313 (alpha1) does not install on macOSIssue #21506 is back for 9.10-alpha1. Same description, same symptoms, probably same cure.
Spelling it out:
- macOS Monterey 12.7.1
- download https://downloads.haskell.org/~ghc/9.10.0.20240313/ghc-9.10.0.20240313-x86_64-apple-darwin.t...Issue #21506 is back for 9.10-alpha1. Same description, same symptoms, probably same cure.
Spelling it out:
- macOS Monterey 12.7.1
- download https://downloads.haskell.org/~ghc/9.10.0.20240313/ghc-9.10.0.20240313-x86_64-apple-darwin.tar.xz
- `tar xf ...; cd ghc-...; ./configure`
- Produces pop-ups stating that "`libHS...` was blocked, not from an identified developer"
Here is some detailed error, but this is probably not interesting, since it is really a reprise of #21506 only:
```
./configure: line 13507: 8575 Killed: 9 "$GHC_TOOLCHAIN_BIN" -v2 "$@"
dyld[8606]: Library not loaded: '@rpath/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib'
Referenced from: '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/ghc-toolchain-bin-ghc-9.10.0.20240313'
Reason: tried: '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (code signature in <665593BF-2381-30B1-A621-5A18BB60B521> '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/bin/../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (code signature in <665593BF-2381-30B1-A621-5A18BB60B521> '/Users/abel/bin/soft/ghc-9.10.0.20240313-x86_64-apple-darwin/lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.10.0.20240313/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/usr/local/lib/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file), '/usr/lib/libHSghc-toolchain-0.1.0.0-ff5c-ghc9.10.0.20240313.dylib' (no such file)
```
I would assume it is a packaging error.
See also #23009.
P.S.: Installation succeeds via `ghcup`, thus, not many will bump into this problem.
I dimly remember that `ghcup` implements a work-around (patching the file tree permissions before running installation).9.10.1Rodrigo MesquitaRodrigo Mesquitahttps://gitlab.haskell.org/ghc/ghc/-/issues/24553Expected and actual kinds in "Couldn't match kind" error appear identical2024-03-23T17:28:30ZJoseph C. SibleExpected and actual kinds in "Couldn't match kind" error appear identical## Summary
When a "Couldn't match kind" error occurs because of a difference in the position of a `forall.`, the expected and actual kinds printed will be identical and provide no indication of what the problem is.
## Steps to reproduc...## Summary
When a "Couldn't match kind" error occurs because of a difference in the position of a `forall.`, the expected and actual kinds printed will be identical and provide no indication of what the problem is.
## Steps to reproduce
Try to compile this code:
```
import GHC.Exts (TYPE)
type Foo :: * -> forall r. TYPE r -> *
newtype Foo m a = MkFoo ()
type Bar = Foo :: forall r. * -> TYPE r -> *
```
You'll receive the following error:
```
error: [GHC-83865]
• Expected kind ‘* -> * -> *’, but ‘Foo’ has kind ‘* -> * -> *’
• In the type ‘Foo :: forall r. * -> TYPE r -> *’
In the type declaration for ‘Bar’
```
## Expected behavior
I expect the expected kind and actual kind printed in the error to be different, specifically to indicate the difference in where the `forall.` is.
## Environment
* GHC version used: Tested on both 9.8.2 and 9.10.0.20240313
Optional:
* Operating System: Ubuntu 22.04
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24552pattern synonyms changed semantics from 9.8 to 9.10?2024-03-23T12:12:44Zjwaldmannpattern synonyms changed semantics from 9.8 to 9.10?## Summary
For a simple program with pattern synonyms, code generated by ghc-9.10.1 (alpha-1) behaves differently (throws exception) than code from ghc-9.8.2 (no exception, which seems correct to me).
Also, the exception's name is conf...## Summary
For a simple program with pattern synonyms, code generated by ghc-9.10.1 (alpha-1) behaves differently (throws exception) than code from ghc-9.8.2 (no exception, which seems correct to me).
Also, the exception's name is confusing (mentions "lambda" but there is none)
I checked 9.10 release notes (file ghc-9.10.0.20240313/docs/users_guide/9.10.1-notes.rst) they did not mention any change w.r.t. semantics of pattern synonyms.
## Reproduce
the following (silly) example is minimized from real code
```
{-# language PatternSynonyms #-}
import Prelude hiding (Maybe, Nothing,Just)
import qualified Prelude as P
data Maybe a = Nothing_ | Just_ a
pattern Nothing :: Maybe a
pattern Nothing <- Nothing_ where Nothing = Nothing_
pattern Just :: a -> Maybe a
pattern Just x <- Just_ x where Just = Just_
main = print $ do Just x <- [Nothing, Just ()] ; return x
```
## Actual Behaviour
```
$ /opt/ghc/ghc-9.10.0.20240313/bin/runhaskell ps.hs
ps.hs: ps.hs:14:19-24: Non-exhaustive patterns in lambda
HasCallStack backtrace:
collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:92:13 in ghc-internal:GHC.Internal.Exception
...
```
## Expected behavior
```
$ /opt/ghc/ghc-9.8.2/bin/runhaskell ps.hs
[()]
```9.10.1Apoorv IngleApoorv Inglehttps://gitlab.haskell.org/ghc/ghc/-/issues/24551Literal string redundantly abstracted over a type variable2024-03-22T12:12:35ZjwaldmannLiteral string redundantly abstracted over a type variable## Summary
(I have no idea what's happening, but GHC asks me to report a bug)
## Steps to reproduce
sorry, didn't have time to minimize
```
git clone https://git.imn.htwk-leipzig.de/waldmann/autotool.git
cd autotool
git submodule ini...## Summary
(I have no idea what's happening, but GHC asks me to report a bug)
## Steps to reproduce
sorry, didn't have time to minimize
```
git clone https://git.imn.htwk-leipzig.de/waldmann/autotool.git
cd autotool
git submodule init
git submodule update
curl https://ghc.gitlab.haskell.org/head.hackage/cabal.project >> cabal.project.local
cabal update
cabal build -w /opt/ghc/ghc-9.10.0.20240313/bin/ghc transport
```
## Observed behaviour
```
...
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.10.0.20240313:
corePrepPgm
Case lzy-ctx _x_r3oD :: forall {atom}. Addr#
[GblId, Unf=OtherCon []]
_x_r3oD = \ (@atom_a2ge) -> "missing"#
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:190:37 in ghc-9.10.0.20240313-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/CoreToStg/Prep.hs:2050:16 in ghc-9.10.0.20240313-inplace:GHC.CoreToStg.Prep
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:507:29 in ghc-9.10.0.20240313-inplace:GHC.Utils.Error
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Note
error does NOT happen with `-O0`, or `-O2`, but DOES appear with `-O1` (which is cabal's default?)9.10.1Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/24550NCG: Use 32bit-comparisons when operating on pointer tags.2024-03-20T17:45:22ZAndreas KlebingerNCG: Use 32bit-comparisons when operating on pointer tags.## Summary
I came across this pointer check in Cmm:
```
cGv: // global
call (I64[R1])(R1) returns to cGu, args: 8, res: 8, upd: 8;
cGu: // global
if (R1 & 7 != 1) goto cGz; else goto cGy;
```
Which ...## Summary
I came across this pointer check in Cmm:
```
cGv: // global
call (I64[R1])(R1) returns to cGu, args: 8, res: 8, upd: 8;
cGu: // global
if (R1 & 7 != 1) goto cGz; else goto cGy;
```
Which turns into this assembly:
```
movq %rbx,%rax
andl $7,%eax
cmpq $1,%rax
je .LcGy
.LcGz:
```
Using cmpq wastes a bit here for the 64bit encoding when the 32bit encoding would do.
I think the issue is that we generate the literal 1 as 64bit wide number resulting in a 64bit operation being used.
To reproduce:
```
module M where
{-# NOINLINE incMaybe #-}
incMaybe :: Maybe Int -> Int
incMaybe (Just x) = x + 1
incMaybe Nothing = 0
```
Compile with `ghc A.hs -O2 -ddump-cmm -ddump-asm -dno-typeable-binds -fforce-recomp -ddump-to-file -fno-worker-wrapper -dcmm-lint`
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24549'<stdin>: hGetLine: invalid argument' with Unicode input on Windows2024-03-19T14:52:54ZSiyuan Chen'<stdin>: hGetLine: invalid argument' with Unicode input on Windows## Summary
On Windows, when handling Unicode input it would report an error.
Due to the probabilistic nature of this issue and different locales, I have to narrow it as much as possible (see below). Nevertheless, I'm not sure if it can...## Summary
On Windows, when handling Unicode input it would report an error.
Due to the probabilistic nature of this issue and different locales, I have to narrow it as much as possible (see below). Nevertheless, I'm not sure if it can be 100% reproducible on your side.
## Steps to reproduce
Change "Current language for non-Unicode programs:" to "Chinese (Simplified, China)" and don't check "Beta: UTF-8". (It's might be not necessary, but can narrow the problem).
Create a new project (named testunicode).
```
-- Main.hs
module Main where
import System.IO
main :: IO ()
main = do
i_enc <- hGetEncoding stdin
o_enc <- hGetEncoding stdout
e_enc <- hGetEncoding stderr
putStrLn $ show i_enc
putStrLn $ show o_enc
putStrLn $ show e_enc
line <- getLine
putStrLn line
```
Ensure there is only one conhost.exe in your task manager (It might be not necessary, but can narrow the problem).
Open `cmd.exe`, set `PATH` for GHC and cabal (DON'T launch by a `.cmd` script, it might cause to unable to reproduce!)
Ensure console Font is "新宋体" (Note that if you select other Font, there would be no error but another problem occurs... see below)
```
C:\work-pl\haskell\testunicode>chcp
Active code page: 936
C:\work-pl\haskell\testunicode>chcp 65001
Active code page: 65001 (This will clear the console)
C:\work-pl\haskell\testunicode>cabal build
... [2 of 2] Linking ... \\testunicode.exe
$ cabal run
C:\work-pl\haskell\testunicode>cabal run
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
testunicode: <stdin>: hGetLine: invalid argument (cannot decode byte sequence starting from 208)
```
If can not reproduce (this might be because your code page defaults to UTF-8), do the following:
```
C:\work-pl\haskell\testunicode>chcp 936
Active code page: 936
C:\work-pl\haskell\testunicode>chcp 65001
Active code page: 65001
C:\work-pl\haskell\testunicode>cabal run
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
testunicode: <stdin>: hGetLine: invalid argument (cannot decode byte sequence starting from 208)
```
This should reproduce (DON't close the console window, see below).
It seems like a Windows BUG because sometimes no problem, for example, if you launch the console by a `.cmd` script and console's active code page defaults to UTF-8. However, I don't believe it is a Windows BUG, because some other PL is OK, e.g. Racket.
Even it works perfectly in `io-manager=native` mode.
For example, edit testunicode.cabal and add `ghc-options: -rtsopts`.
```
C:\work-pl\haskell\testunicode>cabal clean
C:\work-pl\haskell\testunicode>cabal build
... [2 of 2] Linking ... \\testunicode.exe
C:\work-pl\haskell\testunicode>cabal run testunicode -- +RTS --io-manager=native
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
Фывфыв
```
It works perfectly.
However, the `--io-manager=native` can not work normally in REPL.
```
C:\work-pl\haskell\testunicode>cabal repl testunicode --repl-options="+RTS --io-manager=native"
ghci> main
Just UTF-8
Just UTF-8
Just UTF-8
<----- STUCK HERE!!!
```
Note that this issue is only for input. No problem with output. For example, if Main.hs has no `getLine` and just `putStrLn "Фывфыв"`, it works perfectly.
##### If you select Font "Lucida Console" instead of "新宋体".
Then no error occurs, but show nothing.
```
C:\work-pl\haskell\testunicode>cabal run
Just UTF-8
Just UTF-8
Just UTF-8
Фывфыв
<----- NOTHING!
```
However, the Lucida Console definitely can render "Фывфыв", see https://www.myfonts.com/collections/lucida-console-font-monotype-imaging
Thanks.
Related issues: https://gitlab.haskell.org/ghc/ghc/-/issues/10542 https://gitlab.haskell.org/ghc/ghc/-/issues/18307
## Expected behavior
Handle Unicode input correctly.
## Environment
* GHC version used: 9.8.19.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/24548configure ignores LDFLAGS2024-03-21T09:39:17ZRodrigo Mesquitaconfigure ignores LDFLAGS## Summary
It seems that `./configure` ignores `LDFLAGS` (whereas `ghc-toolchain` doesn't).
## Steps to reproduce
`LDFLAGS="-Lsomethingbogus" ./configure`
You should get
```
There are some differences between the toolchain configure...## Summary
It seems that `./configure` ignores `LDFLAGS` (whereas `ghc-toolchain` doesn't).
## Steps to reproduce
`LDFLAGS="-Lsomethingbogus" ./configure`
You should get
```
There are some differences between the toolchain configured by "configure" (hadrian/cfg/default.target) and the toolchain configured by the "ghc-toolchain" program (hadrian/cfg/default.target.ghc-toolchain).
20c20
< { ccLinkProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["--target=arm64-apple-darwin","-Wl,-no_fixup_chains","-Wl,-no_warn_duplicate_libraries"] }
---
> { ccLinkProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["--target=arm64-apple-darwin","-Lsomethingbogus","-Wl,-no_fixup_chains","-Wl,-no_warn_duplicate_libraries"] }
```
## Expected behavior
`./configure`-based toolchain configuration should also consider `LDFLAGS` into the cclinker program.
I suppose this is not a priority because `ghc-toolchain` is already doing this right and we ultimately want to move toolchain configuration to it. It is yet another datapoint to hurry on the move (BTW, I think it has been two releases since ghc-toolchain is available opt-in... perhaps the time to make the move is drawing close?).
## Environment
* GHC version used: HEAD
Optional:
* Operating System: macOS
* System Architecture: aarch64https://gitlab.haskell.org/ghc/ghc/-/issues/24547ghcup metadata includes extraneous dlOutput fields2024-03-27T12:34:17ZBen Gamarighcup metadata includes extraneous dlOutput fieldsghcup can apparently infer the output name of an artifact from its URL.
Consequently, we should only include the `dlOutput` field when it would
differ from the filename of `dlUri`, as requested in https://github.com/haskell/ghcup-metadat...ghcup can apparently infer the output name of an artifact from its URL.
Consequently, we should only include the `dlOutput` field when it would
differ from the filename of `dlUri`, as requested in https://github.com/haskell/ghcup-metadata/pull/186/files#diff-b7aa200da91425001d95ee963dc2b97e33c87f584d916569c69fa20b49795887.Ben GamariBen Gamari