GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:02:45Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15843Tuple sections can't be quoted2019-07-07T18:02:45ZMatthew PickeringTuple sections can't be quotedThere are quite a few forms that are not supported in template haskell quotes. It seems that it would be at least a good warm up patch to add support for tuple sections which you can do simply by desugaring to a lambda and the normal tup...There are quite a few forms that are not supported in template haskell quotes. It seems that it would be at least a good warm up patch to add support for tuple sections which you can do simply by desugaring to a lambda and the normal tuple constructor.
```
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE TupleSections #-}
module Foo where
foo = [|| (,5) ||]
```
1. Modify `DsMeta.repE` to handle tuple sections. You can desugar `(,5) => \x -> (x, 5)`.
1. Add the above test to the test suite.8.10.1Alex DAlex Dhttps://gitlab.haskell.org/ghc/ghc/-/issues/15841User's Guide section for Coercible links to a 404 page2019-07-07T18:02:46Zkoz_User's Guide section for Coercible links to a 404 pageSection 10.14.4 of the User's Guide is meant to describe the Coercible constraint, and links to the safe coercions paper to do so (there's basically little else in that section at all). However, that link currently 404s (the link is spec...Section 10.14.4 of the User's Guide is meant to describe the Coercible constraint, and links to the safe coercions paper to do so (there's basically little else in that section at all). However, that link currently 404s (the link is specifically http://www.cis.upenn.edu/\~eir/papers/2014/coercible/coercible.pdf).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"User's Guide section for Coercible links to a 404 page","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Section 10.14.4 of the User's Guide is meant to describe the Coercible constraint, and links to the safe coercions paper to do so (there's basically little else in that section at all). However, that link currently 404s (the link is specifically http://www.cis.upenn.edu/~eir/papers/2014/coercible/coercible.pdf).","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15840Inline data constructor wrappers very late2019-07-07T18:02:46ZArnaud SpiwackInline data constructor wrappers very lateThis came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach.
Currently...This came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach.
Currently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1).
I want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own.
The proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor:
In
```hs
case $WK u of { K x -> e; … }
```
`$WK` wouldn't unfold until very late. But we don't want the `case` expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable.
Fortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls `exprIsConApp_maybe`. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with `K`). So what we can do is make `exprIsConApp_maybe` a bit smarter and teach it to see through data constructor wrappers.
Let's take an unpacking wrapper as an example:
```hs
data T = MkT {-# UNPACK #-} !(Int, Bool)
$WMkT p = case p of (i,b) -> MkT i b
```
We have to see that `$WMkT u` is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of `exprIsConApp_maybe` would change from
```hs
exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr])
```
to
```hs
exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr])
```
Where `Float`-s are lets or cases with a single alternative (much like in the FloatOut pass).
We then need to change case-of-known-constructor to also perform case-of-lets and case-of-cases when such floats are found.
In summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately.
Does anyone sees something which could go wrong with this plan?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Inline data constructor wrappers very late","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"This came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach.\r\n\r\nCurrently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1).\r\n\r\nI want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own.\r\n\r\nThe proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor:\r\n\r\nIn\r\n{{{#!hs\r\ncase $WK u of { K x -> e; … }\r\n}}}\r\n\r\n`$WK` wouldn't unfold until very late. But we don't want the `case` expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable.\r\n\r\nFortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls `exprIsConApp_maybe`. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with `K`). So what we can do is make `exprIsConApp_maybe` a bit smarter and teach it to see through data constructor wrappers.\r\n\r\nLet's take an unpacking wrapper as an example:\r\n\r\n{{{#!hs\r\ndata T = MkT {-# UNPACK #-} !(Int, Bool)\r\n\r\n$WMkT p = case p of (i,b) -> MkT i b\r\n}}}\r\n\r\nWe have to see that `$WMkT u` is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of `exprIsConApp_maybe` would change from\r\n\r\n{{{#!hs\r\nexprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr])\r\n}}}\r\n\r\nto\r\n\r\n{{{#!hs\r\nexprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr])\r\n}}}\r\n\r\nWhere `Float`-s are lets or cases with a single alternative (much like in the FloatOut pass).\r\n\r\nWe then need to change case-of-known-constructor to also perform case-of-lets and case-of-cases when such floats are found.\r\n\r\nIn summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately.\r\n\r\nDoes anyone sees something which could go wrong with this plan?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15839DerivingStrategies defaulting warning has no associated enable/suppress flag2019-09-25T17:58:18ZAkhra GannonDerivingStrategies defaulting warning has no associated enable/suppress flagWhen `DeriveAnyClass` and `GeneralizedNewtypeDeriving` are enabled together, an instance that could be derived with either one defaults to `DeriveAnyClass` and throws a warning to that effect. There is currently no flag to suppress that ...When `DeriveAnyClass` and `GeneralizedNewtypeDeriving` are enabled together, an instance that could be derived with either one defaults to `DeriveAnyClass` and throws a warning to that effect. There is currently no flag to suppress that warning (it appears even with `-w`).
In the presence of `DerivingStrategies`, it seems desirable to be able to suppress this.
Proposed flag to control it: `-Wderiving-defaults`, after the pattern of `-Wtype-defaults`.
This flag should be part of the default warning set, as without `DerivingStrategies` it remains a bad idea to have both newtype and anyclass active.
Minimal example (thanks RyanGIScott):
```
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
module Bug where
class C a
newtype T a = MkT a deriving C
```
```
$ /opt/ghc/8.6.1/bin/ghci Bug.hs
GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Bug.hs:6:30: warning:
• Both DeriveAnyClass and GeneralizedNewtypeDeriving are enabled
Defaulting to the DeriveAnyClass strategy for instantiating C
• In the newtype declaration for ‘T’
|
6 | newtype T a = MkT a deriving C
| ^
Ok, one module loaded.
```8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15838Warn about unused dependencies2020-03-27T21:10:35ZYurasWarn about unused dependenciesGHC loads packages lazily, so at the end of compilation (at least in `--make` mode) it knows all the dependencies, required to compile the code. See `eps_PIT` in `ExternalPackageState`. If we compare this list with the list of packages, ...GHC loads packages lazily, so at the end of compilation (at least in `--make` mode) it knows all the dependencies, required to compile the code. See `eps_PIT` in `ExternalPackageState`. If we compare this list with the list of packages, passed on command like via `--package-id`, then we'll get a list of unused dependencies.
I propose to add a flag `-Wunused-packages`, off by default, which will report the unused packages if any.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Warn about unused dependencies","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC loads packages lazily, so at the end of compilation (at least in `--make` mode) it knows all the dependencies, required to compile the code. See `eps_PIT` in `ExternalPackageState`. If we compare this list with the list of packages, passed on command like via `--package-id`, then we'll get a list of unused dependencies.\r\n\r\nI propose to add a flag `-Wunused-packages`, off by default, which will report the unused packages if any.","type_of_failure":"OtherFailure","blocking":[]} -->YurasYurashttps://gitlab.haskell.org/ghc/ghc/-/issues/15837Hadrian should build dynamically linked ghc binary2019-07-07T18:02:47ZdavideHadrian should build dynamically linked ghc binaryThe ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this:
1. Add new .cabal file field extra-dynamic-libra...The ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this:
1. Add new .cabal file field extra-dynamic-library-flavours (see [this PR](https://github.com/haskell/cabal/pull/5606)).
1. Use .cabal extra-dynamic-library-flavours for the RTS (see [this comment](https://github.com/snowleopard/hadrian/issues/695#issue-367436377), depends on 1.)
1. Hadrian: fix management of nontrivial dynamic flavours of libHSrts (see [this PR](https://github.com/snowleopard/hadrian/pull/698)).
1. Hadrian should build ghc with the `-fPIC -dynamic` options (see [this comment](https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b#diff-408bbe46d4afae11991cbadb2c531b78), depends on 3.).
1. Use the correct relative path to the dynamically linked libraries (see [D5281](https://phabricator.haskell.org/D5281), depends on 3. and 4.).
1. Build ghc-iserv-dyn, as it is will be required required by many tests (Phab:D5327)
1. Hadrian should only use "-shared -dynload deploy" when linking shared libraries (definitely not when linking executables). This problem causes ghc-iserv-dyn to segfault because it is built as a shared library instead of as an executable.davidedavidehttps://gitlab.haskell.org/ghc/ghc/-/issues/15834genSym is not thread safe with respect to setNumCapabilities2019-07-07T18:02:48ZNeil MitchellgenSym is not thread safe with respect to setNumCapabilitiesIn a large proprietary application using the GHC API, we observe really weird errors (e.g. overlapping instances for `Eq Foo` and `Eq Bar`, where `Foo` and `Bar` are completely unrelated, and come from different modules). The pattern we ...In a large proprietary application using the GHC API, we observe really weird errors (e.g. overlapping instances for `Eq Foo` and `Eq Bar`, where `Foo` and `Bar` are completely unrelated, and come from different modules). The pattern we follow is:
\* Running with the threaded RTS, 1 initial thread
\* Create a new unique supply with `mkSplitUniqSupply` and put it in an `MVar`.
\* Repeating many times:
- Set the thread count higher (e.g. 8) using `setNumCapabilities`
- On many threads in parallel:
\* Obtain a new unique supply on the original with `splitUniqSupply`, protected by the `MVar`, and update the other one in the `MVar`
\* Use that unique supply to interact with the GHC API
- Set the thread count back to 1
Our observations of the errors are best explained by the unique names not being nearly as unique as they might be expected to be. Reading the code for `genSym`:
```c
if (n_capabilities == 1)
{
GenSymCounter = (GenSymCounter + GenSymInc) & UNIQUE_MASK;
checkUniqueRange(GenSymCounter);
return GenSymCounter;
}
else
{
HsInt n = atomic_inc((StgWord *)&GenSymCounter, GenSymInc) & UNIQUE_MASK;
checkUniqueRange(n);
return n;
}
```
It only does an `atomic_inc` if `n_capabilities == 1`, but it doesn't read `n_capabilities` atomically, so is it suffering a race?
The solution was to set the thread count initially, before any interactions with the GHC API, which seems to solve the problem. Alas, we don't have a reproducible test case, and in fact were unable to reproduce it anywhere but our Linux CI, and even then non-deterministically. The problem does not currently impact us (the workaround is robust), but it seemed worth sharing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"genSym is not thread safe with respect to setNumCapabilities","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In a large proprietary application using the GHC API, we observe really weird errors (e.g. overlapping instances for {{{Eq Foo}}} and {{{Eq Bar}}}, where {{{Foo}}} and {{{Bar}}} are completely unrelated, and come from different modules). The pattern we follow is:\r\n\r\n* Running with the threaded RTS, 1 initial thread\r\n* Create a new unique supply with {{{mkSplitUniqSupply}}} and put it in an {{{MVar}}}.\r\n* Repeating many times:\r\n * Set the thread count higher (e.g. 8) using {{{setNumCapabilities}}}\r\n * On many threads in parallel:\r\n * Obtain a new unique supply on the original with {{{splitUniqSupply}}}, protected by the {{{MVar}}}, and update the other one in the {{{MVar}}}\r\n * Use that unique supply to interact with the GHC API\r\n * Set the thread count back to 1\r\n\r\nOur observations of the errors are best explained by the unique names not being nearly as unique as they might be expected to be. Reading the code for {{{genSym}}}:\r\n\r\n{{{#!c\r\n if (n_capabilities == 1)\r\n {\r\n GenSymCounter = (GenSymCounter + GenSymInc) & UNIQUE_MASK;\r\n checkUniqueRange(GenSymCounter);\r\n return GenSymCounter;\r\n }\r\n else\r\n {\r\n HsInt n = atomic_inc((StgWord *)&GenSymCounter, GenSymInc) & UNIQUE_MASK;\r\n checkUniqueRange(n);\r\n return n;\r\n }\r\n}}}\r\n\r\nIt only does an {{{atomic_inc}}} if {{{n_capabilities == 1}}}, but it doesn't read {{{n_capabilities}}} atomically, so is it suffering a race?\r\n\r\nThe solution was to set the thread count initially, before any interactions with the GHC API, which seems to solve the problem. Alas, we don't have a reproducible test case, and in fact were unable to reproduce it anywhere but our Linux CI, and even then non-deterministically. The problem does not currently impact us (the workaround is robust), but it seemed worth sharing.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15831DerivingVia allows bogus implicit quantification in `via` type2019-07-26T10:41:30ZRyan ScottDerivingVia allows bogus implicit quantification in `via` typeConsider the following code:
```hs
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
import Data.Functor.Const (Const(..))
import GHC.Exts (Any)
newtype Age = MkAge Int
deriving Eq
via Const Int Any
```
T...Consider the following code:
```hs
{-# LANGUAGE DerivingVia #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
import Data.Functor.Const (Const(..))
import GHC.Exts (Any)
newtype Age = MkAge Int
deriving Eq
via Const Int Any
```
This fails to compile with a spectacularly unhelpful error message:
```
$ /opt/ghc/8.6.1/bin/ghc -ddump-deriv Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
==================== Derived instances ====================
Derived class instances:
instance GHC.Classes.Eq Bug.Age where
(GHC.Classes.==)
= GHC.Prim.coerce
@((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)
-> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)
-> GHC.Types.Bool)
@(Bug.Age -> Bug.Age -> GHC.Types.Bool)
(GHC.Classes.==) ::
Bug.Age -> Bug.Age -> GHC.Types.Bool
(GHC.Classes./=)
= GHC.Prim.coerce
@((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)
-> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)
-> GHC.Types.Bool)
@(Bug.Age -> Bug.Age -> GHC.Types.Bool)
(GHC.Classes./=) ::
Bug.Age -> Bug.Age -> GHC.Types.Bool
Derived type family instances:
Bug.hs:9:12: error:
The exact Name ‘k’ is not in scope
Probable cause: you used a unique Template Haskell name (NameU),
perhaps via newName, but did not bind it
If that's it, then -ddump-splices might be useful
|
9 | deriving Eq
| ^^
Bug.hs:9:12: error:
The exact Name ‘k’ is not in scope
Probable cause: you used a unique Template Haskell name (NameU),
perhaps via newName, but did not bind it
If that's it, then -ddump-splices might be useful
|
9 | deriving Eq
| ^^
Bug.hs:9:12: error:
The exact Name ‘k’ is not in scope
Probable cause: you used a unique Template Haskell name (NameU),
perhaps via newName, but did not bind it
If that's it, then -ddump-splices might be useful
|
9 | deriving Eq
| ^^
Bug.hs:9:12: error:
The exact Name ‘k’ is not in scope
Probable cause: you used a unique Template Haskell name (NameU),
perhaps via newName, but did not bind it
If that's it, then -ddump-splices might be useful
|
9 | deriving Eq
| ^^
```
There are two things that are strange here:
- Notice that in the derived `Eq` instance, there are references to `(GHC.Types.Any :: k_a24l)`, where `k_a24l` is completely free! This should never happen, and is almost surely the cause of the resulting volley of errors.
- It's quite odd that we didn't reject this `deriving` clause outright //before// generating the derived code. In fact, if we explicitly mention the kind `k`:
```hs
newtype Age = MkAge Int
deriving Eq
via Const Int (Any :: k)
```
> //Then// it's rejected properly:
```
$ /opt/ghc/8.6.1/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:9:12: error:
Type variable ‘k’ is bound in the ‘via’ type ‘Const Int (Any :: k)’
but is not mentioned in the derived class ‘Eq’, which is illegal
|
9 | deriving Eq
| ^^
```
> Something about implicit quantification must be sneaking by this validity check.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DerivingVia allows bogus implicit quantification in `via` type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DerivingVia #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\nimport Data.Functor.Const (Const(..))\r\nimport GHC.Exts (Any)\r\n\r\nnewtype Age = MkAge Int\r\n deriving Eq\r\n via Const Int Any\r\n}}}\r\n\r\nThis fails to compile with a spectacularly unhelpful error message:\r\n\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghc -ddump-deriv Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\n==================== Derived instances ====================\r\nDerived class instances:\r\n instance GHC.Classes.Eq Bug.Age where\r\n (GHC.Classes.==)\r\n = GHC.Prim.coerce\r\n @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)\r\n -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)\r\n -> GHC.Types.Bool)\r\n @(Bug.Age -> Bug.Age -> GHC.Types.Bool)\r\n (GHC.Classes.==) ::\r\n Bug.Age -> Bug.Age -> GHC.Types.Bool\r\n (GHC.Classes./=)\r\n = GHC.Prim.coerce\r\n @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)\r\n -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep)\r\n -> GHC.Types.Bool)\r\n @(Bug.Age -> Bug.Age -> GHC.Types.Bool)\r\n (GHC.Classes./=) ::\r\n Bug.Age -> Bug.Age -> GHC.Types.Bool\r\n \r\n\r\nDerived type family instances:\r\n\r\n\r\n\r\nBug.hs:9:12: error:\r\n The exact Name ‘k’ is not in scope\r\n Probable cause: you used a unique Template Haskell name (NameU), \r\n perhaps via newName, but did not bind it\r\n If that's it, then -ddump-splices might be useful\r\n |\r\n9 | deriving Eq\r\n | ^^\r\n\r\nBug.hs:9:12: error:\r\n The exact Name ‘k’ is not in scope\r\n Probable cause: you used a unique Template Haskell name (NameU), \r\n perhaps via newName, but did not bind it\r\n If that's it, then -ddump-splices might be useful\r\n |\r\n9 | deriving Eq\r\n | ^^\r\n\r\nBug.hs:9:12: error:\r\n The exact Name ‘k’ is not in scope\r\n Probable cause: you used a unique Template Haskell name (NameU), \r\n perhaps via newName, but did not bind it\r\n If that's it, then -ddump-splices might be useful\r\n |\r\n9 | deriving Eq\r\n | ^^\r\n\r\nBug.hs:9:12: error:\r\n The exact Name ‘k’ is not in scope\r\n Probable cause: you used a unique Template Haskell name (NameU), \r\n perhaps via newName, but did not bind it\r\n If that's it, then -ddump-splices might be useful\r\n |\r\n9 | deriving Eq\r\n | ^^\r\n}}}\r\n\r\nThere are two things that are strange here:\r\n\r\n* Notice that in the derived `Eq` instance, there are references to `(GHC.Types.Any :: k_a24l)`, where `k_a24l` is completely free! This should never happen, and is almost surely the cause of the resulting volley of errors.\r\n* It's quite odd that we didn't reject this `deriving` clause outright //before// generating the derived code. In fact, if we explicitly mention the kind `k`:\r\n\r\n{{{#!hs\r\nnewtype Age = MkAge Int\r\n deriving Eq\r\n via Const Int (Any :: k)\r\n}}}\r\n\r\n //Then// it's rejected properly:\r\n\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghc Bug.hs \r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) \r\n \r\nBug.hs:9:12: error: \r\n Type variable ‘k’ is bound in the ‘via’ type ‘Const Int (Any :: k)’ \r\n but is not mentioned in the derived class ‘Eq’, which is illegal \r\n | \r\n9 | deriving Eq \r\n | ^^\r\n}}}\r\n\r\n Something about implicit quantification must be sneaking by this validity check.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/15830Plugins Tests are Skipped2021-05-11T10:01:02ZdavidePlugins Tests are SkippedThe test driver skips the plugins01 test after building the default flavour with hadrian. testsuite/tests/plugins/all.T specifies `only_ways([config.ghc_plugin_way]`. Some how this condition is not met. Open questions:
- Are all plugin\...The test driver skips the plugins01 test after building the default flavour with hadrian. testsuite/tests/plugins/all.T specifies `only_ways([config.ghc_plugin_way]`. Some how this condition is not met. Open questions:
- Are all plugin\* tests skipped?
- Are these tests also skipped when built/run via make?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alpmestan |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Plugins Tests are Skipped","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["plugins","test"],"differentials":[],"test_case":"","architecture":"","cc":["alpmestan"],"type":"Bug","description":"The test driver skips the plugins01 test after building the default flavour with hadrian. testsuite/tests/plugins/all.T specifies `only_ways([config.ghc_plugin_way]`. Some how this condition is not met. Open questions:\r\n\r\n* Are all plugin* tests skipped?\r\n* Are these tests also skipped when built/run via make?","type_of_failure":"OtherFailure","blocking":[]} -->Make removaldavidedavidehttps://gitlab.haskell.org/ghc/ghc/-/issues/15829Add a test case for tricky type synonyms involving visible dependent kinds2019-07-07T18:02:49ZRyan ScottAdd a test case for tricky type synonyms involving visible dependent kindsThis code does not typecheck on GHC 8.6.1:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
import Data.Kind
data A :: Type -> Type
data B a :: A a -> Type
type C a = B a
```
However, it //does// typecheck...This code does not typecheck on GHC 8.6.1:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PolyKinds #-}
module Bug where
import Data.Kind
data A :: Type -> Type
data B a :: A a -> Type
type C a = B a
```
However, it //does// typecheck on GHC HEAD, after commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 (Finish fix for #14880.). This is very cool, although it does alarm me that there is no test case which checks for this at the moment. Let's add one to ensure that this stays fixed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add a test case for tricky type synonyms involving visible dependent kinds","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code does not typecheck on GHC 8.6.1:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE PolyKinds #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata A :: Type -> Type\r\ndata B a :: A a -> Type\r\ntype C a = B a\r\n}}}\r\n\r\nHowever, it //does// typecheck on GHC HEAD, after commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 (Finish fix for #14880.). This is very cool, although it does alarm me that there is no test case which checks for this at the moment. Let's add one to ensure that this stays fixed.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15828Type family equation foralls allow strange re-quantification of class-bound t...2019-07-07T18:02:49ZRyan ScottType family equation foralls allow strange re-quantification of class-bound type variablesThe following code typechecks on GHC HEAD (8.7+):
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
class C1 a where
type T1 a b
class C2 a where
type T2 a b
instance C1 (M...The following code typechecks on GHC HEAD (8.7+):
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
class C1 a where
type T1 a b
class C2 a where
type T2 a b
instance C1 (Maybe a) where
type forall a b. T1 (Maybe a) b = b
instance C2 (Maybe a) where
type forall b. T2 (Maybe a) b = b
```
But ought it to? There is something funny happening in the `C1` instance: it's explicitly quantifying `a`, despite the fact that it had previously been quantified by the class head! Moreover, it appears that you can safely drop the `a` in the explicit `forall`, as the `C2 (Maybe a)` instance witnesses.
What does the documentation have to say on this topic? This is all I could find:
> When an explicit `forall` is present, all //type// variables mentioned must be bound by the `forall`.
I couldn't find anything on the interaction between this feature and associated type families. We should:
1. Decide which of the two programs above should be accepted, and
1. Update the documentation to reflect this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type family equation foralls allow strange re-quantification of class-bound type variables","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code typechecks on GHC HEAD (8.7+):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\nclass C1 a where\r\n type T1 a b\r\nclass C2 a where\r\n type T2 a b\r\n\r\ninstance C1 (Maybe a) where\r\n type forall a b. T1 (Maybe a) b = b\r\ninstance C2 (Maybe a) where\r\n type forall b. T2 (Maybe a) b = b\r\n}}}\r\n\r\nBut ought it to? There is something funny happening in the `C1` instance: it's explicitly quantifying `a`, despite the fact that it had previously been quantified by the class head! Moreover, it appears that you can safely drop the `a` in the explicit `forall`, as the `C2 (Maybe a)` instance witnesses.\r\n\r\nWhat does the documentation have to say on this topic? This is all I could find:\r\n\r\n> When an explicit `forall` is present, all //type// variables mentioned must be bound by the `forall`.\r\n\r\nI couldn't find anything on the interaction between this feature and associated type families. We should:\r\n\r\n1. Decide which of the two programs above should be accepted, and\r\n2. Update the documentation to reflect this.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15827Explicit foralls in type family equations are pretty-printed inconsistently (...2019-07-07T18:02:49ZRyan ScottExplicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times)Load the following code into GHCi HEAD (8.7+):
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
type family F1 a
type instance forall a. F1 a = Maybe a
type family F2 a where
...Load the following code into GHCi HEAD (8.7+):
```hs
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Kind
type family F1 a
type instance forall a. F1 a = Maybe a
type family F2 a where
forall a. F2 a = Maybe a
data family D a
data instance forall a. D a = MkD (Maybe a)
```
And make sure you have the `-fprint-explicit-foralls` flag enabled. Now let's see what happens when we look up the `:info` for each of these type families:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint-explicit-foralls
GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :i F1
type family F1 a :: * -- Defined at Bug.hs:7:1
type instance F1 a = Maybe a -- Defined at Bug.hs:8:25
λ> :i F2
type family F2 a :: *
where [a] F2 a = Maybe a
-- Defined at Bug.hs:10:1
λ> :i D
data family D a -- Defined at Bug.hs:13:1
data instance D a = MkD (Maybe a) -- Defined at Bug.hs:14:25
```
There are two strange things of note here:
- The equations for `F1` and `D` do not have any explicit `forall`s displayed at all, despite the fact that `-fprint-explicit-foralls` is enabled.
- The equation for `F2` //does// have an explicit `forall` displayed, but in a rather bizarre fashion:
```
λ> :i F2
type family F2 a :: *
where [a] F2 a = Maybe a
-- Defined at Bug.hs:10:1
```
> I certainly wasn't expecting to see the type variables in square brackets. I would have hoped to see something like this instead:
```
λ> :i F2
type family F2 a :: *
where forall a. F2 a = Maybe a
-- Defined at Bug.hs:10:1
```
Now that the "more explicit `forall`s" proposal is implemented, my hope is that it will be somewhat simple to change the way that this is pretty-printed (we already store the explicit `forall` information within the AST, after all).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Load the following code into GHCi HEAD (8.7+):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ntype family F1 a\r\ntype instance forall a. F1 a = Maybe a\r\n\r\ntype family F2 a where\r\n forall a. F2 a = Maybe a\r\n\r\ndata family D a\r\ndata instance forall a. D a = MkD (Maybe a)\r\n}}}\r\n\r\nAnd make sure you have the `-fprint-explicit-foralls` flag enabled. Now let's see what happens when we look up the `:info` for each of these type families:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint-explicit-foralls\r\nGHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :i F1\r\ntype family F1 a :: * -- Defined at Bug.hs:7:1\r\ntype instance F1 a = Maybe a -- Defined at Bug.hs:8:25\r\nλ> :i F2\r\ntype family F2 a :: *\r\n where [a] F2 a = Maybe a\r\n -- Defined at Bug.hs:10:1\r\nλ> :i D\r\ndata family D a -- Defined at Bug.hs:13:1\r\ndata instance D a = MkD (Maybe a) -- Defined at Bug.hs:14:25\r\n}}}\r\n\r\nThere are two strange things of note here:\r\n\r\n* The equations for `F1` and `D` do not have any explicit `forall`s displayed at all, despite the fact that `-fprint-explicit-foralls` is enabled.\r\n* The equation for `F2` //does// have an explicit `forall` displayed, but in a rather bizarre fashion:\r\n\r\n{{{\r\nλ> :i F2\r\ntype family F2 a :: *\r\n where [a] F2 a = Maybe a\r\n -- Defined at Bug.hs:10:1\r\n}}}\r\n\r\n I certainly wasn't expecting to see the type variables in square brackets. I would have hoped to see something like this instead:\r\n\r\n{{{\r\nλ> :i F2\r\ntype family F2 a :: *\r\n where forall a. F2 a = Maybe a\r\n -- Defined at Bug.hs:10:1\r\n}}}\r\n\r\nNow that the \"more explicit `forall`s\" proposal is implemented, my hope is that it will be somewhat simple to change the way that this is pretty-printed (we already store the explicit `forall` information within the AST, after all).","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15826Allow registering (Source)Plugins through the GHC API2019-07-07T18:02:49ZDanielGAllow registering (Source)Plugins through the GHC APIOne might expect to be able to load plugins through the GHC API by doing something like:
```
runGHC $ do
dflags <- getSessionDynFlags
setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] }
```
bu...One might expect to be able to load plugins through the GHC API by doing something like:
```
runGHC $ do
dflags <- getSessionDynFlags
setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] }
```
but this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK.
While in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow using (Source)Plugins through the GHC API","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"One might expect to be able to load plugins through the GHC API by doing something like:\r\n\r\n{{{\r\nrunGHC $ do\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] }\r\n}}}\r\n\r\nbut this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK.\r\n\r\nWhile in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1DanielGDanielGhttps://gitlab.haskell.org/ghc/ghc/-/issues/15825Core Lint error from Explicit Foralls Proposal2019-07-07T18:02:50ZIcelandjackCore Lint error from Explicit Foralls ProposalThis is using the recent Explicit Foralls Proposal #14268
```hs
{-# Language RankNTypes #-}
{-# Language PolyKinds #-}
{-# Language KindSignatures #-}
{-# Language DataKinds #-}
{-# Language FlexibleInstances #...This is using the recent Explicit Foralls Proposal #14268
```hs
{-# Language RankNTypes #-}
{-# Language PolyKinds #-}
{-# Language KindSignatures #-}
{-# Language DataKinds #-}
{-# Language FlexibleInstances #-}
{-# Options_GHC -dcore-lint #-}
type C k = (forall (x::k). *)
class X (a :: *)
instance forall (a :: C k). X (a :: *)
```
```
$ ./inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/599_bug.hs
GHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 599_bug.hs, interpreted )
*** Core Lint errors : in result of Desugar (before optimization) ***
<no location info>: warning:
In the expression: C:X @ a_a1yJ
Kind application error in type ‘a_a1yJ’
Function kind = C k_a1yI
Arg kinds = [(x_a1yH, k_a1yG)]
Forall: x_a1xE
k_a1yI
(x_a1yH, k_a1yG)
<no location info>: warning:
In the expression: C:X @ a_a1xG
Kind application error in type ‘a_a1xG’
Function kind = C k_X1xQ
Arg kinds = [(x_a1yv, k_a1xF)]
Forall: x_a1xE
k_X1xQ
(x_a1yv, k_a1xF)
*** Offending Program ***
Rec {
$tcX :: TyCon
[LclIdX]
$tcX
= TyCon
6136962148358085538##
2047526523769221729##
$trModule
(TrNameS "X"#)
0#
$krep_a1zH
$tc'C:X :: TyCon
[LclIdX]
$tc'C:X
= TyCon
12994509767826319747##
2028070155085790741##
$trModule
(TrNameS "'C:X"#)
1#
$krep_a1zJ
$krep_a1zK [InlPrag=NOUSERINLINE[~]] :: KindRep
[LclId]
$krep_a1zK = $WKindRepVar (I# 0#)
$krep_a1zH [InlPrag=NOUSERINLINE[~]] :: KindRep
[LclId]
$krep_a1zH = KindRepFun krep$* $krep_a1zI
$krep_a1zI [InlPrag=NOUSERINLINE[~]] :: KindRep
[LclId]
$krep_a1zI = KindRepTyConApp $tcConstraint ([] @ KindRep)
$krep_a1zJ [InlPrag=NOUSERINLINE[~]] :: KindRep
[LclId]
$krep_a1zJ
= KindRepTyConApp $tcX (: @ KindRep $krep_a1zK ([] @ KindRep))
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "Main"#)
$fXa [InlPrag=NOUSERINLINE CONLIKE]
:: forall k (x :: k) k (a :: C k). X a
[LclIdX[DFunId],
Unf=DFun: \ (@ k_a1xF)
(@ (x_a1yv :: k_a1xF))
(@ k_a1xF)
(@ (a_a1xG :: C k_a1xF)) ->
C:X TYPE: a_a1xG]
$fXa
= \ (@ k_a1yG)
(@ (x_a1yH :: k_a1yG))
(@ k_a1yI)
(@ (a_a1yJ :: C k_a1yI)) ->
C:X @ a_a1yJ
end Rec }
*** End of Offense ***
<no location info>: error:
Compilation had errors
*** Exception: ExitFailure 1
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Core Lint error from Explicit Foralls Proposal","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is using the recent Explicit Foralls Proposal #14268\r\n\r\n{{{#!hs\r\n{-# Language RankNTypes #-}\r\n{-# Language PolyKinds #-}\r\n{-# Language KindSignatures #-}\r\n{-# Language DataKinds #-}\r\n{-# Language FlexibleInstances #-}\r\n\r\n{-# Options_GHC -dcore-lint #-}\r\n\r\ntype C k = (forall (x::k). *)\r\n\r\nclass X (a :: *)\r\ninstance forall (a :: C k). X (a :: *)\r\n}}}\r\n\r\n{{{\r\n$ ./inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/599_bug.hs\r\nGHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 599_bug.hs, interpreted )\r\n*** Core Lint errors : in result of Desugar (before optimization) ***\r\n<no location info>: warning:\r\n In the expression: C:X @ a_a1yJ\r\n Kind application error in type ‘a_a1yJ’\r\n Function kind = C k_a1yI\r\n Arg kinds = [(x_a1yH, k_a1yG)]\r\n Forall: x_a1xE\r\n k_a1yI\r\n (x_a1yH, k_a1yG)\r\n<no location info>: warning:\r\n In the expression: C:X @ a_a1xG\r\n Kind application error in type ‘a_a1xG’\r\n Function kind = C k_X1xQ\r\n Arg kinds = [(x_a1yv, k_a1xF)]\r\n Forall: x_a1xE\r\n k_X1xQ\r\n (x_a1yv, k_a1xF)\r\n*** Offending Program ***\r\nRec {\r\n$tcX :: TyCon\r\n[LclIdX]\r\n$tcX\r\n = TyCon\r\n 6136962148358085538##\r\n 2047526523769221729##\r\n $trModule\r\n (TrNameS \"X\"#)\r\n 0#\r\n $krep_a1zH\r\n\r\n$tc'C:X :: TyCon\r\n[LclIdX]\r\n$tc'C:X\r\n = TyCon\r\n 12994509767826319747##\r\n 2028070155085790741##\r\n $trModule\r\n (TrNameS \"'C:X\"#)\r\n 1#\r\n $krep_a1zJ\r\n\r\n$krep_a1zK [InlPrag=NOUSERINLINE[~]] :: KindRep\r\n[LclId]\r\n$krep_a1zK = $WKindRepVar (I# 0#)\r\n\r\n$krep_a1zH [InlPrag=NOUSERINLINE[~]] :: KindRep\r\n[LclId]\r\n$krep_a1zH = KindRepFun krep$* $krep_a1zI\r\n\r\n$krep_a1zI [InlPrag=NOUSERINLINE[~]] :: KindRep\r\n[LclId]\r\n$krep_a1zI = KindRepTyConApp $tcConstraint ([] @ KindRep)\r\n\r\n$krep_a1zJ [InlPrag=NOUSERINLINE[~]] :: KindRep\r\n[LclId]\r\n$krep_a1zJ\r\n = KindRepTyConApp $tcX (: @ KindRep $krep_a1zK ([] @ KindRep))\r\n\r\n$trModule :: Module\r\n[LclIdX]\r\n$trModule = Module (TrNameS \"main\"#) (TrNameS \"Main\"#)\r\n\r\n$fXa [InlPrag=NOUSERINLINE CONLIKE]\r\n :: forall k (x :: k) k (a :: C k). X a\r\n[LclIdX[DFunId],\r\n Unf=DFun: \\ (@ k_a1xF)\r\n (@ (x_a1yv :: k_a1xF))\r\n (@ k_a1xF)\r\n (@ (a_a1xG :: C k_a1xF)) ->\r\n C:X TYPE: a_a1xG]\r\n$fXa\r\n = \\ (@ k_a1yG)\r\n (@ (x_a1yH :: k_a1yG))\r\n (@ k_a1yI)\r\n (@ (a_a1yJ :: C k_a1yI)) ->\r\n C:X @ a_a1yJ\r\nend Rec }\r\n\r\n*** End of Offense ***\r\n\r\n\r\n<no location info>: error:\r\nCompilation had errors\r\n\r\n\r\n*** Exception: ExitFailure 1\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15821Implement more constant folding for Naturals2021-02-10T03:12:28ZBen GamariImplement more constant folding for Naturals#14465 has already gone a long way in improving the runtime performance of `Natural` numbers. However, we still lack constant folding for these numbers so there is money left on the table.
To fix this you will want to implement rules si...#14465 has already gone a long way in improving the runtime performance of `Natural` numbers. However, we still lack constant folding for these numbers so there is money left on the table.
To fix this you will want to implement rules similar to those for `Integer` in the `PrelRules` module. Additionally, you will need to comment back in the `CONSTANT_FOLDED` pragmas in `GHC.Natural` (see [D5267](https://phabricator.haskell.org/D5267))
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement constant folding for Naturals","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"#14465 has already gone a long way in improving the runtime performance of `Natural` numbers. However, we still lack constant folding for these numbers so there is money left on the table.\r\n\r\nTo fix this you will want to implement rules similar to those for `Integer` in the `PrelRules` module. Additionally, you will need to comment back in the `CONSTANT_FOLDED` pragmas in `GHC.Natural` (see Phab:D5267)","type_of_failure":"OtherFailure","blocking":[]} -->9.0.1Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/15819COMPLETE pragma not listed in GHC manual index2019-07-07T18:02:51ZRichard Eisenbergrae@richarde.devCOMPLETE pragma not listed in GHC manual indexI wanted information on the `COMPLETE` pragma. So I went to GHC's manual's index. And it isn't there!
We should likely have some RST gubbins to support pragmas, in much the same way that we do for flags, as I'm sure this isn't only `COM...I wanted information on the `COMPLETE` pragma. So I went to GHC's manual's index. And it isn't there!
We should likely have some RST gubbins to support pragmas, in much the same way that we do for flags, as I'm sure this isn't only `COMPLETE`'s problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"COMPLETE pragma not listed in GHC manual index","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wanted information on the `COMPLETE` pragma. So I went to GHC's manual's index. And it isn't there!\r\n\r\nWe should likely have some RST gubbins to support pragmas, in much the same way that we do for flags, as I'm sure this isn't only `COMPLETE`'s problem.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15818Bump template-haskell version to 2.15.0.02019-07-07T18:02:51ZRyan ScottBump template-haskell version to 2.15.0.0Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GH...Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, [th-abstraction](https://github.com/glguy/th-abstraction/issues/55)). We should properly bump the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bump template-haskell version to 2.15.0.0","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, [https://github.com/glguy/th-abstraction/issues/55 th-abstraction]). We should properly bump the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15817Data family quantification = GHC panic, ‘impossible’ happened2019-07-07T18:02:52ZIcelandjackData family quantification = GHC panic, ‘impossible’ happened```hs
{-# Language RankNTypes #-}
{-# Language TypeApplications #-}
{-# Language PolyKinds #-}
{-# Language KindSignatures #-}
{-# Language TypeFamilies #-}
data family Pair :: forall a. forall b. *
data instance Pa...```hs
{-# Language RankNTypes #-}
{-# Language TypeApplications #-}
{-# Language PolyKinds #-}
{-# Language KindSignatures #-}
{-# Language TypeFamilies #-}
data family Pair :: forall a. forall b. *
data instance Pair @a @b = MkPair a b
```
```
$ ghci -ignore-dot-ghci 593_bug.hs
GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( 593_bug.hs, interpreted )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.7.20181017 for x86_64-unknown-linux):
ASSERT failed!
kind axiom D:R:Pairabab0 ::
forall a b (a :: a) (b :: b).
Pair = R:Pairabab -- Defined at 593_bug.hs:8:15
forall k k (a :: k) (b :: k). *
forall a b -> a -> b -> *
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable
assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mnguyen |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Visible kind application + data family = GHC panic, ‘impossible’ happened","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":["mnguyen"],"type":"Bug","description":"{{{#!hs\r\n{-# Language RankNTypes #-}\r\n{-# Language TypeApplications #-}\r\n{-# Language PolyKinds #-}\r\n{-# Language KindSignatures #-}\r\n{-# Language TypeFamilies #-}\r\n\r\ndata family Pair :: forall a. forall b. *\r\ndata instance Pair @a @b = MkPair a b\r\n}}}\r\n\r\n{{{\r\n$ ghci -ignore-dot-ghci 593_bug.hs\r\nGHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( 593_bug.hs, interpreted )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20181017 for x86_64-unknown-linux):\r\n ASSERT failed!\r\n kind axiom D:R:Pairabab0 ::\r\n forall a b (a :: a) (b :: b).\r\n Pair = R:Pairabab -- Defined at 593_bug.hs:8:15\r\n forall k k (a :: k) (b :: k). *\r\n forall a b -> a -> b -> *\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable\r\n pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable\r\n assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n>\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15816Visible kind applications + data family: `U :: Type' said to be of kind `k0 -...2019-07-07T18:02:52ZIcelandjackVisible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error messageUsing the [visible kind applications (D5229)](https://phabricator.haskell.org/D5229) (#12045) patch.
GHC erroneously calls `U :: Type` a "function" of kind `k0 -> k1` if I understand this right,
```
$ ghci
GHCi, version 8.7.20181017: ...Using the [visible kind applications (D5229)](https://phabricator.haskell.org/D5229) (#12045) patch.
GHC erroneously calls `U :: Type` a "function" of kind `k0 -> k1` if I understand this right,
```
$ ghci
GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help
Prelude> :set prompt "> "
> import Data.Kind (Type)
>
> :set -XTypeFamilies
> :set -XTypeApplications
>
> data family U :: Type
> data instance U @Int
<interactive>:7:1: error:
• Cannot apply function of kind ‘k0 -> k1’
to visible kind argument ‘Int’
• In the data instance declaration for ‘U’
>
```
I expect something like "Cannot apply type `U` to visible kind argument `Int`" or
```
> data instance U Int = MkU
<interactive>:7:1: error:
• Expected kind ‘* -> *’, but ‘U’ has kind ‘*’
• In the data instance declaration for ‘U’
>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeApplications"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using the [https://phabricator.haskell.org/D5229 visible kind applications (D5229)] (#12045) patch.\r\n\r\nGHC erroneously calls `U :: Type` a \"function\" of kind `k0 -> k1` if I understand this right,\r\n\r\n{{{\r\n$ ghci \r\nGHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :set prompt \"> \"\r\n> import Data.Kind (Type)\r\n>\r\n> :set -XTypeFamilies \r\n> :set -XTypeApplications\r\n>\r\n> data family U :: Type\r\n> data instance U @Int\r\n\r\n<interactive>:7:1: error:\r\n • Cannot apply function of kind ‘k0 -> k1’\r\n to visible kind argument ‘Int’\r\n • In the data instance declaration for ‘U’\r\n> \r\n}}}\r\n\r\nI expect something like \"Cannot apply type `U` to visible kind argument `Int`\" or\r\n\r\n{{{\r\n> data instance U Int = MkU\r\n\r\n<interactive>:7:1: error:\r\n • Expected kind ‘* -> *’, but ‘U’ has kind ‘*’\r\n • In the data instance declaration for ‘U’\r\n> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15812add System.Mem.Address to base2019-07-07T18:02:53ZCarter Schonwaldadd System.Mem.Address to baseper libraries in progress discussion and https://phabricator.haskell.org/D5268
current state is this
```
{-# LANGUAGE MagicHash #-}
Module System.Mem.Address (
-- * Types
Addr(..),
-- * Address arithmetic
nullAddr, plusAddr, m...per libraries in progress discussion and https://phabricator.haskell.org/D5268
current state is this
```
{-# LANGUAGE MagicHash #-}
Module System.Mem.Address (
-- * Types
Addr(..),
-- * Address arithmetic
nullAddr, plusAddr, minusAddr, remAddr,
-- * Conversion
addrToInt, addrToPtr, ptrToAddr
) where
import GHC.Base ( Int(..) )
import GHC.Prim
import GHC.Exts (isTrue#)
import GHC.Ptr
import Foreign.Marshal.Utils
import Data.Typeable ( Typeable )
import Data.Data ( Data(..), mkNoRepType )
-- | A machine address
data Addr = Addr Addr# deriving ( Typeable )
instance Show Addr where
showsPrec _ (Addr a) =
showString "0x" . showHex (fromIntegral (I# (addr2Int# a)) :: Word)
instance Eq Addr where
Addr a# == Addr b# = isTrue# (eqAddr# a# b#)
Addr a# /= Addr b# = isTrue# (neAddr# a# b#)
instance Ord Addr where
Addr a# > Addr b# = isTrue# (gtAddr# a# b#)
Addr a# >= Addr b# = isTrue# (geAddr# a# b#)
Addr a# < Addr b# = isTrue# (ltAddr# a# b#)
Addr a# <= Addr b# = isTrue# (leAddr# a# b#)
instance Data Addr where
toConstr _ = error "toConstr"
gunfold _ _ = error "gunfold"
dataTypeOf _ = mkNoRepType "Data.Primitive.Types.Addr"
-- | The null address
nullAddr :: Addr
nullAddr = Addr nullAddr#
infixl 6 `plusAddr`, `minusAddr`
infixl 7 `remAddr`
-- | Offset an address by the given number of bytes
plusAddr :: Addr -> Int -> Addr
plusAddr (Addr a#) (I# i#) = Addr (plusAddr# a# i#)
-- | Distance in bytes between two addresses. The result is only valid if the
-- difference fits in an 'Int'.
minusAddr :: Addr -> Addr -> Int
minusAddr (Addr a#) (Addr b#) = I# (minusAddr# a# b#)
-- | The remainder of the address and the integer.
remAddr :: Addr -> Int -> Int
remAddr (Addr a#) (I# i#) = I# (remAddr# a# i#)
-- | Convert an 'Addr' to an 'Int'.
addrToInt :: Addr -> Int
{-# INLINE addrToInt #-}
addrToInt (Addr addr#) = I# (addr2Int# addr#)
-- | convert `Addr` to `Ptr a`
addrToPtr :: Addr -> Ptr a
addrToPtr (Addr addr#) = Ptr addr#
-- | convert `Ptr a` to `Addr`
ptrToAddr :: Ptr a -> Addr
ptrToAddr (Ptr p) = Addr p
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------------------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | [D5268](https://phabricator.haskell.org/D5268) |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"add System.Mem.Address to base","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[5268],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"per libraries in progress discussion and https://phabricator.haskell.org/D5268\r\n\r\ncurrent state is this \r\n\r\n{{{\r\n\r\n{-# LANGUAGE MagicHash #-}\r\n\r\nModule System.Mem.Address (\r\n -- * Types\r\n Addr(..),\r\n\r\n -- * Address arithmetic\r\n nullAddr, plusAddr, minusAddr, remAddr,\r\n\r\n -- * Conversion\r\n addrToInt, addrToPtr, ptrToAddr\r\n\r\n\r\n\r\n ) where\r\n\r\n\r\n\r\nimport GHC.Base ( Int(..) )\r\nimport GHC.Prim\r\n\r\nimport GHC.Exts (isTrue#)\r\nimport GHC.Ptr\r\nimport Foreign.Marshal.Utils\r\n\r\nimport Data.Typeable ( Typeable )\r\nimport Data.Data ( Data(..), mkNoRepType )\r\n\r\n\r\n-- | A machine address\r\ndata Addr = Addr Addr# deriving ( Typeable )\r\n\r\ninstance Show Addr where\r\n showsPrec _ (Addr a) =\r\n showString \"0x\" . showHex (fromIntegral (I# (addr2Int# a)) :: Word)\r\n\r\ninstance Eq Addr where\r\n Addr a# == Addr b# = isTrue# (eqAddr# a# b#)\r\n Addr a# /= Addr b# = isTrue# (neAddr# a# b#)\r\n\r\ninstance Ord Addr where\r\n Addr a# > Addr b# = isTrue# (gtAddr# a# b#)\r\n Addr a# >= Addr b# = isTrue# (geAddr# a# b#)\r\n Addr a# < Addr b# = isTrue# (ltAddr# a# b#)\r\n Addr a# <= Addr b# = isTrue# (leAddr# a# b#)\r\n\r\ninstance Data Addr where\r\n toConstr _ = error \"toConstr\"\r\n gunfold _ _ = error \"gunfold\"\r\n dataTypeOf _ = mkNoRepType \"Data.Primitive.Types.Addr\"\r\n\r\n-- | The null address\r\nnullAddr :: Addr\r\nnullAddr = Addr nullAddr#\r\n\r\ninfixl 6 `plusAddr`, `minusAddr`\r\ninfixl 7 `remAddr`\r\n\r\n-- | Offset an address by the given number of bytes\r\nplusAddr :: Addr -> Int -> Addr\r\nplusAddr (Addr a#) (I# i#) = Addr (plusAddr# a# i#)\r\n\r\n-- | Distance in bytes between two addresses. The result is only valid if the\r\n-- difference fits in an 'Int'.\r\nminusAddr :: Addr -> Addr -> Int\r\nminusAddr (Addr a#) (Addr b#) = I# (minusAddr# a# b#)\r\n\r\n-- | The remainder of the address and the integer.\r\nremAddr :: Addr -> Int -> Int\r\nremAddr (Addr a#) (I# i#) = I# (remAddr# a# i#)\r\n\r\n-- | Convert an 'Addr' to an 'Int'.\r\naddrToInt :: Addr -> Int\r\n{-# INLINE addrToInt #-}\r\naddrToInt (Addr addr#) = I# (addr2Int# addr#)\r\n\r\n-- | convert `Addr` to `Ptr a`\r\naddrToPtr :: Addr -> Ptr a\r\naddrToPtr (Addr addr#) = Ptr addr#\r\n\r\n-- | convert `Ptr a` to `Addr`\r\nptrToAddr :: Ptr a -> Addr\r\nptrToAddr (Ptr p) = Addr p\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1