GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-19T14:42:24Zhttps://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/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/24543improve documentation of :doc and -haddock2024-03-19T15:14:03Zjwaldmannimprove documentation of :doc and -haddockI was preaching about `:doc` but people said "what? does not work here".
Of course it works for me since I have ghc option `-haddock` in my global cabal config since forever.
`ghci` does the right thing (it prints `Try re-compiling wi...I was preaching about `:doc` but people said "what? does not work here".
Of course it works for me since I have ghc option `-haddock` in my global cabal config since forever.
`ghci` does the right thing (it prints `Try re-compiling with '-haddock'.`) but GHC documantation feels incomplete:
* documentation for `-haddock` says what is happening (parse Haddock comments and include them in the interface file) but does not say why I should want this https://downloads.haskell.org/ghc/latest/docs/users_guide/using.html#ghc-flag--haddock
* documentation for `:doc` does not say that it needs these interface files, and sounds vague and dated ("experimental, might change with GHC 8.8") https://downloads.haskell.org/ghc/latest/docs/users_guide/ghci.html#ghci-cmd-:doc
(for context, https://club.tidalcycles.org/t/where-are-n-and-notes-documented/5109/8 )
... Can we just make `-haddock` the default in ghc? (I am not sure about implications - interface size and compile time might go up). Global `-haddock` was a bit risky before GHC version 9 (?) since it would occasionally refuse to generate code when a haddock comment was malformed. But I've never seen such an error recently.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24521Some Addr#, (Mutable)ByteArray# primops do not note mutability expectations2024-03-14T21:44:21ZBen OrchardSome Addr#, (Mutable)ByteArray# primops do not note mutability expectationsOne group of primops exported by GHC.Exts are the `index<primty>OffAddr# :: Addr# -> Int# -> <primty>` functions.
Their type signatures were somewhat surprising to me-- how are we to read from an address without some sort of state tracki...One group of primops exported by GHC.Exts are the `index<primty>OffAddr# :: Addr# -> Int# -> <primty>` functions.
Their type signatures were somewhat surprising to me-- how are we to read from an address without some sort of state tracking?
The Haddock docstrings state "Read a (pretty type description); offset in (type size in bytes) words."
This docstring is shared with the associated `read<primty>OffAddr# :: Addr# -> Int# -> State# d -> (# State# d, <primty> #)` function.
These primops are for reading from immutable non-GC-managed addresses. I eventually gathered so from some documentation in GHC.Prim,
which explains what the index, read and write primops do in the context of `ByteArray#`s. On a closer look, there are notes on whether a given primop works with immutable or mutable memory, but these are inconsistently applied, and no `Addr#` primops make any reference.
I think primops that access the contents of some pointer (`Addr#`, `MutableByteArray#` or `ByteArray#`) should note the mutability of the memory they're accessing. This is potentially "obvious" for the latter two, but easily confusing for `Addr#` access primops which aren't explained purely by their type signatures.
This is fairly easily accomplished by editing some `desc` fields in `utils/genprimopcode/AccessOps.hs`.https://gitlab.haskell.org/ghc/ghc/-/issues/24509Undocumented ghci commands2024-03-12T15:04:15ZAdam GundryUndocumented ghci commandsThe `:check` and `:where` GHCi commands appear to be missing from the user's guide. We should either document them or deprecate them. (Originally noted at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12070#note_551552.)
Ideally w...The `:check` and `:where` GHCi commands appear to be missing from the user's guide. We should either document them or deprecate them. (Originally noted at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12070#note_551552.)
Ideally we would have a test that all the `ghciCommands` are documented...Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24488TypeAbstractions example produces a parse error2024-03-09T17:48:33ZJkensikTypeAbstractions example produces a parse error## Summary
The example from the documentation
`
f5 :: [forall a. a -> a -> a]
f5 = [ \ @a x _ -> x :: a,
\ @a _ y -> y :: a ]
`
gives the error
error: [GHC-58481] parse error on input ‘@’
|
26 | f5 = [ \ @a x _ -> x :: a,
...## Summary
The example from the documentation
`
f5 :: [forall a. a -> a -> a]
f5 = [ \ @a x _ -> x :: a,
\ @a _ y -> y :: a ]
`
gives the error
error: [GHC-58481] parse error on input ‘@’
|
26 | f5 = [ \ @a x _ -> x :: a,
## Environment
GHC9.8.2Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24484Haddocks for base-4.19 has broken source links to ghc-prim2024-02-27T13:54:59ZAndreas AbelHaddocks for base-4.19 has broken source links to ghc-primWhen clicking on "Source" for `Symbol` here (1.) we get to a non-existing page (2.):
1. https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-TypeLits.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.11.0-dca4/docs/sr...When clicking on "Source" for `Symbol` here (1.) we get to a non-existing page (2.):
1. https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-TypeLits.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.11.0-dca4/docs/src/GHC.Types.html#Symbol
Note the somewhat fishy hash part `-dca4` in the link to `ghc-prim`.
When I remove this part, I get to the correct location:
- https://hackage.haskell.org/package/ghc-prim-0.11.0/docs/src/GHC.Types.html#Symbol
So I looks like the documentation for `base` uploaded with GHC 9.8.2 has been incorrectly generated.
The same problem exists for base-4.19.0.0:
1. https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-Exts.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.11.0-997e/docs/src/GHC.Types.html#Symbol
Maybe it is a bug in the tooling (`haddock`).
But a script could be run on the generated documentation to remove the stray hashes before uploading the docs to hackage...
This seems to be a new problem, base-4.18 does not suffer from it:
1. https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-Exts.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.10.0/docs/src/GHC.Types.html#Symbolhttps://gitlab.haskell.org/ghc/ghc/-/issues/24444The callback argument passed to foreign import javascript interruptible funct...2024-02-20T14:10:49ZStefano DebenedettiThe callback argument passed to foreign import javascript interruptible functions is undocumented## Summary
Location of documentation issue: the GHC user's guide for [FFI and the JavaScript Backend](https://downloads.haskell.org/ghc/latest/docs/users_guide/javascript.html).
The JavaScript Backend will pass a callback function as e...## Summary
Location of documentation issue: the GHC user's guide for [FFI and the JavaScript Backend](https://downloads.haskell.org/ghc/latest/docs/users_guide/javascript.html).
The JavaScript Backend will pass a callback function as extra last argument to the JavaScript function defined or referenced by a `foreign import javascript interruptible` string. Such argument does not appear in the Haskell type signature of the function.
For more details and context: https://github.com/ghcjs/ghcjs-dom/pull/104#issuecomment-1945867928
## Proposed improvements or changes
The semantics of the `foreign import javascript interruptible` functions should be added the JavaScript Backend FFI documentation, together with a mention of the extra callback parameter and an example of how to use it in JavaScript code.
## Environment
* GHC version used (if appropriate): 9.8.1Sylvain HenryLuite Stegemandoyougnujmy6342@gmail.comSylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24425PartialTypeSignatures regression in 9.82024-03-11T09:00:53ZMatthías Páll GissurarsonPartialTypeSignatures regression in 9.8## Summary
There seems to be a regression in `-XPartialTypeSignatures`,
with GHC asking me to add a constraint to the context of an *inferred* type,
where as previously this constraint would have been inferred as well.
## Steps to repr...## Summary
There seems to be a regression in `-XPartialTypeSignatures`,
with GHC asking me to add a constraint to the context of an *inferred* type,
where as previously this constraint would have been inferred as well.
## Steps to reproduce
This compiles and runs fine in 9.6.3:
```
{-# LANGUAGE PartialTypeSignatures #-}
module Main where
checkFunc :: _ -> Bool
checkFunc f = f == 3
main :: IO ()
main = print (checkFunc 3)
```
```
$ ghc test.hs && ./test
[1 of 2] Compiling Main ( test.hs, test.o ) [Source file changed]
test.hs:4:14: warning: [GHC-88464] [-Wpartial-type-signatures]
• Found type wildcard ‘_’ standing for ‘Integer’
• In the type signature: checkFunc :: _ -> Bool
|
4 | checkFunc :: _ -> Bool
| ^
[2 of 2] Linking test [Objects changed]
$ ./test
True
```
but when compiled with 9.8.1:
```
$ ghc test.hs && ./test
[1 of 2] Compiling Main ( test.hs, test.o )
test.hs:5:17: error: [GHC-39999]
• No instance for ‘Eq a’ arising from a use of ‘==’
Possible fix:
add (Eq a) to the context of
the inferred type of checkFunc :: a -> Bool
• In the expression: f == 3
In an equation for ‘checkFunc’: checkFunc f = f == 3
|
5 | checkFunc f = f == 3
| ^^
test.hs:5:20: error: [GHC-39999]
• No instance for ‘Num a’ arising from the literal ‘3’
Possible fix:
add (Num a) to the context of
the inferred type of checkFunc :: a -> Bool
• In the second argument of ‘(==)’, namely ‘3’
In the expression: f == 3
In an equation for ‘checkFunc’: checkFunc f = f == 3
|
5 | checkFunc f = f == 3
|
```
## Expected behavior
I would expect it to compile as it did in 9.6.
## Environment
* GHC version used: 9.6.3, 9.8.1
Optional:
* Operating System: Ubuntu 22.04
* System Architecture: WSL2https://gitlab.haskell.org/ghc/ghc/-/issues/24394`-Dn` is missing from user guide2024-02-08T17:32:08ZTeo Camarasu`-Dn` is missing from user guideThe `-Dn` debug flag for non-moving collector information is missing from the user guide.
It should be listed along with the other `-D*` flags here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-flag-...The `-Dn` debug flag for non-moving collector information is missing from the user guide.
It should be listed along with the other `-D*` flags here: https://downloads.haskell.org/ghc/latest/docs/users_guide/runtime_control.html#rts-flag--Dk%20%20DEBUG:%20continuation
The corresponding `-ln` flag is documentedBen GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24377Wrong type signature for JavaScript asyncCallback in document2024-01-30T15:01:03ZohhoWrong type signature for JavaScript asyncCallback in document## Summary
Location of documentation issue: the GHC user's guide
This line here [1]:
```
* asyncCallback :: (JSVal -> IO ()) -> IO (Callback (JSVal -> IO ()))
```
...should either be:
```
* asyncCallback1 :: (JSVal -> IO ()) -> IO (Cal...## Summary
Location of documentation issue: the GHC user's guide
This line here [1]:
```
* asyncCallback :: (JSVal -> IO ()) -> IO (Callback (JSVal -> IO ()))
```
...should either be:
```
* asyncCallback1 :: (JSVal -> IO ()) -> IO (Callback (JSVal -> IO ()))
```
or:
```
* asyncCallback :: IO () -> IO (Callback (IO ()))
```
...according to [2].
- [[1]](https://gitlab.haskell.org/ghc/ghc/-/blame/master/docs/users_guide/javascript.rst?ref_type=heads#L140) - docs/users_guide/javascript.rst#L140
- [[2]](https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/src/GHC/JS/Foreign/Callback.hs#L116) - libraries/base/src/GHC/JS/Foreign/Callback.hs#L116
## Proposed improvements or changes
Update to the corresponding type signature.
## Environment
* GHC version used (if appropriate): 9.8.1Sylvain HenryLuite StegemanJosh Meredithdoyougnujmy6342@gmail.comSylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24350Comment on withBinaryFile seems wrong2024-01-23T15:52:47ZTom EllisComment on withBinaryFile seems wrongIt says
> The action /should/ close the file when finished with it so the file does not remain open until the garbage collector collects the handle
but like `withFile` and `withFileBlocking`, `withBinaryFile` uses `withFile'`, which pa...It says
> The action /should/ close the file when finished with it so the file does not remain open until the garbage collector collects the handle
but like `withFile` and `withFileBlocking`, `withBinaryFile` uses `withFile'`, which passes `True` as the argument `close_finally` to `withOpenFile'`, so it seems like the handle is indeed closed in the end. It seems like the comment should thus say the same as for `withFile` and `withFileBlocking`:
> The handle will be closed on exit
Originally introduced in f90487cacb16e8398c4c4a84de5a1e33ac4e7867.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24343Document which GHC version introduced GHC20212024-02-23T11:40:31ZOleg GrenrusDocument which GHC version introduced GHC2021https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html doesn't tell since which GHC2021 is available.
I actually have no idea what is the best way (without having all GHC versions installed locally to try) to find out whic...https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/control.html doesn't tell since which GHC2021 is available.
I actually have no idea what is the best way (without having all GHC versions installed locally to try) to find out which is the first GHC version supporting GHC2021. Looking through the all the manual going back is not great.
Compare to e.g. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/numeric_underscores.html#extension-NumericUnderscores, it tells immediately that NumericUnderscores is there since GHC-8.6.19.10.1Adam GundryAdam Gundryhttps://gitlab.haskell.org/ghc/ghc/-/issues/24317GHC9.8 changed where to place DuplicateRecordFields when re-exporting records...2024-01-09T17:07:21ZjackkellyGHC9.8 changed where to place DuplicateRecordFields when re-exporting records that share field names## Summary
GHC 9.8 has changed the way DuplicateRecordFields needs to be used when re-exporting records which share field names. The pragma now seems to affect modules instead of records (which is probably more correct), but causes GHC ...## Summary
GHC 9.8 has changed the way DuplicateRecordFields needs to be used when re-exporting records which share field names. The pragma now seems to affect modules instead of records (which is probably more correct), but causes GHC to reject some programs that it used to accept, in a way that I couldn't see mentioned in the release notes.
The pattern in the reproduction example is heavily used within the `amazonka-*` family of libraries, to collect type definitions into a single `Types` module per-package: https://github.com/brendanhay/amazonka/issues/969
## Steps to reproduce
Given the following source files:
`Export.hs`:
```haskell
module Export (Foo (..), Bar (..)) where
import A (Foo (..))
import B (Bar (..))
```
`A.hs`:
```haskell
{-# LANGUAGE DuplicateRecordFields #-}
module A where
data Foo = Foo {field :: Int}
```
`B.hs`:
```haskell
-- DuplicateRecordFields seemingly not required here:
-- GHC <9.8 seems happy if at least one record is
-- declared in a module with it enabled.
module B where
data Bar = Bar {field :: Bool}
```
Under GHC <9.8, `ghc --make Export.hs` would successfully compile. GHC 9.8 refuses to compile `Export.hs`:
```
$ ghc --make Export.hs
[1 of 3] Compiling A ( A.hs, A.o )
[2 of 3] Compiling B ( B.hs, B.o )
[3 of 3] Compiling Export ( Export.hs, Export.o )
Export.hs:1:26: error: [GHC-97219]
Duplicate record field ‘field’ in export list:
‘Bar(..)’ exports the field ‘field’
belonging to the constructor ‘Bar’
imported from ‘B’ at Export.hs:4:11-18
(and originally defined at B.hs:3:17-21)
‘Foo(..)’ exports the field ‘field’
belonging to the constructor ‘Foo’
imported from ‘A’ at Export.hs:3:11-18
(and originally defined at A.hs:3:17-21)
Suggested fix: Perhaps you intended to use DuplicateRecordFields
|
1 | module Export (Foo (..), Bar (..)) where
| ^^^^^^^^
```
Moving (or adding) the `{-# LANGUAGE DuplicateRecordFields #-}` to `Export.hs` will make GHC 9.8.1 compile `Export.hs`
## Expected behavior
If this change was intentional, GHC 9.8's behaviour makes more sense to me, in that the pragma is needed where the collision actually occurs. An update to the User's Guide page on `DuplicateRecordFields` may be all that's required here. (Amazonka can easily adapt by updating templates and regenerating service definitions.)
## Environment
* GHC version used: 9.8.1
Optional:
* Operating System: `x86_64-pc-linux-gnu`
* System Architecture: `amd64`9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24304ghc-9.8.1 --supported-extensions doesn't report JavaScriptFFI2024-02-09T17:32:33ZOleg Grenrusghc-9.8.1 --supported-extensions doesn't report JavaScriptFFI... but it does report `NoJavaScriptFFI`:
```
% ghc-9.8.1 --supported-extensions|grep JavaScriptFFI
NoJavaScriptFFI
```
... which is very weird.
Also from `.cabal` perspective, not reporting `JavaScriptFFI` in `--supported-extensions`...... but it does report `NoJavaScriptFFI`:
```
% ghc-9.8.1 --supported-extensions|grep JavaScriptFFI
NoJavaScriptFFI
```
... which is very weird.
Also from `.cabal` perspective, not reporting `JavaScriptFFI` in `--supported-extensions` is questionable (as it is accepted). Not reporting the extensions prevents its usage in `default-extensions` or `other-extensions` fields.https://gitlab.haskell.org/ghc/ghc/-/issues/24294Lots of incorrect links in haddock of `Data.List.NonEmpty`2024-03-19T14:36:21ZOwen Shepherdowen@owen.cafeLots of incorrect links in haddock of `Data.List.NonEmpty`## Summary
Building the docs for `base` currently produces lots of incorrect links to `GHC.OldList`, for unqualified names in `Data.List.NonEmpty`.
This issue is in production, as seen in the [live docs](https://hackage.haskell.org/pac...## Summary
Building the docs for `base` currently produces lots of incorrect links to `GHC.OldList`, for unqualified names in `Data.List.NonEmpty`.
This issue is in production, as seen in the [live docs](https://hackage.haskell.org/package/base-4.19.0.0/docs/Data-List-NonEmpty.html) for `base-4.19`.
This is a problem with lots of examples, but a good one would be [`unfoldr`](https://hackage.haskell.org/package/base-4.19.0.0/docs/Data-List-NonEmpty.html#v:unfoldr), for which the docs currently state that `GHC.OldList`'s `unfoldr` is analogous to `Data.List`'s `unfoldr`, which is technically correct, but clearly not the intention.
The docs for base-4.18.0.0 are correct, so the fault seems to have been introduced between GHC 9.6 and 9.8.
## Expected behavior
Unqualified quoted names in the `Data.List.NonEmpty` haddock should link to their counterparts in `Data.List.NonEmpty`, instead of in `GHC.OldList`.
## Environment
* GHC version used: ghc-9.9, ghc-9.89.8.2Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24291Missing changelog for (at least) tuples2024-01-29T07:56:39ZAndrey ProkopenkoMissing changelog for (at least) tuplesHello GHC team,
## Summary
Location of documentation issue:
- I believe, documentation presence was expected in either GHC user guide or `base`.
GHC 9.8.1 contains a new feature, i.e. Generic representation of (at least) tuples, i.e....Hello GHC team,
## Summary
Location of documentation issue:
- I believe, documentation presence was expected in either GHC user guide or `base`.
GHC 9.8.1 contains a new feature, i.e. Generic representation of (at least) tuples, i.e. `Tuple2`, `Tuple3` and so on. It was suddenly recognised on failed tests for `swagger2` package. Please also find discussion on [GitHub](https://github.com/GetShopTV/swagger2/issues/248).
## Proposed improvements or changes
My proposal is to add changelog entry for either GHC 9.8.1 or `base-4.19.0.0`.
## Environment
* GHC 9.8.1, base-4.19.0.0
Kind Regards,
Andrey9.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/24257Implicit param allowed, but doesn't work.2023-12-19T15:53:25ZOleg GrenrusImplicit param allowed, but doesn't work.ImplicitParams are awkward, I think it's awkward that they are `Constraint`s.
They are not allowed as superclasses (makes sense, but then not really):
```haskell
Prelude> :set -XConstraintKinds -XUndecidableSuperClasses -XImplicitParam...ImplicitParams are awkward, I think it's awkward that they are `Constraint`s.
They are not allowed as superclasses (makes sense, but then not really):
```haskell
Prelude> :set -XConstraintKinds -XUndecidableSuperClasses -XImplicitParams -XAllowAmbiguousTypes
Prelude> class (?foo :: Int) => Foo a where
<interactive>:22:1: error:
• Illegal implicit parameter ‘?foo::Int’
• In the context: ?foo::Int
While checking the super-classes of class ‘Foo’
In the class declaration for ‘Foo’
```
However, one can "work-around" that, by tricking GHC, making syntactic `?foo` not so obvious to the compiler:
```haskell
Prelude> class c => Id c where
Prelude> class (c, c ~ (?foo :: Int)) => Id c where bar :: Int; bar = ?foo
```
That is accepted.
But (not so obviously) it doesn't work:
```haskell
Prelude> let ?foo = 42 :: Int in bar @(?foo :: Int)
<interactive>:9:25: error: [GHC-39999]
• Could not deduce ‘Id (?foo::Int)’ arising from a use of ‘bar’
from the context: ?foo::Int
bound by the implicit-parameter binding for ?foo
at <interactive>:9:1-42
• In the expression: bar @(?foo :: Int)
In the expression: let ?foo = 42 :: Int in bar @(?foo :: Int)
In an equation for ‘it’:
it = let ?foo = 42 :: Int in bar @(?foo :: Int)
```
I feel that GHC should error earlier. It's the `Id`s class (or rather `bar`) definition which is wrong already.https://gitlab.haskell.org/ghc/ghc/-/issues/24255Mechanically check documentation of GHC flag implications2023-12-12T15:26:15ZBen GamariMechanically check documentation of GHC flag implicationsIn #24253 we found that a flag was added to `-Wdefault` yet the documentation was not amended. This is likely neither the first nor last time that this has happened. We should see to it that this is mechnically checked.In #24253 we found that a flag was added to `-Wdefault` yet the documentation was not amended. This is likely neither the first nor last time that this has happened. We should see to it that this is mechnically checked.9.12.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24249Unrestricted OverloadedLabels are not documented in user's guide2024-01-30T11:44:39ZAdam GundryUnrestricted OverloadedLabels are not documented in user's guideSince GHC 9.6, `OverloadedLabels` has not been restricted to identifiers but permits expressions like `#"a b c"` where the hash sign is immediately followed by a double-quoted string, number or various other characters. See the proposal ...Since GHC 9.6, `OverloadedLabels` has not been restricted to identifiers but permits expressions like `#"a b c"` where the hash sign is immediately followed by a double-quoted string, number or various other characters. See the proposal (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-unrestricted-overloadedlabels.rst) and implementation (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8966).
However the GHC user's guide section (https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_labels.html) doesn't appear to have been updated along with the implementation. The documentation should point out the additional syntactic flexibility that is now available.9.6.4ZubinZubin