GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-02-07T17:12:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/22432Wrong documentation for `foldMap`/`foldMap'`?2023-02-07T17:12:56ZkonsumlammWrong documentation for `foldMap`/`foldMap'`?The doc comments for [`foldMap`](https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-Foldable.html#v:foldMap) and [`foldMap'`](https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-Foldable.html#v:foldMap-39-) currently say...The doc comments for [`foldMap`](https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-Foldable.html#v:foldMap) and [`foldMap'`](https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-Foldable.html#v:foldMap-39-) currently say that they're right-associative and left-associative, respectively. However, as I understand it, that should only apply for the default implementations (which are using `foldr` and `foldl'`, respectively).
The point of `foldMap`/`foldMap'` (and `Monoid`s in general) is that `<>`/`mappend` is associative, so it doesn't make sense to me to enforce that they need a specific associativity. Additionally, if they always had to be right-/left-associative, I don't see why they should be class methods, since I don't think there would be a better implementation than the default one.https://gitlab.haskell.org/ghc/ghc/-/issues/22429MacOS ld warning: -undefined dynamic_lookup may not work with chained fixups2024-03-22T10:44:17ZBrandon ChinnMacOS ld warning: -undefined dynamic_lookup may not work with chained fixupsGetting a linker warning after upgrading to MacOS Monterey (12.6). Repro steps:
1. Create empty `Bar.hs` module (`module Bar where`)
2. Run `ghc -shared Bar.hs`
```
[1 of 1] Compiling Bar ( Bar.hs, Bar.o )
Linking a.out .....Getting a linker warning after upgrading to MacOS Monterey (12.6). Repro steps:
1. Create empty `Bar.hs` module (`module Bar where`)
2. Run `ghc -shared Bar.hs`
```
[1 of 1] Compiling Bar ( Bar.hs, Bar.o )
Linking a.out ...
ld: warning: -undefined dynamic_lookup may not work with chained fixups
```
Artifacts still seem to work, but it would be nice to resolve (or hide?) the warning.
From the man page:
```
-undefined treatment
Specifies how undefined symbols are to be treated. Options are: error, warning,
suppress, or dynamic_lookup. The default is error. Note: dynamic_lookup that
depends on lazy binding will not work with chained fixups.
```9.6.1Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22412Feature Idea: Conflict Marker detection and reporting in source files2022-11-23T17:16:54ZHécate MoonlightFeature Idea: Conflict Marker detection and reporting in source filesAs so helpfully pointed out by @phadej, Clang is able to produce a helpful report when detecting version control conflict markers in a source file:
![image](/uploads/328b67b663a49536a8f2408d0244bb5f/image.png)
I believe it would be a w...As so helpfully pointed out by @phadej, Clang is able to produce a helpful report when detecting version control conflict markers in a source file:
![image](/uploads/328b67b663a49536a8f2408d0244bb5f/image.png)
I believe it would be a welcome addition from our users, and would certainly help with GHC's reputation to the general public.
Here are relevant links from the clang source file:
* [Lexer.cpp#L4028-L4032](https://github.com/llvm/llvm-project/blob/369899449226a00f15422a12aacb62dee312c8d5/clang/lib/Lex/Lexer.cpp#L4028-L4032)
* [Lexer.h#L42-L55](https://github.com/llvm/llvm-project/blob/369899449226a00f15422a12aacb62dee312c8d5/clang/include/clang/Lex/Lexer.h#L42-L55)
* [Lexer.cpp#L3077-L3156](https://github.com/llvm/llvm-project/blob/2e999b7dd1934a44d38c3a753460f1e5a217e9a5/clang/lib/Lex/Lexer.cpp#L3077-L3156)
* [DiagnosticLexKinds.td#L97](https://github.com/llvm/llvm-project/blob/2e999b7dd1934a44d38c3a753460f1e5a217e9a5/clang/include/clang/Basic/DiagnosticLexKinds.td#L97)https://gitlab.haskell.org/ghc/ghc/-/issues/22401Plugin-Swappable Parser2022-11-14T10:49:08ZKai-Oliver ProttPlugin-Swappable Parser*I originally started writing this as a GHC proposal, but apparently Plugin-API changes do not need one. This is a work-in-progress. Feedback welcome*
*Update 1:* Added 2 parameters to the function in `ReplacementParser`.
# Plugin-Swa...*I originally started writing this as a GHC proposal, but apparently Plugin-API changes do not need one. This is a work-in-progress. Feedback welcome*
*Update 1:* Added 2 parameters to the function in `ReplacementParser`.
# Plugin-Swappable Parser
For many people in the community, GHC plugins are a quick and easy way to extend the compiler with additional features or to prototype implementations.
While plugins allow their author to transform or analyze a module as well as changing the (type) constraint solver, it is currently not possible to change the static syntax accepted by GHC.
I propose to make the parser implementation replaceable using a GHC plugin. This way, a plugin author can not only change the semantics, but also the accepted syntax for a module.
## Motivation
At the moment, the only way to use different syntax in a Haskell module is to use quasiquotation.
However, this leads to some ugly code without any support from IDEs.
In the case that someone just wants to alter GHC's accepted syntax in a tiny way, this is unsatisfactory.
By replacing the parser using a plugin, most syntax highlighter will keep working even when a definition contains a new keyword.
Other features of an IDE might also continue working, such as hovering over a definition to see its type.
This is not possible if the full definition was created by a quasi quoter.
I can see different use cases for such a parser plugin.
1. Using GHC to implement Haskell-adjacent languages. In my case, I am trying to implement Curry using GHC, a language that uses Haskell's syntax with a few modifications (new keyword for example). Maybe the people working on Mu (Haskell dialect from Standard Chartered) would be interested in this as well.
2. Prototyping proposed, syntactic changes to GHC. Many GHC proposals introduce new syntax. I am not very familiar with the process of implementing a proposal, but I could imagine that it would be useful to prototype an implementation to test syntactic changes without re-building the compiler every time.
3. Restricting the syntax accepted by GHC for teaching.
Racket offers [different languages specifically for teaching](https://docs.racket-lang.org/drracket/htdp-langs.html).
These restrict the language to certain features, depending on the level, to make it easier to use for beginners.
At the moment, Haskell can be overwhelming for beginner students.
Having a way to restrict the language can help with that.
Although the current plugin infrastructure might be enough to implement a purely restrictive change.
## Proposed Change Specification
I propose to augment the `Plugin` data type as follows:
```haskell
data Plugin = Plugin {
-- keep all current constructors
, parserPlugin :: ParserPlugin
}
type ParserPlugin = [CommandLineOption] -> ParserSpecification
data ParserSpecification = DefaultParser -- ^ Do not replace the parser
| ReplacementParser (DynFlags -> RealSrcLoc -> StringBuffer -> ParseResult ParsedModule) -- ^ Replace the parser with the given function.
```
Here, `DynFlags`, `RealSrcLoc`, `StringBuffer` and `ParseResult` are currently used by GHC's parser and my proposal does not affect them.
We need all of these parameters to at least be able to use GHC's own parser in a plugin.
As long as none of the plugins active for a module uses the `ReplacementParser` constructor, nothing special happens.
When more than one plugin specifies a `ReplacementParser`, compilation is aborted with an error.
We can only replace the parser with a single definiton , so having two plugins specifying different parsers is a problem and we should abort.
In the case that exactly one plugin specifies a new parser to be used, the module is parsed according to the function given in the `ReplacementParser` constructor.
Note that the new parser still has to use GHC's current AST representation for its output.
Thus, any plugin has to transform its own syntax to fit into the current AST.
When a GHC (error) message refers back to these transformed sections, e.g. in a type error, it should continue using the existing `SrcLoc` (and friends) annotations.
Any plugin author can decide to give meaningful source locations and fix any error messages via different mechanisms, if desired.
## Effect and Interactions
The effect of a replaceable parser is that it allows a plugin author to modify the syntax accepted by GHC.
This increases the flexibility and usability of GHC as a compiler tool.
I am not involved in GHC development, so it is hard for me do imagine any interactions with this feature.
However, I will extend this section with any interactions from the comments.
## Costs and Drawbacks
I estimate that the cost of this change is relatively low, since it is only concerned with a small part of the compiler.
The change is also backwards compatible and should have a low maintenance cost.
Drawbacks:
- Completely replacing the parser does not compose when using multiple parser plugins as mentioned before. Adopting this solution makes it harder to reach a composable solution without being backwards-incompatible. However, I do not believe that there will be a better solution in the foreseeable future.
- *To be extended*
## Alternatives
I can imagine that a parser based on parser combinators (i.e. not using Happy) is easier to extend with a plugin. Thus, one alternative could be to replace the current parser implementation with an implementation based on parser combinators. At each syntax rule, the parser could then look at all active parser plugins and try any parsing combinators as an alternative.
Such a solution would compose better with multiple plugins, but it would incur a significant implementation and maintenance burden for a small benefit.
Additionally, the performance of the parser will probably suffer as well.
## Unresolved Questions
- Should a plugin be allowed to change the syntax of the module header and pragmas at the top of a module? Often, a plugin is activated per-module using `OPTIONS_GHC`. Specifying a plugin that alters the parsing of the header in the header itself is pretty weird.
- Should the GHC AST be adapted to accommodate plugin-parsed syntax by adding a constructor that behaves similarly as the `HsExpansion` data type?
E.g.
```haskell
data HsPluginExpansion a = HsPluginExpansion String a
^ -- original source plus generated AST`
```
This makes the changes more involved and the new data type would need to be added in many places in the AST.
I do not really see the benefit, since GHC currently uses the original source code text to show the source in error messages (if i remember correctly...).
## Implementation Plan
I could implement this, but would probably need some guidance.Kai-Oliver ProttKai-Oliver Protthttps://gitlab.haskell.org/ghc/ghc/-/issues/22400Strings and info tables allocated by the bytecode compiler are never freed2023-08-23T16:16:08ZAlexis KingStrings and info tables allocated by the bytecode compiler are never freedThe bytecode compiler uses `malloc` to allocate memory for string literals and `allocateExecPage` (from the RTS) to allocate memory for data constructor info tables. This memory is never freed, so if the associated BCOs are unloaded, it ...The bytecode compiler uses `malloc` to allocate memory for string literals and `allocateExecPage` (from the RTS) to allocate memory for data constructor info tables. This memory is never freed, so if the associated BCOs are unloaded, it just leaks.
GHC already takes some care to ensure that this memory is only allocated when bytecode is compiled, not when it is linked, so the same BCO can be relinked arbitrarily many times without having to reallocate memory. However, the memory does, of course, need to be reallocated when a BCO is recompiled. For most modules, the leaked memory is probably relatively small, but it is not entirely uncommon for programmers to embed arbitrarily-large string literals into their programs using Template Haskell (see the [file-embed](https://hackage.haskell.org/package/file-embed) package), so in general this is not a trivial issue.
In https://gitlab.haskell.org/ghc/ghc/-/issues/22376#note_461080, I initially wrote that freeing this data seemed essentially impossible, as string literals are represented as `Addr#` pointers, which are not GC-managed. However, I think this may have been unnecessarily conservative: we support unloading `.o` files when using a statically-linked GHC, which suggests dropping these pointers is at least supposed to work, presumably because GHCi takes care to throw away any closures derived in any way from the unloaded objects. Unfortunately, I’m not familiar enough with all the ways unloading can occur to say for certain whether that’s completely safe in general.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/22384Visible type application in record patterns2022-11-01T08:49:22ZTarmeanVisible type application in record patterns## Motivation
I've been using type applications in patterns quite a bit recently and struggled when adding or removing an argument from the constructors because all pattern matches must add/remove wildcards.
```haskell
lookupQMap :: fo...## Motivation
I've been using type applications in patterns quite a bit recently and struggled when adding or removing an argument from the constructors because all pattern matches must add/remove wildcards.
```haskell
lookupQMap :: forall a. Typeable a => QKey a -> QMap -> Maybe a
lookupQMap qid qmap =
-- This could use a Data.Typeable.cast, but it's simplified from some more complex code
case lookupQ qid qmap of
ResultEntry @r' dat _
| Just Refl <- eqT @r @r' -> ...
```
The nice way to avoid the problem would be to use record patterns. But mixing type applications with record patterns results in a parse error!
```haskell
case lookupQ qid qmap of
ResultEntry @r {resultData=dat}
-- [parser] [E] parser error on input '{'
```
I'm not sure if this is intentional, an oversight, or whether I'm missing the right syntax. It'd be really useful, though!
## Proposal
If the missing syntax is an oversight it hopefully could be added without making the grammar overly ambiguous. I do not know whether this would require a separate proposal.
If the feature already exists or is intentionally missing it maybe could be documented somewhere, though I'm not sure what the right place would be. I couldn't find a mention in the proposal or paper at least.https://gitlab.haskell.org/ghc/ghc/-/issues/22382Improve Error message when field is missing on actual Haskell record2023-06-23T12:28:19ZMagnus ViernickelImprove Error message when field is missing on actual Haskell record<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
When having `-XOverloadedRecordDots` on and writing the following code
```haskell
data R = MkR
{ ri :: Int
, rs :: String
}
x :: R -> Bool
x r = r.rb
```
I get the following error message
```
• No instance for (GHC.Records.HasField "rb" R Bool)
arising from selecting the field ‘rb’
• In the expression: r.rb
In an equation for ‘x’: x r = r.rb
|
97 | x r = r.rb
| ^^^^
```
which is arguably too confusing if you just want to use this extension for allowing the record dot syntax.
## Proposal
As this is a Haskell record the error message could just have been "The Haskell record `R` does not have the field `rb`" which is in my opinion easier to decipher for users who don't want to use the actual overloading of the record dot. As it's possible to also declare `HasField` instances for some specific field name (`HasField "rb" R Bool`) it would probably be good to nevertheless include a NB that this error results from a missing `HasField` instance.
I would like to implement this my own, if this was accepted, but I'm new so guidance would be appreciated :smile:
Thanks in advance!https://gitlab.haskell.org/ghc/ghc/-/issues/22326Visible forall in types of terms, Part 12023-07-24T17:53:16ZVladislav ZavialovVisible forall in types of terms, Part 1[GHC Proposal #281: Visible forall in types of terms](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst) is presented in two parts:
1. Part 1 introduces the `forall a ->` quantifier in types of...[GHC Proposal #281: Visible forall in types of terms](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst) is presented in two parts:
1. Part 1 introduces the `forall a ->` quantifier in types of terms but also requires a syntactic marker at use sites.
2. Part 2 specifies when it is permissible to omit the `type` herald.
This issue is to track the implementation of Part 1 only. Here are a few examples of code that we aim to allow:
* A variant of `id` that uses visible `forall`:
```haskell
-- Definition:
idv :: forall a -> a -> a
idv (type a) x = x :: a
-- Usage:
n = idv (type Double) 42
```
This is equivalent to `n = (42 :: Double)`.
* A wrapper around `typeRep` that uses visible `forall`:
```haskell
-- Definition:
typeRepVis :: forall a -> Typeable a => TypeRep a
typeRepVis (type a) = typeRep @a
-- Usage:
t = typeRepVis (type (Maybe String))
```
* A wrapper around `sizeOf` that uses visible `forall` instead of `Proxy`:
```haskell
-- Definition:
sizeOfVis :: forall a -> Storable a => Int
sizeOfVis (type a) = sizeOf (undefined :: a)
-- Usage:
n = sizeOfVis (type Int)
```
* A wrapper around `symbolVal` that uses visible `forall` instead of `Proxy`:
```haskell
-- Definition:
symbolValVis :: forall s -> KnownSymbol s => String
symbolValVis (type s) = symbolVal (Proxy :: Proxy s)
-- Usage
str = symbolValVis (type "Hello, World")
```9.10.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/22266Source shown in error messages can be wrong if file changes during compilation2024-02-21T13:50:13ZMichael Peyton JonesSource shown in error messages can be wrong if file changes during compilation## Summary
Sometimes the source shown in an error message can be wrong (too new) if the file is changed during compilation.
Example:
```
src/PlutusTx/AssocMap.hs:242:55: error: ...## Summary
Sometimes the source shown in an error message can be wrong (too new) if the file is changed during compilation.
Example:
```
src/PlutusTx/AssocMap.hs:242:55: error:
• Expecting two more arguments to ‘Map’
Expected a type, but ‘Map’ has kind ‘* -> * -> *’
• In the fourth argument of ‘PlutusTx.LiftU’, namely ‘Map’
In the stand-alone deriving instance for
‘PlutusTx.LiftU name uni fun Map’
|
242 | deriving newtype instance PlutusTx.LiftU name uni fun (Map k v)
| ^^^
```
I added the `k` and `v` parameters while the compilation was happening.
You can see that the source is wrong (it contains `k` and `v`), and caret (and the highlight) is in the wrong place (corresponding to the old source, I guess). I think the error is using the source location from the file at the _start_ of compilation, but reading the file back when the error is _reported_ to make the final message.
This is a bit of an edge case so it's probably not worth that much effort to fix!
## Steps to reproduce
1. Start compiling a file with an error in.
2. Edit the line with the error in before compilation finishes.
3. Observe that the wrong source appears.
## Expected behavior
I think the most reasonable behaviour is to show the source as it was when compilation began. This may require reading it in at that point and saving it until error reporting is done.
## Environment
* GHC version used: 8.10.7https://gitlab.haskell.org/ghc/ghc/-/issues/22254getLevity allocates too much for what it does.2022-11-22T10:04:58ZAndreas KlebingergetLevity allocates too much for what it does.Looking at a ghc profile I noticed that `getLevity` was accountable for about 0.5% of all allocations for an -O2 build. Which seemed far too high.
After a brief chat with @sheaf we noticed that its call to splitTyConApp_maybe was alloca...Looking at a ghc profile I noticed that `getLevity` was accountable for about 0.5% of all allocations for an -O2 build. Which seemed far too high.
After a brief chat with @sheaf we noticed that its call to splitTyConApp_maybe was allocating a lot of intermediate data structures that were not really needed by the use in getLevity.
I will post a patch with the perf improvement shortly.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/22250stimesDefault, stimesIdempotent etc throw exception on Integral types without...2023-03-15T20:15:31ZOleg GrenrusstimesDefault, stimesIdempotent etc throw exception on Integral types without a zero.For example
```haskell
data BinP -- also called Pos
= BE
| B0 BinP
| B1 BinP
```
like in [`bin`](https://hackage.haskell.org/package/bin) package or just
```haskell
newtype Natural1 = N1 Natural
instance Integral N1 where...For example
```haskell
data BinP -- also called Pos
= BE
| B0 BinP
| B1 BinP
```
like in [`bin`](https://hackage.haskell.org/package/bin) package or just
```haskell
newtype Natural1 = N1 Natural
instance Integral N1 where
toInteger (N1 n) = 1 + toInteger n
```
With these
```
*Data.Bin Data.Semigroup> stimes (1 :: Integer) "foo"
"foo"
*Data.Bin Data.Semigroup> stimes (2 :: Integer) "foo"
"foofoo"
*Data.Bin Data.Semigroup> stimes (3 :: Integer) "foo"
"foofoofoo"
*Data.Bin Data.Semigroup> stimes (1 :: BinP) "foo"
"*** Exception: arithmetic underflow
*Data.Bin Data.Semigroup> stimes (2 :: BinP) "foo"
"*** Exception: arithmetic underflow
*Data.Bin Data.Semigroup> stimes (3 :: BinP) "foo"
"*** Exception: arithmetic underflow
```
The `stimesDefault` is defined as
```haskell
stimesDefault :: (Integral b, Semigroup a) => b -> a -> a
stimesDefault y0 x0
| y0 <= 0 = errorWithoutStackTrace "stimes: positive multiplier expected"
| otherwise = f x0 y0 where f ...
```
but I think it can be as well defined as
```haskell
stimesDefault :: (Integral b, Semigroup a) => b -> a -> a
stimesDefault y0 x0
| y0 >= 1 = f x0 y0 where ...
| otherwise = errorWithoutStackTrace "stimes: positive multiplier expected"
```
and similarly for `stimesIdempotent`
Fixing `mtimesDefault` would be trickier as it is defined as
```haskell
stimesIdempotentMonoid :: (Integral b, Monoid a) => b -> a -> a
stimesIdempotentMonoid n x = case compare n 0 of
LT -> errorWithoutStackTrace "stimesIdempotentMonoid: negative multiplier"
EQ -> mempty
GT -> x
```
and using `compare` is probably very welcome, although for types people care about, like `Int` or `Integer`, or even `BinP` or `Natural/1`, having `n >= 1` first case is probably a win.https://gitlab.haskell.org/ghc/ghc/-/issues/22249Empty array primitives2023-03-10T15:58:53ZkonsumlammEmpty array primitives## Motivation
Currently, there is no way to create an empty array without a value of the element type, since the only primitive to create a new array is `newArray#`, which requires an element. For lifted element types, this is no proble...## Motivation
Currently, there is no way to create an empty array without a value of the element type, since the only primitive to create a new array is `newArray#`, which requires an element. For lifted element types, this is no problem, since you can use a bottom as a dummy element, but that doesn't work for unlifted types.
## Proposal
I propose adding two new primitives:
```hs
emptyArray# :: forall {l :: Levity} (a :: TYPE (BoxedRep l)). Array# a
emptSmallyArray# :: forall {l :: Levity} (a :: TYPE (BoxedRep l)). SmallArray# a
```
This should be enough, since you can also use them to create empty mutable arrays (by using `thawArray#`/`thawSmallArray#`). One could also go the other way round, adding primitives to create mutable empty arrays instead, but I'd argue that empty immutable arrays are more common (e.g. `primitive` has [`emptyArray`](https://hackage.haskell.org/package/primitive-0.7.4.0/docs/src/Data.Primitive.Array.html#emptyArray), but no `emptyMutableArray`). It might still be beneficial to additionally add primitives for empty mutable arrays though.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/22205Can't build GHC: missing or private dependencies2022-10-01T11:45:25ZRichard Eisenbergrae@richarde.devCan't build GHC: missing or private dependenciesStill can't build GHC:
```
rae:23:08:59 ~/ghc/ghc-spj> hadrun
--build-root=_build --flavour=default -j9 --flavour=devel2 --docs=none
Up to date
| Configure package 'unix'
| Configure package 'integer-gmp'
| Configure package 'text'
| Co...Still can't build GHC:
```
rae:23:08:59 ~/ghc/ghc-spj> hadrun
--build-root=_build --flavour=default -j9 --flavour=devel2 --docs=none
Up to date
| Configure package 'unix'
| Configure package 'integer-gmp'
| Configure package 'text'
| Configure package 'ghc-heap'
| Configure package 'ghc-compact'
| Configure package 'pretty'
| Configure package 'ghc-boot'
| Configure package 'directory'
| Configure package 'process'
| Configure package 'hpc'
| Configure package 'Cabal'
| Configure package 'base'
| Configure package 'binary'
| Configure package 'Cabal-syntax'
| Configure package 'ghci'
| Configure package 'array'
| Configure package 'unix'
| Configure package 'transformers'
| Configure package 'template-haskell'
| Configure package 'bytestring'
| Configure package 'Cabal-syntax'
| Configure package 'time'
| Configure package 'hpc'
| Configure package 'directory'
| Configure package 'ghc-prim'
| Configure package 'exceptions'
| Configure package 'haskeline'
| Configure package 'deepseq'
| Configure package 'terminfo'
| Configure package 'xhtml'
| Configure package 'rts'
| Configure package 'parsec'
| Configure package 'ghc-boot-th'
| Configure package 'ghc-boot'
| Configure package 'containers'
| Configure package 'stm'
| Configure package 'Cabal'
| Configure package 'libiserv'
| Configure package 'mtl'
| Configure package 'ghc-bignum'
| Configure package 'parsec'
| Configure package 'text'
| Configure package 'filepath'
| Configure package 'process'
| Configure package 'ghci'
| Configure package 'ghc'
| Configure package 'ghc'
| Copy package 'linters-common'
# cabal-copy (for _build/stageBoot/lib/package.conf.d/linters-common-0.1.0.0.conf)
# cabal-configure (for _build/stage0/libraries/unix/setup-config)
# cabal-configure (for _build/stage0/libraries/text/setup-config)
| Run Ghc FindHsDependencies (Stage0 InTreeLibs): libraries/binary/src/Data/Binary.hs (and 8 more) => _build/stage0/libraries/binary/.dependencies.mk
| Run GhcPkg Recache (Stage0 GlobalLibs): none => none
hadrian: Encountered missing or private dependencies:
base (>=4.9 && <5) && <0
ExitFailure 1
Build failed.
hadrian-util: Received ExitFailure 1 when running
Raw command: /Users/rae/ghc/ghc-spj/hadrian/build-cabal --build-root=_build --flavour=default -j9 --flavour=devel2 --docs=none
Run from: /Users/rae/ghc/ghc-spj
```
The `hadrun` at the top is an alias for Ben's hadrian-util script:
```
rae:23:09:02 ~/ghc/ghc-spj> alias hadrun
alias hadrun='hadrian-util run -j$THREADS --flavour=$GHC_FLAVOUR --docs=none'
```
where `$THREADS` is 9 and `$GHC_FLAVOUR` is `devel2`.
I'm on macOS 12.3.1 on an M1 Mac. My bootstrap GHC is 9.2.1, which is generally working for other projects.https://gitlab.haskell.org/ghc/ghc/-/issues/22185Avoiding head and tail in GHC codebase2023-04-01T17:11:38ZBodigrimAvoiding head and tail in GHC codebaseI'm investigating feasibility of adding a `{-# WARNING #-}` to `Data.List.{head,tail}`, which is a subject of https://github.com/haskell/core-libraries-committee/issues/87. Before moving forward with the proposal, I'd like to learn what ...I'm investigating feasibility of adding a `{-# WARNING #-}` to `Data.List.{head,tail}`, which is a subject of https://github.com/haskell/core-libraries-committee/issues/87. Before moving forward with the proposal, I'd like to learn what kind of burden it puts over developers.
GHC codebase is extensive, old and uses `head` a lot, which makes it a perfect candidate for investigation. If I (presumably, singlehandedly) succeed in eliminating all use cases of `head` and `tail`, it will be a strong argument in favor of the proposal. If I don't succeed - well, at least, we end up with less partiality in GHC, which is good anyway. I'm gonna submit small, limited in surface PRs, gradually moving to the goal.
Upd.: CLC has approved the proposal.https://gitlab.haskell.org/ghc/ghc/-/issues/22145Allow promotion of one-to-one pattern synonyms2022-09-06T13:36:09ZOleg GrenrusAllow promotion of one-to-one pattern synonyms```haskell
{-# LANGUAGE PatternSynonyms, DataKinds #-}
import Data.Proxy
import Data.Kind
pattern JustJust :: a -> Maybe (Maybe a)
pattern JustJust x = Just (Just x)
p :: Proxy (JustJust Type)
p = Proxy
```
is rejected because of
``...```haskell
{-# LANGUAGE PatternSynonyms, DataKinds #-}
import Data.Proxy
import Data.Kind
pattern JustJust :: a -> Maybe (Maybe a)
pattern JustJust x = Just (Just x)
p :: Proxy (JustJust Type)
p = Proxy
```
is rejected because of
```
• Pattern synonym ‘JustJust’ cannot be used here
(pattern synonyms cannot be promoted)
```
but I don't see why not.
This issue allows to distinguish between pattern synonym and real constructor, e.g. a pattern synonym like
```haskell
pattern Some :: a -> Maybe a
pattern Some x = Just x
```
cannot be used to provide backwards compatibility when renaming constructors! (e.g. upcoming `Solo` to `MkSolo` is a real example).https://gitlab.haskell.org/ghc/ghc/-/issues/22104Error message UX around CUSKs and GHC20212023-08-09T18:16:25ZparsonsmattError message UX around CUSKs and GHC2021`GHC2021` does not enable `CUSKs`, like `Haskell2010` did, and so a common pattern of use will have a mysterious error message.
Consider the following module:
```haskell
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module ...`GHC2021` does not enable `CUSKs`, like `Haskell2010` did, and so a common pattern of use will have a mysterious error message.
Consider the following module:
```haskell
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Main where
type family T (a :: k) :: k where
T Char = Int
T a = a
main = pure ()
```
With GHC 9.0, this compiles fine:
```
λ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.0.1
λ ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Linking Main ...
```
If you upgrade to GHC 9.2, then this fails:
```
λ ghcup set ghc 9.2.4
[ Info ] GHC 9.2.4 successfully set as default version
λ ghc --make Main.hs
[1 of 1] Compiling Main ( Main.hs, Main.o )
Main.hs:8:5: error:
• Expected kind ‘k’, but ‘Char’ has kind ‘*’
• In the first argument of ‘T’, namely ‘Char’
In the type family declaration for ‘T’
|
8 | T Char = Int
| ^^^^
λ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.4
```
The `cabal` file specifies `default-language: Haskell2010`, and so `cabal build` works, while `ghc --make` does not.
However, suppose a project switches from `Haskell2010` to `GHC2021`. They'll receive those confusing error messages. I was able to diagnose this by diffing the `cabal build --verbose` to get the `ghc` invocation from `cabal`, and noticed the `-XHaskell2010` flag passed in. I checked to see what that implied, and fortunately `CUSKs` was the first extension, which is the culprit.
I've never heard of `CUSKs`, since it's an implied feature in the language for the entire time that I've been using it. So I had no idea that I needed an extension at all to get this behavior.
Since `CUSKs` are on the Path to Deprecation and Removal, it'd be *great* if we could get an informative error message about the situation.
```
λ ghc --make Main.hs
[1 of 2] Compiling Main ( Main.hs, Main.o )
Main.hs:8:5: error:
• Expected kind ‘k’, but ‘Char’ has kind ‘*’
• In the first argument of ‘T’, namely ‘Char’
In the type family declaration for ‘T’
• The language extension `CUSKs` may fix this behavior,
but it will soon been deprecated in favor of `StandaloneKingSignatures`.
|
8 | T Char = Int
| ^^^^
```sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22061Lessons to be learned from the paper: Investigating Magic Numbers: Improving ...2023-09-07T11:04:14ZAndreas KlebingerLessons to be learned from the paper: Investigating Magic Numbers: Improving the Inlining Heuristic in the Glasgow Haskell CompilerThe paper [Investigating Magic Numbers: Improving the Inlining Heuristic in the Glasgow Haskell Compiler](https://michel.steuwer.info/#publications) by Hollenbeck, O'Boyle, and Steuwer (Haskell Symposium 2022) applied search to the param...The paper [Investigating Magic Numbers: Improving the Inlining Heuristic in the Glasgow Haskell Compiler](https://michel.steuwer.info/#publications) by Hollenbeck, O'Boyle, and Steuwer (Haskell Symposium 2022) applied search to the parameter space of the inliner and seems to have found quite impressive improvements.
In particular the paper found a set of inlining magic numbers which achieves a 12% speedup over the defaults of ghc-8.10.3 for the testsuites of 10 particular packages.
To me the obvious questions not answered in the paper are:
* **Compile Times.** There is no mention of compile times at all in the paper. It's generally accepted among ghc devs that being more lenient with inlining would improve runtime performance at the cost of increased compile time. If we want to change the set of magic inlining numbers we need to characterize not just the runtime but also compile time differences and make a informed decision based on the full picture.
* **nofib vs package tests.** The paper heavily criticizes nofib on a number of points (some warranted, some not) and comes up with quite a clever alternative to benchmarking. I'm not sure if it's feasible to maintain a benchmark suite based on the principles in the paper for ghc.
It would be quite informative to compare the results between their benchmarking approach and nofib. At the very least this should give us a good idea how stable these results are between different ways of evaluation.
If nofib and these packages give use very different results the next question would be if this set of packages is more (or less) representative of typical haskell code. But that's a whole other question which isn't easy to answer at all.
* **Reproduction**. In general it would be good to try to reproduce their results at least on nofib with one or multiple recent versions of ghc. But reproducing their methodology with newer versions of GHC would also be nice. Things often change between versions and it would be interesting to see how stable these results are between ghc and maybe even package versions and if they are still as beneficial for 9.4/master.9.12.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/21843Give a better error for code corrupted by smart quotes2023-08-21T04:18:53ZJoseph C. SibleGive a better error for code corrupted by smart quotes## Motivation
Consider this invalid code:
```
badString = “hello”
badChar = ‘x’
```
The errors we give for it are `lexical error at character 'h'` and `lexical error at character 'x'`. Unless you can see that those are surrounded by sma...## Motivation
Consider this invalid code:
```
badString = “hello”
badChar = ‘x’
```
The errors we give for it are `lexical error at character 'h'` and `lexical error at character 'x'`. Unless you can see that those are surrounded by smart quotes in your code, and already know that smart quotes are a problem, that error won't be helpful.
## Proposal
I propose that we give an error explicitly pointing out the smart quotes and saying they're not real quotes (similar to [what Rust does](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=057b0be9dd6bc57c240e27eaef529ad2): `Unicode characters '“' (Left Double Quotation Mark) and '”' (Right Double Quotation Mark) look like '"' (Quotation Mark), but are not`).https://gitlab.haskell.org/ghc/ghc/-/issues/21826Import error message for a type operator should suggest type keyword2023-06-14T10:17:19Zsheafsam.derbyshire@gmail.comImport error message for a type operator should suggest type keywordI needed to import `(~)` from `Data.Type.Equality`, after the introduction of the `-Wtype-equality-out-of-scope` warning.
However, I tried to write
```haskell
import Data.Type.Equality ( (~) )
```
instead of:
```haskell
import Data.T...I needed to import `(~)` from `Data.Type.Equality`, after the introduction of the `-Wtype-equality-out-of-scope` warning.
However, I tried to write
```haskell
import Data.Type.Equality ( (~) )
```
instead of:
```haskell
import Data.Type.Equality ( type (~) )
```
This caused the rather inscrutable error message:
```
error:
Module `Data.Type.Equality' does not export `(~)'
```
I think it would be much better if the error message noticed that there was a type operator by that name exported by `Data.Type.Equality`, and mentioned that I might have meant to use the `type` keyword to refer to it.https://gitlab.haskell.org/ghc/ghc/-/issues/21806Example in ghc doc for SAKS doesn't work2022-07-29T11:00:01ZGeorgi LyubenovExample in ghc doc for SAKS doesn't workNot sure if this is a bug or a documentation issue, but an example from the [ghc docs on SAKS](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/poly_kinds.html#standalone-kind-signatures-and-declaration-headers) doesn'...Not sure if this is a bug or a documentation issue, but an example from the [ghc docs on SAKS](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/exts/poly_kinds.html#standalone-kind-signatures-and-declaration-headers) doesn't compile:
```haskell
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE KindSignatures #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
import Data.Kind
type GProx4 :: k -> Type
data GProx4 :: w where MkGProx4 :: GProx4 a
```
```sh
[nix-shell:~]$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 9.2.2
[nix-shell:~]$ ghci /tmp/asdf.hs
GHCi, version 9.2.2: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/googleson78/.ghci
[1 of 1] Compiling Main ( /tmp/asdf.hs, interpreted )
/tmp/asdf.hs:10:1: error:
• Couldn't match expected kind ‘w’ with actual kind ‘k -> *’
• In the data type declaration for ‘GProx4’
|
10 | data GProx4 :: w where MkGProx4 :: GProx4 a
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
>
```sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.com