GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-04-01T12:27:18Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/19535CharToNat and NatToChar type families2021-04-01T12:27:18ZVladislav ZavialovCharToNat and NatToChar type families@RyanGlScott’s work on `singletons` revealed that built-in type families added in 7f3524efcbd58ca6837ec0ffca6ddd121d64e4de are insufficient to implement a promoted variant of `Show Char`.
For `Show`, we need `CharToNat`. And with `NatTo...@RyanGlScott’s work on `singletons` revealed that built-in type families added in 7f3524efcbd58ca6837ec0ffca6ddd121d64e4de are insufficient to implement a promoted variant of `Show Char`.
For `Show`, we need `CharToNat`. And with `NatToChar` to accompany it, we can also define promoted `Enum Char`.
These type families were originally part of !3598, but it is currently on hold because it’s unclear whether we want to add so many built-in definitions (and also because the author currently has no time to rebase it and clean it up, at least in time for the %"9.2.1" release). However, now there’s a clear case for `CharToNat` and `NatToChar`, so this ticket is to track their addition.
Patch here: !52589.2.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/19504Another <no location info> error (Tuple section in pattern context)2021-06-11T11:19:23ZilcasinistareloadedAnother <no location info> error (Tuple section in pattern context)## Summary
For some syntax errors GHC cannot locate the error (<no location info>: error: Tuple section in pattern context).
## Steps to reproduce
```
ok = (\ (0, _) -> (0, undefined))
-- But forgetting the underscore,
e...## Summary
For some syntax errors GHC cannot locate the error (<no location info>: error: Tuple section in pattern context).
## Steps to reproduce
```
ok = (\ (0, _) -> (0, undefined))
-- But forgetting the underscore,
error_notLocated = (\ (0, ) -> (0, undefined)) -- <no location info>: error: Tuple section in pattern context
```
## Expected behavior
GHC should locate the error in the source code.
## Environment
* GHC version used: 8.10.49.2.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/18834Implement -Woperator-whitespace2020-11-09T14:02:13ZVladislav ZavialovImplement -Woperator-whitespace[GHC Proposal #229](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst) defines two warnings:
* `-Woperator-whitespace-ext-conflict`
* `-Woperator-whitespace`
This ticket is to track ...[GHC Proposal #229](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst) defines two warnings:
* `-Woperator-whitespace-ext-conflict`
* `-Woperator-whitespace`
This ticket is to track their implementation.9.2.1Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/18712Bump base to 4.162020-11-06T12:42:45ZVladislav ZavialovBump base to 4.16GHC 9.0 will be released with `base-4.15`, and the branch has been cut. So it's time we bump `base` to `4.16` in HEAD.
This is needed to make progress in !3598, as it needs to tell apart the `base` version in `HEAD` and the latest relea...GHC 9.0 will be released with `base-4.15`, and the branch has been cut. So it's time we bump `base` to `4.16` in HEAD.
This is needed to make progress in !3598, as it needs to tell apart the `base` version in `HEAD` and the latest released `base` version using a CPP conditional. Currently it uses these lines:
```
#if MIN_VERSION_base(4,15,0)
#define HAS_TYPELITS_CHAR
#endif
```
But they will break as soon as GHC 9.0 is released.
Of course, the problem with bumping the `base` version is that it also requires relaxing upper bounds in so many submodules. So let's do it separately from !35989.2.1Ben GamariVladislav ZavialovBen Gamari