GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-26T15:15:03Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24581Missing Pre-processor Command Error Message2024-03-26T15:15:03ZHateUsernamesMissing Pre-processor Command Error Message## Summary
I was using hspec-discover and had forgotten to add `build-tools: hspec-discover` in my cabal file. When I tried running the tests i received the following unhelpful error message
```txt
$ cabal test -O0
Reso...## Summary
I was using hspec-discover and had forgotten to add `build-tools: hspec-discover` in my cabal file. When I tried running the tests i received the following unhelpful error message
```txt
$ cabal test -O0
Resolving dependencies...
Build profile: -w ghc-9.2.7 -O0
In order, the following will be built (use -v for more details):
- biparsing-core-0.0.0.1 (lib) (configuration changed)
- biparsing-core-0.0.0.1 (test:spec) (configuration changed)
Configuring library for biparsing-core-0.0.0.1..
Preprocessing library for biparsing-core-0.0.0.1..
Building library for biparsing-core-0.0.0.1..
Configuring test suite 'spec' for biparsing-core-0.0.0.1..
Preprocessing test suite 'spec' for biparsing-core-0.0.0.1..
Building test suite 'spec' for biparsing-core-0.0.0.1..
tests/Spec.hs:1:1: error:
hspec-discover: builderMainLoop: exec: invalid argument (Bad file descriptor)
|
1 | {-# OPTIONS_GHC -F -pgmF hspec-discover #-}
| ^
```
this error seems to indicate that there is some bad file descriptor in the Spec.hs file and gives a line number where to look.
The actual problem is that the command `hspec-discover` cannot be found in PATH. I would have expected an error more like
```txt
The command hspec-discover could not be found for pre-processing tests/Spec.hs
```
Related issue in hspec https://github.com/hspec/hspec/issues/879
## Steps to reproduce
```sh
echo '{-# OPTIONS_GHC -F -pgmF not-a-real-command #-}' > /tmp/pre-processor-error.hs
ghc /tmp/pre-processor-error.hs
```
## Expected behavior
The following compilation error should be output
```txt
Loaded package environment from /home/wjr/.ghc/x86_64-openbsd-9.2.7/environments/default
/tmp/pre-processor-error.hs:1:1: error:
not-a-real-command: builderMainLoop: exec: invalid argument (Bad file descriptor)
|
1 | {-# OPTIONS_GHC -F -pgmF not-a-real-command #-}
| ^
```
## Environment
* GHC version used: 9.2.7
Optional:
* Operating System: OpenBSD 7.4
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24577Memory Leak with GHC 9.4.72024-03-27T16:43:28ZMathieu BessouMemory Leak with GHC 9.4.7## Summary
Hello, we have a web service running on a machine and the memory usage increase over multiple days:
(The times were the memory usage goes down is when it is restarted during an update.
![image](/uploads/438698384cc45ff446b96...## Summary
Hello, we have a web service running on a machine and the memory usage increase over multiple days:
(The times were the memory usage goes down is when it is restarted during an update.
![image](/uploads/438698384cc45ff446b9686710ece40b/image.png)
However, the live memory and the compact regions are using a fixed amount of memory:
![image](/uploads/a7f532c645e5f7bcf0d5fb3e39042c13/image.png)
![image](/uploads/3087da64e78e5a46e1a5e0ca43079225/image.png)
I know that the problem has existed for months but I am don't know when it started.
The server is written using servant and Warp.
## Steps to reproduce
I can't share the code but I have tracked the problem quite a bit.
I have tracked down the problem to a endpoint that writes data from the db to disk.
It is called every 4 hours.
If I only get the data from the db it desn't leak.
By doing the request in a loop I get an increase in memory use of multiple GB.
The code that leak looks like that:
```
let f data = do
let bs = getjson data
fp = getFilepath data
liftIO $ BL.writeFile fp bs
return $ partOf data
index <- S.fold_ (\acc (k,v) -> M.insert k v acc) def id $ S.mapM f input
```
Where the library S is streaming
I tried running it with -M to limit the memory use in case it was just memory that wasn't released to the os but it eventualy crashes because it doesn't have enough memory.
If I remove `writeFile` it doesn't leak.
If I then evaluate the bytestring manualy and not write it it leaks
If I run the garbage collector after each call it doesn't leak:
```
let f data = do
let bs = getjson data
fp = getFilepath data
liftIO $ BL.writeFile fp bs
return $ partOf data
index <- S.fold_ (\acc (k,v) -> M.insert k v acc) def id $ S.mapM S.mapM (f >=> (\x -> Mem.performGC >> pure x)) input
```
I looked at the fragmentation with ghc-debug and there is barely any pinned data after the request terminate.
## Expected behavior
I would expect:
- that the memory use to be the same before running the request and after.
- that evaluating a bytestring and not using it shouldn't make the program leak.
- that adding a call the the gc doesn't remove the leak
## Environment
* GHC version used: 9.4.7
Optional:
* Operating System: Debian 11
* System Architecture: x86https://gitlab.haskell.org/ghc/ghc/-/issues/24576Add a :version command to GHCi2024-03-26T15:22:43ZMinh Thu VoAdd a :version command to GHCi## Summary
Add a `:version` command to GHCi. This would show either the same as `ghc --version`, or the (beginning of the) first output line of GHCi, which is e.g. "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/ :? for help"...## Summary
Add a `:version` command to GHCi. This would show either the same as `ghc --version`, or the (beginning of the) first output line of GHCi, which is e.g. "GHCi, version 9.11.20240322: https://www.haskell.org/ghc/ :? for help".
This command would especially make sense when used while GHCi is started in a quiet mode (e.g. with `-v0`), where such information would not be displayed at startup.
(I guess it would also make sense in the case of a Machine accessible interface to GHCi https://gitlab.haskell.org/ghc/ghc/-/issues/15461, so a controlling client could query such information.)Minh Thu VoMinh Thu Vohttps://gitlab.haskell.org/ghc/ghc/-/issues/24575Hide GHCi message about ghci.conf being loaded2024-03-26T15:24:20ZMinh Thu VoHide GHCi message about ghci.conf being loaded## Summary
Have a flag to make GHCi not output the string "Loaded GHCi configuration from path/to/ghci.conf". This would let the `ghci.conf` file be in complete charge of what is displayed, instead of being necessarily followed by that ...## Summary
Have a flag to make GHCi not output the string "Loaded GHCi configuration from path/to/ghci.conf". This would let the `ghci.conf` file be in complete charge of what is displayed, instead of being necessarily followed by that string. (This is for cosmetic reason, e.g. when demoing GHCi or providing a specific configuration that displays instructions to follow.)
I think the same option should also hide the version string (but this version string is displayed before the `ghci.conf` file acts, so `ghci.conf` can e.g. clear the clear, and thus is a bit less inconvenient).
## Steps to reproduce
Make sure a `ghci.conf` file exists (it can be empty), then use it with the `-ghci-script` option.
```
$ touch ghci.conf
$ _build/stage1/bin/ghc --interactive -ghci-script ghci.conf
```
## Current behavior
```
$ _build/stage1/bin/ghc --interactive -ghci-script ghci.conf
GHCi, version 9.11.20240322: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from ghci.conf
ghci>
```https://gitlab.haskell.org/ghc/ghc/-/issues/24574bindist's configure generates an invalid target file2024-03-26T15:26:49ZRodrigo Mesquitabindist's configure generates an invalid target file## Summary
The configure in the bindist script generates an invalid target description file (unlike ghc-toolchain). This is currently not a problem for the usability of the compiler because the `settings` file (also written by configure...## Summary
The configure in the bindist script generates an invalid target description file (unlike ghc-toolchain). This is currently not a problem for the usability of the compiler because the `settings` file (also written by configure with roughly the same information) is used directly, but in a future where the target description files are used by GHC instead of the `settings` file (#24212) it will be.
The whole point of generating these files in the bindists is to diff them against the ones generated by ghc-toolchain to find discrepancies between the two. At the moment, this is a completely useless check because the target generated by configure is very broken...
## Steps to reproduce
Download a binary distribution of GHC 9.10.1 and run
```
./configure && cat default.target
```
You should get something like
```
Target
{ tgtArchOs = ArchOS {archOS_arch = ArchX86_64, archOS_OS = OSLinux}
, tgtVendor =
, tgtLocallyExecutable =
, tgtSupportsGnuNonexecStack =
, tgtSupportsSubsectionsViaSymbols =
, tgtSupportsIdentDirective =
, tgtWordSize = WS8
, tgtEndianness =
, tgtSymbolsHaveLeadingUnderscore =
, tgtLlvmTarget = "@LlvmTarget@"
, tgtUnregisterised =
, tgtTablesNextToCode =
, tgtUseLibffiForAdjustors =
, tgtCCompiler = Cc {ccProgram = Program {prgPath = "gcc", prgFlags = }}
, tgtCxxCompiler = Cxx {cxxProgram = Program {prgPath = "g++", prgFlags = }}
, tgtCPreprocessor = Cpp {cppProgram = Program {prgPath = "gcc", prgFlags = }}
, tgtHsCPreprocessor = HsCpp {hsCppProgram = Program {prgPath = "gcc", prgFlags = }}
, tgtCCompilerLink = CcLink
{ ccLinkProgram = Program {prgPath = "gcc", prgFlags = }
, ccLinkSupportsNoPie =
, ccLinkSupportsCompactUnwind =
, ccLinkSupportsFilelist =
, ccLinkSupportsSingleModule =
, ccLinkIsGnu =
}
, tgtAr = Ar
{ arMkArchive = Program {prgPath = "ar", prgFlags = }
, arIsGnu =
, arSupportsAtFile =
, arSupportsDashL =
, arNeedsRanlib =
}
, tgtRanlib = Just (Ranlib {ranlibProgram = Program {prgPath = "ranlib", prgFlags = []}})
, tgtNm = Nm {nmProgram = Program {prgPath = "nm", prgFlags = []}}
, tgtMergeObjs =
, tgtWindres =
}
```
## Expected behavior
Note how half the fields are empty and `tgtLlvmTarget` still refers to a macro...
Ghc-toolchain generates the following file:
```
Target
{ tgtArchOs = ArchOS {archOS_arch = ArchAArch64, archOS_OS = OSDarwin}
, tgtVendor = Just "apple"
, tgtLocallyExecutable = True
, tgtSupportsGnuNonexecStack = False
, tgtSupportsSubsectionsViaSymbols = False
, tgtSupportsIdentDirective = True
, tgtWordSize = WS8
, tgtEndianness = LittleEndian
, tgtSymbolsHaveLeadingUnderscore = True
, tgtLlvmTarget = "arm64-apple-darwin"
, tgtUnregisterised = False
, tgtTablesNextToCode = True
, tgtUseLibffiForAdjustors = True
, tgtCCompiler = Cc {ccProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["--target=arm64-apple-darwin","-Qunused-arguments"] }}
, tgtCxxCompiler = Cxx {cxxProgram = Program { prgPath = "/usr/bin/g++" , prgFlags = ["--target=arm64-apple-darwin"] }}
, tgtCPreprocessor = Cpp {cppProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["-E"] }}
, tgtHsCPreprocessor = HsCpp {hsCppProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["-E","-undef","-traditional","-Wno-invalid-pp-token","-Wno-unicode","-Wno-trigraphs"] }}
, tgtCCompilerLink = CcLink
{ ccLinkProgram = Program { prgPath = "/usr/bin/gcc" , prgFlags = ["--target=arm64-apple-darwin","-Wl,-no_fixup_chains","-Wl,-no_warn_duplicate_libraries"] }
, ccLinkSupportsNoPie = False
, ccLinkSupportsCompactUnwind = True
, ccLinkSupportsFilelist = True
, ccLinkSupportsSingleModule = False
, ccLinkIsGnu = False
}
, tgtAr = Ar
{ arMkArchive = Program { prgPath = "/usr/bin/ar" , prgFlags = ["qcls"] }
, arIsGnu = False
, arSupportsAtFile = False
, arSupportsDashL = False
, arNeedsRanlib = True
}
, tgtRanlib = Just (Ranlib {ranlibProgram = Program { prgPath = "/usr/bin/ranlib" , prgFlags = [] }})
, tgtNm = Nm {nmProgram = Program { prgPath = "/usr/bin/nm" , prgFlags = [] }}
, tgtMergeObjs = Just (MergeObjs {mergeObjsProgram = Program { prgPath = "/usr/bin/ld" , prgFlags = ["-r"] }, mergeObjsSupportsResponseFiles = True})
, tgtWindres = Nothing
}
```9.10.1Ben GamariRodrigo MesquitaBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24573MacOS binaries have $ORIGIN in RPATH2024-03-26T15:28:47ZRodrigo MesquitaMacOS binaries have $ORIGIN in RPATH## Summary
The binaries shipped with GHC on macOS have an `RPATH` entry that refers to `$ORIGIN`, a Linux-only dynamic linker variable...
## Steps to reproduce
On macOS,
```
otool -l $(ghc --print-libdir)/../bin/ghc | grep -A2 RPATH
`...## Summary
The binaries shipped with GHC on macOS have an `RPATH` entry that refers to `$ORIGIN`, a Linux-only dynamic linker variable...
## Steps to reproduce
On macOS,
```
otool -l $(ghc --print-libdir)/../bin/ghc | grep -A2 RPATH
```
you get
```
cmd LC_RPATH
cmdsize 56
path @loader_path/../lib/aarch64-osx-ghc-9.8.1 (offset 12)
--
cmd LC_RPATH
cmdsize 56
path $ORIGIN/../../../lib/aarch64-osx-ghc-9.8.1 (offset 12)
```
## Expected behavior
There shouldn't be any RPATH entries referring to `$ORIGIN` as the macOS loader can't ever resolve it, thus no dynamic library can actually be found there.
## Environment
* GHC version used: 9.8.1, 9.10.1
Optional:
* Operating System: macOS
* System Architecture: aarch64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24572RequiredTypeArguments: application of infix type fails when combined with Tem...2024-03-26T15:29:03ZRyan ScottRequiredTypeArguments: application of infix type fails when combined with TemplateHaskellI am using the `master` branch of GHC on commit da2a10ceab7498fbbd5723dee0393ce75f2bb562. That includes a fix for https://gitlab.haskell.org/ghc/ghc/-/issues/24570, so this program now typechecks:
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANG...I am using the `master` branch of GHC on commit da2a10ceab7498fbbd5723dee0393ce75f2bb562. That includes a fix for https://gitlab.haskell.org/ghc/ghc/-/issues/24570, so this program now typechecks:
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE RequiredTypeArguments #-}
{-# LANGUAGE TemplateHaskell #-}
module Foo where
import Language.Haskell.TH
idee :: forall a -> a -> a
idee _ x = x
type (!@#) = Bool
f :: Bool -> Bool
f = idee (!@#)
```
Surprisingly, however, this variation of `f` does not typecheck:
```hs
g :: Bool -> Bool
g = $([| idee (!@#) |])
```
```
~/Software/ghc/_build/stage1/bin/ghc Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:17:6: error: [GHC-55017]
• Illegal data constructor name: ‘!@#’
When splicing a TH expression: Foo.idee (Foo.!@#)
• In the untyped splice: $([| idee (!@#) |])
|
17 | g = $([| idee (!@#) |])
| ^^^^^^^^^^^^^^^^^^
```
Why is GHC complaining about a data constructor name when `(!@#)` is a type name? If you compile this program with `-ddump-simpl`, you'll see:
```
$ ~/Software/ghc/_build/stage1/bin/ghc Foo.hs -ddump-simpl
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
==================== Simplified expression ====================
Language.Haskell.TH.Lib.Internal.appE
@Language.Haskell.TH.Syntax.Q
Language.Haskell.TH.Syntax.$fQuoteQ
(Language.Haskell.TH.Lib.Internal.varE
@Language.Haskell.TH.Syntax.Q
Language.Haskell.TH.Syntax.$fQuoteQ
(Language.Haskell.TH.Syntax.mkNameG_v
(GHC.CString.unpackCString# "main"#)
(GHC.CString.unpackCString# "Foo"#)
(GHC.CString.unpackCString# "idee"#)))
(Language.Haskell.TH.Lib.Internal.conE
@Language.Haskell.TH.Syntax.Q
Language.Haskell.TH.Syntax.$fQuoteQ
(Language.Haskell.TH.Syntax.mkNameG_tc
(GHC.CString.unpackCString# "main"#)
(GHC.CString.unpackCString# "Foo"#)
(GHC.CString.unpackCString# "!@#"#)))
```
Which reveals that GHC is desugaring `g` to something like this:
```hs
g :: Bool -> Bool
g = $(varE 'idee `appE` conE ''(!@#))
```
I believe `conE` is the culprit here. If you look into how `conE` is desugared, you'll find that it calls [`cName`](https://gitlab.haskell.org/ghc/ghc/-/blob/da2a10ceab7498fbbd5723dee0393ce75f2bb562/compiler/GHC/ThToHs.hs#L2101):
```hs
cName n = cvtName OccName.dataName n
```
Where [`cvtName`](https://gitlab.haskell.org/ghc/ghc/-/blob/da2a10ceab7498fbbd5723dee0393ce75f2bb562/compiler/GHC/ThToHs.hs#L2127-2136) is defined as:
```hs
cvtName :: OccName.NameSpace -> TH.Name -> CvtM RdrName
cvtName ctxt_ns (TH.Name occ flavour)
| not (okOcc ctxt_ns occ_str) = failWith (IllegalOccName ctxt_ns occ_str)
| otherwise
= do { loc <- getL
; let rdr_name = thRdrName loc ctxt_ns occ_str flavour
; force rdr_name
; return rdr_name }
where
occ_str = TH.occString occ
```
Note the `not (okOcc ctxt_ns occ_str)` check. When calling `cName`, `ctxt_ns` is `dataName`, so this check will only succeed if the supplied `Name` is a valid data constructor. `''(!@#)` isn't a valid data constructor `Name`, so it fails this check.
-----
Two possible ways of fixing this include:
1. Relaxing this check. (I'm not sure what the consequences of this would be.)
2. Change the way `RequiredTypeArguments` applications are desugared so that `[| idee (!@#) |]` is desugared to ``varE 'idee `appE` typeE (conT ''(!@#))`` instead. This would have the downside that `[| idee (!@#) |]` would be indistinguishable from `[| idee (type (!@#$)) |]` after desugaring, however.https://gitlab.haskell.org/ghc/ghc/-/issues/24569CI: MacOS update causes build failure2024-03-27T02:35:41ZBryan Rbryan@haskell.foundationCI: MacOS update causes build failureExample: https://gitlab.haskell.org/ghc/ghc/-/jobs/1811344
This affected https://gitlab.haskell.org/admin/runners/706#/ and https://gitlab.haskell.org/admin/runners/705#/
@angerman reports:
> When you run m4, it tells you "requesting ...Example: https://gitlab.haskell.org/ghc/ghc/-/jobs/1811344
This affected https://gitlab.haskell.org/admin/runners/706#/ and https://gitlab.haskell.org/admin/runners/705#/
@angerman reports:
> When you run m4, it tells you "requesting installation of command line developer tools", you then get the popup, it installs the CLT.
>
> If you run m4 again, the whole process starts all over again.
```
Command line: sh configure --enable-shared=no --with-pic=yes --host=aarch64-apple-darwin --build=aarch64-apple-darwin
===> Command failed with error code: 1
configure: error: No usable m4 in $PATH or /usr/5bin (see config.log for reasons).
```Moritz AngermannBryan Rbryan@haskell.foundationMoritz Angermannhttps://gitlab.haskell.org/ghc/ghc/-/issues/24568Make ghc-toolchain vs configure differences errors instead of warnings2024-03-26T15:35:28ZRodrigo MesquitaMake ghc-toolchain vs configure differences errors instead of warningsI believe ghc-toolchain has been introduced for over 2 releases now, and that we should proceed to the next stage: making it the default and deleting toolchain configuration logic from configure.
To this end, we should try to make the c...I believe ghc-toolchain has been introduced for over 2 releases now, and that we should proceed to the next stage: making it the default and deleting toolchain configuration logic from configure.
To this end, we should try to make the current configure warning which diffs the outputs of configure and ghc-toolchain into errors. Given the lack of recent reports about toolchains differences and the fact that CI currently checks for these differences as errors, they should not be terribly common and push remaining problems to be reported...
Although this may be too heavy of a hammer. It would be good to discuss what should be the path forward for a ghc-toolchain-only-future with high assurance.9.14.1https://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/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/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.3