GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-25T17:23:20Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24585GHC master fails to build with alex 3.5.1.02024-03-25T17:23:20ZRodrigo MesquitaGHC master fails to build with alex 3.5.1.0## Summary
Upgrading to Alex 3.5.1.0 makes compilation of GHC on master fail because of 7dfdf3d9fbc216653fe2cf95cc52c35900bdc8b4 (cc @hsyl20)
```
compiler/GHC/Parser/Lexer.x:2871:20: error: [GHC-88464]
Data constructor not in scope...## Summary
Upgrading to Alex 3.5.1.0 makes compilation of GHC on master fail because of 7dfdf3d9fbc216653fe2cf95cc52c35900bdc8b4 (cc @hsyl20)
```
compiler/GHC/Parser/Lexer.x:2871:20: error: [GHC-88464]
Data constructor not in scope: C# :: t0 -> Char
Suggested fixes:
• Perhaps use one of these:
‘GHC.Exts.C#’ (imported from GHC.Exts),
‘GHC.Exts.D#’ (imported from GHC.Exts),
‘GHC.Exts.F#’ (imported from GHC.Exts)
• Add ‘C#’ to the import list in the import of ‘GHC.Exts’
(at _build/stage0/compiler/build/GHC/Parser/Lexer.hs:100:1-202).
|
2871 |
| ^^
compiler/GHC/Parser/Lexer.x:2871:24: error: [GHC-88464]
Variable not in scope: chr# :: Int# -> t0
Suggested fixes:
• Perhaps use one of these:
‘GHC.Exts.chr#’ (imported from GHC.Exts),
‘chr’ (imported from Data.Char)
• Add ‘chr#’ to the import list in the import of ‘GHC.Exts’
(at _build/stage0/compiler/build/GHC/Parser/Lexer.hs:100:1-202).
|
2871 |
| ^^^^
```
## Steps to reproduce
Try building master with alex 3.5.1.0
## Environment
* GHC version used: 9.8.2, alex 3.5.1.0
## Solution
It seems to be sufficient to qualify the names with GHC.Extshttps://gitlab.haskell.org/ghc/ghc/-/issues/24584Size reduction of "hello world" bundle compiled by javascript-backend2024-03-28T16:17:06ZSerge S. GulinSize reduction of "hello world" bundle compiled by javascript-backendLong-running issue (more like _epic_ than issue)
## Motivation
[Hello World](https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend/building#compiling-hello-world) bundle size is:
```
6224 -rw-r--r-- 1 gulinserge staff 5398132 ...Long-running issue (more like _epic_ than issue)
## Motivation
[Hello World](https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend/building#compiling-hello-world) bundle size is:
```
6224 -rw-r--r-- 1 gulinserge staff 5398132 Mar 23 20:39 all.js
```
Reduction `~5.4mb` would help to use ghc in wider application of web development.
## Proposal
Size reduction strategy could be considered in following broad directions:
1. **JavaScript-centric**. Use widely known existing tools to reduce js bundle size, such as (at least): [Google Closure Compiler](https://github.com/google/closure-compiler) and [UglifyJS](https://github.com/mishoo/UglifyJS). Here we will gather information on how existing bundle compress solutions work with hello-world. And if they do not work for some reasonable cases we will apply fixes and improvements to our javascript-backend building process.
2. **Environment-related**. JavaScript code is running in a rich environment where many basic things are defined and implemented already. For example, browsers already provide some Unicode and Locale support via `Intl`, which can probably be reused. So, our javascript hello-world bundle could reduce its size by removing already implemented stuff in browsers via ECMAScript standard.
3. **Translation-leaned**. GHCJS had built-in tooling for better dedupe called [Compactor](https://github.com/ghcjs/ghcjs/blob/b7711fbca7c3f43a61f1dba526e6f2a2656ef44c/src/Gen2/Compactor.hs). Such an approach could be ported to GHC Javascript-Backend and enabled in the same fashion via compilation options like `-dedupe`.
Currently this issue is about **N1** as other options still require deep dive from my side.
### JavaScript-centric
Usage of existing JavaScript tools to reduce the size of bundle output is a straightforward task. Honestly that is the first thing that comes to the mind.
See the difference how it is much between UglifyJS and Closure Compiler for hello-world:
```
$ uglifyjs --compress --mangle --output ./HelloJS.jsexe/all.min.uglifyjs.js -- ./HelloJS.jsexe/all.js
$ ls -als ./HelloJS.jsexe
...
4968 -rw-r--r-- 1 gulinserge staff 5084786 Mar 24 19:11 all.min.uglifyjs.js
```
To run Closure Compiler need to do [some](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12293) (See the origin [issue](https://gitlab.haskell.org/ghc/ghc/-/issues/24578)) [changes](https://gitlab.haskell.org/gulin.serge/ghc/-/compare/master...wip%2Fgoogle_closure?from_project_id=1&straight=false) (will be prepared as MR after applying the MR before) in GHC code because Closure Compiler will raise errors.
<details><summary>What if we run without these changes?</summary>
At first we hit the following:
```
./HelloJS.jsexe/all.js:12611:9: ERROR - [JSC_VAR_MULTIPLY_DECLARED_ERROR] Variable h$rts_isProfiled declared more than once. First occurrence: ./HelloJS.jsexe/all.js:8723:9
12611| function h$rts_isProfiled() {
```
The [origin issue](https://gitlab.haskell.org/ghc/ghc/-/issues/24578) has some investigation into how it happened.
> Commit https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11447/diffs#24e9216fe80fd5aa5c24ea79d3633fb0b2bee7c6_0_17 added a dupe of `h$rts_isProfiled` which was already defined by https://gitlab.haskell.org/ghc/ghc/-/commit/08d8e9efa245e87e9c67da73e0987846865671d6#c14e882edb9d4b205929f4f71581a2e43ea05852_334_335
Then if we try to fix it locally (how MR suggests) we will hit the following on [latest master](https://gitlab.haskell.org/ghc/ghc/-/tree/8d67f247c3e4ca3810712654e1becbf927405f6b) (+ applied [MR](https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12293)):
```
./HelloJS.jsexe/all.js:7795:8: ERROR - [JSC_UNDEFINED_VARIABLE] variable java is undeclared
7795| java.lang.System.out.print(s);
^^^^
./HelloJS.jsexe/all.js:8432:27: ERROR - [JSC_UNDEFINED_VARIABLE] variable Buffer is undeclared
8432| h$fs.read(real_fd, Buffer.alloc(n), 0, n, pos, function(err, bytesRead, nbuf) {
^^^^^^
./HelloJS.jsexe/all.js:8495:8: ERROR - [JSC_UNDEFINED_VARIABLE] variable putstr is undeclared
8495| putstr(h$decodeUtf8(buf, n, buf_offset));
^^^^^^
./HelloJS.jsexe/all.js:8499:8: ERROR - [JSC_UNDEFINED_VARIABLE] variable printErr is undeclared
8499| printErr(h$decodeUtf8(buf, n, buf_offset));
^^^^^^^^
./HelloJS.jsexe/all.js:8507:37: ERROR - [JSC_UNDEFINED_VARIABLE] variable debug is undeclared
8507| var h$base_stderrLeftover = { f: debug, val: null };
^^^^^
./HelloJS.jsexe/all.js:9747:68: ERROR - [JSC_UNDEFINED_VARIABLE] variable null_ is undeclared
9747| var p = (((ptr_d).arr && (ptr_d).arr[off]) ? (ptr_d).arr[off] : null_); var o = (ptr_d).dv.getInt32(off,true);;
^^^^^
./HelloJS.jsexe/all.js:10273:26: ERROR - [JSC_UNDEFINED_VARIABLE] variable j is undeclared
10273| for(j=x.length-1;j>=0;j--) {
^
./HelloJS.jsexe/all.js:12247:9: ERROR - [JSC_UNDEFINED_VARIABLE] variable ptr is undeclared
12247| return ptr = h$initHeapBufferLen(str_d, str_o, str_d.len);
^^^
./HelloJS.jsexe/all.js:12498:25: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$setCcs_e is undeclared
12498| if(h$stack[h$sp] !== h$setCcs_e) {
^^^^^^^^^^
./HelloJS.jsexe/all.js:12808:11: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$vt_int is undeclared
12808| case h$vt_int:
^^^^^^^^
./HelloJS.jsexe/all.js:12941:22: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$checkInvariants_e is undeclared
12941| h$stack[h$sp] = h$checkInvariants_e;
^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:13834:33: ERROR - [JSC_UNDEFINED_VARIABLE] variable arr is undeclared
13834| return h$charCodeArrayToString(arr);
^^^
./HelloJS.jsexe/all.js:13925:12: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$EINVAL is undeclared
13925| h$errno = h$EINVAL;
^^^^^^^^
./HelloJS.jsexe/all.js:14112:2: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$fds is undeclared
14112| h$fds[fd].waitRead.push(h$currentThread);
^^^^^
./HelloJS.jsexe/all.js:24517:13: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$stg_cloneMyStackzh is undeclared
24517| if(c) {var g=h$stg_cloneMyStackzh();
^^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:24518:6: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$stg_decodeStackzh is undeclared
24518| var i=h$stg_decodeStackzh(g);
^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:25814:6: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$libdwLookupLocation is undeclared
25814| var h=h$libdwLookupLocation(d,e,a,c,f,g);
^^^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:26282:21: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$libdwPoolRelease is undeclared
26282| h$r3=h$mkFunctionPtr(h$libdwPoolRelease);
^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:26290:2: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$libdwPoolTake is undeclared
26290| a=h$libdwPoolTake();
^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:26307:2: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$libdwGetBacktrace is undeclared
26307| c=h$libdwGetBacktrace(a,b);
^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:26335:21: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$backtraceFree is undeclared
26335| h$r3=h$mkFunctionPtr(h$backtraceFree);
^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:33154:5: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$fdReady is undeclared
33154| h$r1=h$fdReady(a,1,f,(c>>>0),0);
^^^^^^^^^
./HelloJS.jsexe/all.js:37760:5: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$lookupIPE is undeclared
37760| h$r1=h$lookupIPE(a,c,d,0);
^^^^^^^^^^^
./HelloJS.jsexe/all.js:47403:0: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$reportStackOverflow is undeclared
47403| h$reportStackOverflow(c);
^^^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:47407:8: ERROR - [JSC_UNDEFINED_VARIABLE] variable h$reportHeapOverflow is undeclared
47407| case(2):h$reportHeapOverflow();
^^^^^^^^^^^^^^^^^^^^
./HelloJS.jsexe/all.js:57067:4: ERROR - [JSC_VAR_MULTIPLY_DECLARED_ERROR] Variable fs declared more than once. First occurrence: ./HelloJS.jsexe/all.js:7767:8
57067| var fs, nodePath;
^^
26 error(s), 87 warning(s)
make: *** [Makefile:8: closure] Error 26
```
</details>
When all changes will be applied to master branch of GHC it will be possible to run Google Closure Compiler:
```
$ google-closure-compiler --isolation_mode IIFE --assume_function_wrapper --emit_use_strict --externs ./HelloJS.jsexe/all.js.externs --compilation_level ADVANCED_OPTIMIZATIONS ./HelloJS.jsexe/all.js ./hello.externs.js --js_output_file ./HelloJS.jsexe/all.min.js
$ ls -als ./HelloJS.jsexe
...
4160 -rw-r--r-- 1 gulinserge staff 3775580 Mar 23 16:50 all.min.js
```
<details><summary>For reference ./hello.externs.js is following:</summary>
```
/**
* @externs
*/
/** @type {*} */
Module.HEAP8;
if (typeof process !== 'undefined') {
/** @type {*} */
process.stdin.on;
}
/** @type {*} */
var __dirname = typeof __dirname != 'undefined' ? __dirname : undefined;
```
</details>
<details><summary>Why we do not test SWC?</summary>
SWC is a good thing, but it supports tree shaking only for CommonJS-enabled bundle output which is not currently available with ghc javascript-backend. When (and ever) we will support it, we could try this compiler as well and very probably it will do the job better than others.
</details>
| | Origin | UglifyJS (+ mangle) | Google Closure Compiler (Advanced) |
| ------ | ------ | ------------------- | -----------------------------------|
| Size | 5398132 | 5084786 | 3775580 |
It is not a surprise that Closure Compiler wins the challenge with UglifyJS. Google Closure Compiler does deep static code analysis (that's why it was possible CC to point us on errors) to eliminate dead code and throw it away.
#### Little summary
Using existing tools to compress generated bundles is useful. To make it happen we still need to change GHC code to make its output work with Google Closure Compiler. To prevent us from facing such issues further it would be nice to add Google Closure Compiler to the test suite and run it at least over the hello-world bundle just to make sure that we do not add mistakes to javascript code which can be noted automatically via static checks.
### Environment-related
Middle way of optimizations is to make a good deal with the environment where we are supposed to run our javascript bundles. I reviewed our code of supported environments, and, it seems, we are going to
<details><summary> support as much as possible. </summary>
```
function h$isNode() {
return h$isNode_;
}
function h$isJvm() {
return h$isJvm_;
}
function h$isJsShell() {
return h$isJsShell_;
}
function h$isJsCore() {
return h$isJsCore_;
}
function h$isBrowser() {
return h$isBrowser_;
}
function h$isGHCJSi() {
return h$isGHCJSi_;
}
```
</details>
Besides the wide list of JVM ones (Rhino, Nashorn, GraalVM) , browser support requires even more effort due its very large amount of differences between them.
So, the first step here is to define **what exactly** we are going to support. And leave details to tools which are specialized on graceful degradation in the modern web. My point of view is simple. We could rely on the edge of ECMA and leave things down to tools like `babel`. That's how the javascript world works with all its huge amount of little differences.
If we are going to take such a way the problem becomes simpler.
Okay, suppose we've limited our list of support to only edge ECMA but why do I ever tell about it? Even if we will have applied for **N1** we are still dealing with `~3.8MB`. It is still quite a large volume for an average browser app. Let's take a look deeper into our bundle.
I did the following:
1. Processed our bundle via Google Closure Compiler (with all patches enabled) but with `--debug` option. It produces output without dead code but also without names mangling.
2. Counted chars on every line. Most interesting is `out.js` content. Its structure is very simple: every line contains a translated expression from haskell. For example: `var h$ghczminternalZCGHCziInternalziUnicodezizdtrModule4_1=h$rawStringData([103,104,99,45,105,110,116,101,114,110,97,108]);`.
3. Calculated sum of all chars (without newlines), divided every line all chars over sum of all chars, selected some threshold to limit noise.
4. Draw the graph of accumulated amount for weighted lines length.
It has a very interesting structure.
![image](/uploads/3456f8c51873d72e1b9c6d8e065a56d3/image.png)
At the image above you will note that size grows at a lower speed most of the time. But there is an area where its growing speed is very large. I took a look into it and found the following:
```
h$ghczminternalZCGHCziInternalziUnicodeziCharziUnicodeDataziGeneralCategoryzilvl_1=h$rawStringData([25,25,25,25,25,25,25,25,25,25,25,25,25,25,25,25,25......
```
`GHC.Internal.Unicode.Char.UnicodeData.GeneralCategory.lvl_1`. It is related to [this](https://gitlab.haskell.org/ghc/ghc/-/tree/8d67f247c3e4ca3810712654e1becbf927405f6b/libraries/ghc-internal/src/GHC/Internal/Unicode/Char/UnicodeData). And one of these files take up to `3.5MB` in sources.
**Here are my assumptions.** I assume that we could avoid bundling Unicode into javascript builds due to having `Intl` in modern browsers and environments. I cut off this line from my minified bundle and its size became: `0.5MB`.
#### Little summary
The Javascript Environment is rich but very granular. But in best crossed chances we could drastically reduce our `>5.5MB` bundle to a notable little `~0.5MB`. It is TEN times better. To make it happen we should select a strategy which Javascript Environments we support, how and at which limitations. After that we could make steps into the more risky part: swap GHC internals on Environment implementations. For an average web app where size is critical the total win is **10x**.
### Translation-leaned
It is the last way which I can see currently but not the least. Our Haskell->Javascript translation process is not perfect. It leaves out very important things in modern JavaScript development such as: CommonJS module wrapping, Source Code Maps generation, origin code (at Haskell) duplication removal, types information provided to JavaScript tools. I think there are other things but these came to my mind first.
Every point of above could have a positive impact on javascript code compression. For example, having CommonJS module wrapping opens a door into modern javascript compilers: [SWC](https://swc.rs/). See the [list](https://github.com/privatenumber/minification-benchmarks) for details why. Having Source Code Maps opens a door into modern JavaScript tooling to [analyze](https://github.com/danvk/source-map-explorer) what takes space in the bundle (besides a nice-to-have [feature](https://developer.chrome.com/docs/devtools/javascript/source-maps?hl=en) to show sources right at the browser with breakpoints).
But for first attempt I would move your look into existing `-dedupe` option in GHCJS which is covered by [Compactor](https://github.com/ghcjs/ghcjs/blob/b7711fbca7c3f43a61f1dba526e6f2a2656ef44c/src/Gen2/Compactor.hs). Its results are described at [Reddit](https://www.reddit.com/r/haskell/comments/54knub/ghcjs_dedupe/). As for me it is good to have things which could help too with size reduction.
It would be nice to port it into GHC JavaScript-Backend and see how it will go. This issue is not about it (because it still requires deep investigation from me) but looks pretty promising.
#### Little summary
This way of optimizations scratched very little at the current time but I bet here we will hit 2 things in one shot: earn some amount of size reduction with improvement overall development experience of ghc javascript-backend usage.
## Summary
Suggested changes already have potential improvements in 10 times for hello-world. I am open for any questions and as you suppose most sentences in this issue could be covered by a large description further. I hope that with blessing from the GHC community we could improve the current situation with bundle size. And as you see also code size reduction is not only about size. It points us to far away things which could be a game changer for the role of GHC in modern client-side web development.https://gitlab.haskell.org/ghc/ghc/-/issues/24583Recent lexer perf compile error with alex-3.5.1.02024-03-25T18:48:57ZShayne Fletchershayne@shaynefletcher.orgRecent lexer perf compile error with alex-3.5.1.0## Summary
[This commit](https://gitlab.haskell.org/ghc/ghc/-/commit/7dfdf3d9fbc216653fe2cf95cc52c35900bdc8b4) yields a Lexer.hs that doesn't compile when using alex-3.5.1.0 (prevailing version on Hackage). Errors look like
```
compile...## Summary
[This commit](https://gitlab.haskell.org/ghc/ghc/-/commit/7dfdf3d9fbc216653fe2cf95cc52c35900bdc8b4) yields a Lexer.hs that doesn't compile when using alex-3.5.1.0 (prevailing version on Hackage). Errors look like
```
compiler/GHC/Parser/Lexer.x:2871:20: error: [GHC-88464]
Data constructor not in scope: C# :: t0 -> Char
Suggested fixes:
• Perhaps use one of these:
‘GHC.Exts.C#’ (imported from GHC.Exts),
‘GHC.Exts.D#’ (imported from GHC.Exts),
‘GHC.Exts.F#’ (imported from GHC.Exts)
• Perhaps you want to add ‘C#’ to the import list in the import of
‘GHC.Exts’
```Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24582Infinite simplifier iteration2024-03-26T15:13:09ZSimon Peyton JonesInfinite simplifier iterationConsider this little program:
```
module Foo(woo) where
foo :: String -> Int -> a
{-# NOINLINE foo #-}
foo s _ = error s
f :: (Int->Int) -> Int
{-# NOINLINE f #-}
f g = g 3
x :: Int -> a
x = foo "urk"
woo = f x
```
When compiling wi...Consider this little program:
```
module Foo(woo) where
foo :: String -> Int -> a
{-# NOINLINE foo #-}
foo s _ = error s
f :: (Int->Int) -> Int
{-# NOINLINE f #-}
f g = g 3
x :: Int -> a
x = foo "urk"
woo = f x
```
When compiling with HEAD we get
```
bash$ ~/code/HEAD/$s1 -c -O -fmax-simplifier-iterations=10 Foo.hs
WARNING:
Simplifier bailing out
Foo, after 10 iterations [12, 2, 2, 2, 2, 2, 2, 2, 2, 2]
Size = {terms: 85, types: 55, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
WARNING:
Simplifier bailing out
Foo, after 10 iterations [46, 3, 3, 3, 3, 3, 3, 3, 3, 3]
Size = {terms: 85, types: 45, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
WARNING:
Simplifier bailing out
Foo, after 10 iterations [3, 3, 3, 3, 3, 3, 3, 3, 3, 3]
Size = {terms: 85, types: 45, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
```
Clearly the Simplifier is not reaching a fixed point.
This is true in HEAD, and goes back to at least GHC 9.6 probably earlier.
## Diagnosis
We end up with
```
s1 = "urk#"
s2 = unpackSString# s1
x = foo s2 -- A partial application, since foo has arity 2
-- but x is bottoming so we don't inline it
```
The Simplifier is
* doing `preInlineUnconditionally` to inline `s1` into `s2`, and `s2` into `x`
* and then ANF-ising the RHS `foo (unpackCString# "urk"#)` to get back what we started with.
The (long-standing) bug is that the `certainly_inline` predicate in `GHC.Core.Opt.OccurAnal.mkNonRecRhsCtxt` is not tracking `preInlineUnconditionally` correctly; see Note [Cascading inlines] in that module. (In this case it is not accounting for the fact that `x` a top-level is bottoming binding.
## Solution
Update `certainly_inline`. It's not very satisfactory that this out-of-sync-ness can
happen but I don't see an easy solution.Simon Peyton JonesSimon Peyton Joneshttps://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/24580rts/ARMOutlineAtomicsSymbols.h does not compile2024-03-26T09:32:20ZGleb Popovrts/ARMOutlineAtomicsSymbols.h does not compileWhen compiling GHC 9.6 with Clang 16 on FreeBSD 14 AArch64 I get a bunch of compilation errors:
```
rts/ARMOutlineAtomicsSymbols.h:15:3: error:
error: address argument to atomic operation must be a pointer to _Atomic type ('uint8_t...When compiling GHC 9.6 with Clang 16 on FreeBSD 14 AArch64 I get a bunch of compilation errors:
```
rts/ARMOutlineAtomicsSymbols.h:15:3: error:
error: address argument to atomic operation must be a pointer to _Atomic type ('uint8_t *' (aka 'unsigned char *') invalid)
atomic_compare_exchange_strong_explicit(p, &old, new, memory_order_relaxed, memory_order_relaxed); return old;
^ ~
|
15 | atomic_compare_exchange_strong_explicit(p, &old, new, memory_order_relaxed, memory_order_relaxed); return old;
| ^
```Cheng ShaoCheng Shaohttps://gitlab.haskell.org/ghc/ghc/-/issues/24579Imports inserted by plugin do not influence topographical module sorting2024-03-27T02:09:53ZtaylorfausakImports inserted by plugin do not influence topographical module sorting## Summary
Sorry, this is a weird one :smile: I'm not sure if it's actually a bug in GHC or just a misunderstanding on my part. I'm looking for clarification from someone who knows more about GHC internals.
I describe the issue in det...## Summary
Sorry, this is a weird one :smile: I'm not sure if it's actually a bug in GHC or just a misunderstanding on my part. I'm looking for clarification from someone who knows more about GHC internals.
I describe the issue in detail here: <https://github.com/tfausak/imp/issues/11>. But long story short, if you use a plugin to insert an import of a module from the same unit, it won't work because the module you're importing won't be loaded. I believe this happens because while plugins can modify the parsed module, when GHC discovers imports it uses the contents of the actual source file before any plugins have a chance to run.
## Steps to reproduce
Define a package like this and try to build it:
``` cabal
-- example.cabal
cabal-version: 3.8
name: example
version: 0
library
build-depends: base, imp
ghc-options: -fplugin=Imp
exposed-modules: A B
```
``` hs
-- A.hs
module A where
mainA = System.IO.print 'a'
```
``` hs
-- B.hs
module B where
mainB = A.mainA
```
## Expected behavior
In the `B` module, I expect the identifier `A.mainA` to work because the Imp plugin inserts `import qualified A`. Instead I get an error like this:
```
B.hs:1:1: error: [GHC-58427]
attempting to use module ‘example-0-inplace:A’ (A.hs) which is not loaded
|
1 | module B where
| ^
Error: cabal: Failed to build example-0.
```
Note that in the `A` module, the identifier `System.IO.print` works because Imp inserts `import qualified System.IO`.
## Environment
* GHC version used: 9.8.2
Optional:
* Operating System: macOS 14.4
* System Architecture: ARM64https://gitlab.haskell.org/ghc/ghc/-/issues/24578Dupe of h$rts_isProfiled2024-03-28T16:16:45ZSerge S. GulinDupe of h$rts_isProfiled## Summary
Commit https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11447/diffs#24e9216fe80fd5aa5c24ea79d3633fb0b2bee7c6_0_17 added a dupe of `h$rts_isProfiled` which was already defined by https://gitlab.haskell.org/ghc/ghc/-/commit/...## Summary
Commit https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11447/diffs#24e9216fe80fd5aa5c24ea79d3633fb0b2bee7c6_0_17 added a dupe of `h$rts_isProfiled` which was already defined by https://gitlab.haskell.org/ghc/ghc/-/commit/08d8e9efa245e87e9c67da73e0987846865671d6#c14e882edb9d4b205929f4f71581a2e43ea05852_334_335
That's one of reasons why Google Closure Compiler does not work in Advanced Optimizations Mode.
## Steps to reproduce
Create Hello-World app like at the wiki page: https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend/building
Try to build it and then pass through google closure compiler.
```
../ghc-js/_build/stage1/bin/javascript-unknown-ghcjs-ghc -fforce-recomp HelloJS.hs
google-closure-compiler --compilation_level ADVANCED_OPTIMIZATIONS ./HelloJS.jsexe/all.js --js_output_file ./HelloJS.jsexe/all.min.js
```
It will show the error:
```
./HelloJS.jsexe/all.js:12611:9: ERROR - [JSC_VAR_MULTIPLY_DECLARED_ERROR] Variable h$rts_isProfiled declared more than once. First occurrence: ./HelloJS.jsexe/all.js:8723:9
12611| function h$rts_isProfiled() {
```
## Expected behavior
Google Closure Compiler does not treat `h$rts_isProfiled` as declared more than once. Better to have it fully working for hello-world, but it requires more scope of work than this pretty trivial change.
## Environment
* GHC version used: #3e0b2b1f14e5e82eaa1dc6fbf8dceb5f539f5aa3
Optional:
* Operating System: MacOS 13.6.3 (22G436)
* System Architecture: Apple M1
# Linked Issues
[Parent] [Size reduction of "hello world" bundle compiled by javascript-backend](https://gitlab.haskell.org/ghc/ghc/-/issues/24584)Serge S. GulinSerge S. Gulinhttps://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/24571Pattern to type transformation doesn't work with TH splices.2024-03-26T15:31:18ZAndrei BorzenkovPattern to type transformation doesn't work with TH splices.## Summary
`pat_to_type_pat` doesn't perform transformation for `SplicePat`, so it is not possible to use TH splices to create a pattern for `forall->`
## Steps to reproduce
```
{-# LANGUAGE TemplateHaskell, RequiredTypeArguments #-}
...## Summary
`pat_to_type_pat` doesn't perform transformation for `SplicePat`, so it is not possible to use TH splices to create a pattern for `forall->`
## Steps to reproduce
```
{-# LANGUAGE TemplateHaskell, RequiredTypeArguments #-}
module T where
g :: forall a -> ()
g $([p| a |]) = () -- Ill-formed type pattern: a_a285
```
## Expected behavior
That should compile.
The fix is straightforward, just a couple lines of code with a new equation in `pat_to_type_pat` function.
```diff
diff --git a/compiler/GHC/Tc/Gen/Pat.hs b/compiler/GHC/Tc/Gen/Pat.hs
index 99ffe6561b..eaf263907d 100644
--- a/compiler/GHC/Tc/Gen/Pat.hs
+++ b/compiler/GHC/Tc/Gen/Pat.hs
@@ -534,6 +534,9 @@ pat_to_type_pat (SigPat _ pat sig_ty)
pat_to_type_pat (ParPat _ pat)
= do { HsTP x t <- pat_to_type_pat (unLoc pat)
; return (HsTP x (noLocA (HsParTy noAnn t))) }
+pat_to_type_pat (SplicePat (HsUntypedSpliceTop mod_finalizers pat) splice) = do
+ { HsTP x t <- pat_to_type_pat pat
+ ; return (HsTP x (noLocA (HsSpliceTy (HsUntypedSpliceTop mod_finalizers t) splice))) }
pat_to_type_pat pat =
-- There are other cases to handle (ConPat, ListPat, TuplePat, etc), but these
-- would always be rejected by the unification in `tcHsTyPat`, so it's fine to
```Andrei BorzenkovAndrei Borzenkovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24570RequiredTypeArguments: unexpected parse error for infix type2024-03-26T15:32:05ZRyan ScottRequiredTypeArguments: unexpected parse error for infix typeI am using GHC 9.10.1-alpha1, which introduces the `RequiredTypeArguments` extension. My understanding is that a visible `forall` can be instantiated with a type (without needing a `type` disambiguator) when the name of the type is unamb...I am using GHC 9.10.1-alpha1, which introduces the `RequiredTypeArguments` extension. My understanding is that a visible `forall` can be instantiated with a type (without needing a `type` disambiguator) when the name of the type is unambiguously in the type syntax. For example, the following works as I would expect, since `(:!@#)` is unambiguously in the type syntax:
```hs
{-# LANGUAGE GHC2024 #-}
{-# LANGUAGE RequiredTypeArguments #-}
module Foo where
import Language.Haskell.TH
idee :: forall a -> a -> a
idee _ x = x
type (:!@#) = Bool
f :: Bool -> Bool
f = idee (:!@#) -- Relies on RequiredTypeArguments to work
```
So far, so good. Now consider what happens if we change the name of the type slightly:
```hs
-- No longer starts with a colon
type (!@#) = Bool
f :: Bool -> Bool
f = idee (!@#)
```
The name has changed to `(!@#)`, but it's still unambiguously in the type syntax. Despite this, GHC no longer accepts the program!
```
$ ghc-9.10 Foo.hs
[1 of 1] Compiling Foo ( Foo.hs, Foo.o )
Foo.hs:14:5: error: [GHC-76037]
• Not in scope: ‘!@#’
• In the expression: idee (!@#)
In an equation for ‘f’: f = idee (!@#)
|
14 | f = idee (!@#)
| ^^^^^^^^^^
```
This error message is very surprising, as `(!@#)` _is_ in scope. Surely this ought to be accepted? At the very least, I didn't see this limitation of `RequiredTypeArguments` mentioned in the [relevant section of the GHC User's Guide](https://gitlab.haskell.org/ghc/ghc/-/blob/cdfe6e01f113dbed9df6703c97207c02fc60303b/docs/users_guide/exts/required_type_arguments.rst).9.10.1https://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/24567Missing preamble from 9.10 release notes2024-03-21T16:32:24ZTeo CamarasuMissing preamble from 9.10 release notes9.8 has a paragraph that goes:
```
The significant changes to the various parts of the compiler are listed in the
following sections. See the `migration guide
<https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8>`_ on the GHC Wiki
f...9.8 has a paragraph that goes:
```
The significant changes to the various parts of the compiler are listed in the
following sections. See the `migration guide
<https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.8>`_ on the GHC Wiki
for specific guidance on migrating programs to this release.
```
It would be good to have something similar for 9.10https://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.8