GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-08-04T00:08:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/23012Core Lint error with horde-ad2023-08-04T00:08:58ZKrzysztof GogolewskiCore Lint error with horde-adCompiling the following module with `-O` fails Core Lint in 9.6 and master:
```haskell
{-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses #-}
module M where
import Data.Kind (Type)
class Vector v a where
nothing ::...Compiling the following module with `-O` fails Core Lint in 9.6 and master:
```haskell
{-# LANGUAGE BangPatterns, FlexibleInstances, MultiParamTypeClasses #-}
module M where
import Data.Kind (Type)
class Vector v a where
nothing :: v a
just :: a -> v a
data Proxy (a :: Type) = P
instance Vector Proxy a where
nothing = P
just _ = P
step :: Maybe a
step = Nothing
{-# INLINE[0] step #-}
stream :: Vector v a => v a
stream = case step of
Nothing -> nothing
Just !x -> just x
{-# INLINE[1] stream #-}
data Id a = MkId a
f :: (Proxy (Id a), Proxy a)
f = (stream, stream)
```
```
$ ./stage1/bin/ghc -O -dcore-lint M
[1 of 1] Compiling M ( M.hs, M.o )
*** Core Lint errors : in result of Simplifier ***
M.hs:29:1: warning:
Argument value doesn't match argument type:
Expected arg type: a_aHI
Actual arg type: Id a_aHI
Arg: ipv_sJg
In the RHS of f_sIP :: forall {a}. Proxy (Id a)
In the body of lambda with binder a_aHI :: *
In a case alternative: (Just x_ax7 :: Id a_aHI)
In a case alternative: (MkId ipv_sJg :: Id a_aHI)
In the pattern of a case alternative: (MkId ipv_sJg :: Id a_aHI)
Substitution: <InScope = {a_aHI}
IdSubst = []
TvSubst = [aHI :-> a_aHI]
CvSubst = []>
```
GHC 9.4.3 and 9.2.5 work fine. Testcase minimized from https://gitlab.haskell.org/ghc/ghc/-/issues/22955#note_483278.https://gitlab.haskell.org/ghc/ghc/-/issues/22994Shrinking a large ByteArray# retains all of its memory2023-03-09T14:32:52ZMatthew Cravenclyring@gmail.comShrinking a large ByteArray# retains all of its memory## Summary
The primop `shrinkMutableByteArray#` just overwrites the size of its `MutableByteArray#` argument on the heap. But when that argument is large enough to consist of more than one block, some of its trailing blocks may no longe...## Summary
The primop `shrinkMutableByteArray#` just overwrites the size of its `MutableByteArray#` argument on the heap. But when that argument is large enough to consist of more than one block, some of its trailing blocks may no longer be part of the shrunken array. However, these blocks are not returned to the RTS until the shrunken array is garbage-collected, which can be very wasteful in extreme situations.
(`resizeMutableByteArray#` exhibits this problem as well.)
## Steps to reproduce
Here's a sample program that can be used to verify this behavior:
<details>
```haskell
{-# LANGUAGE MagicHash, UnboxedTuples, ViewPatterns #-}
import qualified GHC.Exts as Exts
import GHC.IO (IO(..))
import Control.Monad
import Data.Array.Byte
import System.Environment
data ShrinkMethod = Shrink | Resize | Copy
deriving Read
shrink :: ShrinkMethod -> Exts.MutableByteArray# s -> Exts.Int# -> Exts.State# s
-> (# Exts.State# s, Exts.MutableByteArray# s #)
shrink p a n s0 = case p of
Shrink -> (# Exts.shrinkMutableByteArray# a n s0, a #)
Resize -> Exts.resizeMutableByteArray# a n s0
Copy -> case Exts.newByteArray# n s0 of
(# s1, tar #) -> case Exts.copyMutableByteArray# a 0# tar 0# n s1 of
s2 -> (# s2, tar #)
mkArr :: Int -> ShrinkMethod -> Int -> IO ByteArray
mkArr (Exts.I# initSize) whichOp (Exts.I# finalSize) = IO $ \s0 ->
case Exts.newByteArray# initSize s0 of
(# s1, marrL #) -> case shrink whichOp marrL finalSize s1 of
(# s2, marrS #) -> case Exts.setByteArray# marrS 0# finalSize 0# s2 of
s3 -> case Exts.unsafeFreezeByteArray# marrS s3 of
(# s4, arr #) -> (# s4, ByteArray arr #)
main :: IO ()
main = do
[read -> nArrs, read -> initSize, read -> whichOp, read -> finalSize]
<- getArgs
li <- replicateM nArrs (mkArr initSize whichOp finalSize)
-- printing of the first ByteArray is sequenced after
-- creation of the last ByteArray, so they are all live at once
mapM_ print li
```
</details>
If I compile and run this program with `./ShrinkDegeneracy 1000 1048576 Shrink 48 +RTS -M1G > /dev/null`, I see:
```
ShrinkDegeneracy: Heap exhausted;
ShrinkDegeneracy: Current maximum heap size is 1073741824 bytes (1024 MB).
ShrinkDegeneracy: Use `+RTS -M<size>' to increase it.
```
If I run `./ShrinkDegeneracy 1000 1048576 Resize 48 +RTS -M1G > /dev/null`, I see the same error.
If I run `./ShrinkDegeneracy 1000 1048576 Copy 48 +RTS -M1G > /dev/null`, the program successfully finishes in a small fraction of a second. (This is the desired behavior.)
## Environment
* GHC version used: 9.4.4Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/22963Improve the documentation for ($)2023-05-08T16:21:35ZHécate MoonlightImprove the documentation for ($)See discussion at https://github.com/haskell/core-libraries-committee/issues/132
cc @dixonarySee discussion at https://github.com/haskell/core-libraries-committee/issues/132
cc @dixonaryHécate MoonlightHécate Moonlighthttps://gitlab.haskell.org/ghc/ghc/-/issues/22621`ghc: internal error` when using nonmoving-gc2023-08-25T07:56:22ZDavid Hewson`ghc: internal error` when using nonmoving-gc## Summary
We use the nonmoving-gc and so I like to try it lots of places coax out issues. So i had the bright idea of what if we have ghc use it when we build our project? Long story short adding `+RTS --nonmoving-gc -RTS` to the build...## Summary
We use the nonmoving-gc and so I like to try it lots of places coax out issues. So i had the bright idea of what if we have ghc use it when we build our project? Long story short adding `+RTS --nonmoving-gc -RTS` to the build args results in an internal error on some packages.
```
ghc: internal error: allocGroup: free list corrupted
(GHC version 9.2.5 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
i thought i might be able to get more info from a ghc with the -debug runtime so i built 9.2.5 (the ghc we're using at the moment because stackage) with `quick-debug+debug_info` flavour
the error changes to
```
ghc: internal error: allocGroup: free list corrupted
(GHC version 9.2.5 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
ghc: internal error: ASSERTION FAILED: file rts/sm/BlockAlloc.c, line 819
(GHC version 9.2.5 for x86_64_unknown_linux)
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
not 100% on if this is two messages from the same call or not though.
I tried running in valgrind and whilst it complained about some branches using initialised data i don't think they were the cause (since i initialised them and the error is still there, if you wanna know it was complaining here https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.2.5-release/rts/Stats.c#L510)
i'm looking for more suggestions now on how to provide useful info. i suspect getting a small repro that I can share won't be easy
## Steps to reproduce
Use nonmoving-gc when building things using ghc
## Expected behavior
It not to die
## Environment
* GHC version used: 9.2.5
Optional:
* Operating System: ubuntu-20.04 via wsl2
* System Architecture: amd649.6.1Ben GamariBen Gamarihttps://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/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/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/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.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/21766Allow -finfo-table-map to be separated from executable2023-09-07T09:27:26ZMatthew PickeringAllow -finfo-table-map to be separated from executableSee: https://gitlab.haskell.org/ghc/ghc/-/wikis/Separate-Debug-Info
It would be good to allow the `-finfo-table-map` debugging information to be distributed separately from the executable it is the debugging information for. This would ...See: https://gitlab.haskell.org/ghc/ghc/-/wikis/Separate-Debug-Info
It would be good to allow the `-finfo-table-map` debugging information to be distributed separately from the executable it is the debugging information for. This would allow us to distribute `-finfo-table-map` debugging information for GHC and base packages, currently the profiles are quite poor if you rely a lot on base packages.9.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/21663hIsTerminalDevice can benefit from documenting Windows issues2022-07-21T02:52:41ZBodigrimhIsTerminalDevice can benefit from documenting Windows issues## Summary
Haddocks for [`GHC.IO.Handle.hIsTerminalDevice`](https://hackage.haskell.org/package/base-4.16.1.0/docs/System-IO.html#v:hIsTerminalDevice) could benefit from the discussion of Windows-related issues. Namely, this function fa...## Summary
Haddocks for [`GHC.IO.Handle.hIsTerminalDevice`](https://hackage.haskell.org/package/base-4.16.1.0/docs/System-IO.html#v:hIsTerminalDevice) could benefit from the discussion of Windows-related issues. Namely, this function fails to recognise MinTTY terminals, used by MSYS or Cygwin. See discussion of [`System.Console.ANSI.hSupportsANSI`](https://hackage.haskell.org/package/ansi-terminal-0.11.3/docs/System-Console-ANSI.html#v:hSupportsANSI) for more context.
I hit this during debugging of https://github.com/NorfairKing/feedback/pull/7.
## Proposed improvements or changes
Haddocks should suggest using [`System.Win32.MinTTY.isMinTTYHandle`](https://hackage.haskell.org/package/Win32-2.13.2.0/docs/System-Win32-MinTTY.html#v:isMinTTYHandle) in conjunction with `hIsTerminalDevice`.9.4.1BodigrimBodigrimhttps://gitlab.haskell.org/ghc/ghc/-/issues/21587Allow (and bundle?) transformers-0.6 as ghc dependency2023-02-24T09:49:08ZOleg GrenrusAllow (and bundle?) transformers-0.6 as ghc dependencyBecause `ghc` package itself depends on `transformers`, upgrading `transformers` is impossible if build plan uses plugins e.g.
This a bummer.
Opening an issue for the record.Because `ghc` package itself depends on `transformers`, upgrading `transformers` is impossible if build plan uses plugins e.g.
This a bummer.
Opening an issue for the record.9.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/21537Add fragmentation statistics to GHC.Stats2022-09-22T10:35:26ZTeo CamarasuAdd fragmentation statistics to GHC.Stats## Motivation
Fragmentation is a key statistic when using the non-moving garbage collector. The event log has information about heap fragmentation, but it would be helpful to have the same information available from `GHC.Stats`.
As far...## Motivation
Fragmentation is a key statistic when using the non-moving garbage collector. The event log has information about heap fragmentation, but it would be helpful to have the same information available from `GHC.Stats`.
As far as I understand we can already get at this statistic by taking `gcdetails_mem_in_use_bytes - gcdetails_live_bytes `. But I'm not sure that's right. And even if that's true, I think it would be more user friendly to make this stat available in an explicit way.
## Proposal
Add a field to `GHC.Stats.GCDetails` called `gcdetails_fragmentation_bytes` that gives the same stats as the event log fragmentation counter.
I'm happy to implement this.9.6.1Teo CamarasuTeo Camarasuhttps://gitlab.haskell.org/ghc/ghc/-/issues/21475Document extension stability2022-08-10T11:34:39ZBen GamariDocument extension stabilityIn the stability working group it was noted that nowhere do we state the expected stability contract of each language extension offered by GHC. This makes it hard for new users to determine which extensions are safe to use and which dese...In the stability working group it was noted that nowhere do we state the expected stability contract of each language extension offered by GHC. This makes it hard for new users to determine which extensions are safe to use and which deserve caution. Perhaps each language extension should grow a `stability` field.Trevis ElserTrevis Elserhttps://gitlab.haskell.org/ghc/ghc/-/issues/21410base changelog is missing MutableByteArray addition (only ByteArray# boxed wr...2022-04-25T23:02:57ZOleg Grenrusbase changelog is missing MutableByteArray addition (only ByteArray# boxed wrapper)Please select a template from the list above.Please select a template from the list above.9.4.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/21389Improve error messages from GHC.IO.Encoding.Failure2022-07-21T02:48:03ZBodigrimImprove error messages from GHC.IO.Encoding.Failure## Summary
Error messages from `GHC.IO.Encoding.Failure` are notoriously unhelpful. They are triggered by encoding mismatches and are environmental-dependent, so a program could work perfectly fine in development, but suddenly complain ...## Summary
Error messages from `GHC.IO.Encoding.Failure` are notoriously unhelpful. They are triggered by encoding mismatches and are environmental-dependent, so a program could work perfectly fine in development, but suddenly complain about invalid argument in production. The error message does not give any hints about an unexpected byte/char and whether it was decoding or encoding, which makes it frustrating and challenging to debug.
## Steps to reproduce
```haskell
module Main where
import GHC.IO.Encoding
main :: IO ()
main = decoding
decoding :: IO ()
decoding = do
-- enforce non-Latin1 locale
setLocaleEncoding utf8
-- read binary file
xs <- readFile "Foo"
-- force evaluation
print (length xs)
-- throws hGetContents: invalid argument (invalid byte sequence)
encoding :: IO ()
encoding = do
-- enforce non-Unicode locale
setLocaleEncoding latin1
-- print unescaped Unicode char
putStrLn "Я"
-- throws commitBuffer: invalid argument (invalid character)
```
## Expected behavior
I have a patch, which changes error messages to respectively
```haskell
-- hGetContents: invalid argument (cannot decode byte sequence starting from 207)
-- commitBuffer: invalid argument (cannot encode character '\1071')
```
Admittedly, this is not perfect and ideally we would dump more context and specify encodings involved, but better than status quo.
## Environment
* GHC version used: 9.2BodigrimBodigrimhttps://gitlab.haskell.org/ghc/ghc/-/issues/211969.2.2 is defunct on windows?2022-08-15T20:57:11ZJulian Ospald9.2.2 is defunct on windows?When I install 9.2.2 with ghcup on windows and try to run ghc or ghci, nothing happens:
```
PS C:\Users\bas ar\ghcup-hs> ghc-9.2.2 --version
PS C:\Users\bas ar\ghcup-hs> ghc-9.2.2 --help
PS C:\Users\bas ar\ghcup-hs> C:\ghcup\ghc\9.2.2\b...When I install 9.2.2 with ghcup on windows and try to run ghc or ghci, nothing happens:
```
PS C:\Users\bas ar\ghcup-hs> ghc-9.2.2 --version
PS C:\Users\bas ar\ghcup-hs> ghc-9.2.2 --help
PS C:\Users\bas ar\ghcup-hs> C:\ghcup\ghc\9.2.2\bin\ghc-9.2.2.exe --help
PS C:\Users\bas ar\ghcup-hs> C:\ghcup\ghc\9.2.2\bin\ghc-9.2.2.exe --version
PS C:\Users\bas ar\ghcup-hs> ghc-8.10.7 --version
The Glorious Glasgow Haskell Compilation System, version 8.10.7
```9.2.3Ben GamariZubinBen Gamari