GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:01:01Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16193Nondeterministic T15897 timeout failures2019-07-07T18:01:01ZRyan ScottNondeterministic T15897 timeout failuresI'm noticing sporadic test failures for `T15897`. Here is [one recent example](https://ghc-gitlab.s3.amazonaws.com/43/4c/434c9b5ae514646bbd91b50032ca579efec8f22bf0b4aac12e65997c418e0dd6/2019_01_16/12262/16763/job.log?response-content-typ...I'm noticing sporadic test failures for `T15897`. Here is [one recent example](https://ghc-gitlab.s3.amazonaws.com/43/4c/434c9b5ae514646bbd91b50032ca579efec8f22bf0b4aac12e65997c418e0dd6/2019_01_16/12262/16763/job.log?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content-disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190116T140554Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190116/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=a8e95f4ef77f5dc5fd38a8ee4f4ccdbb25c1671f8be3b767de21004a2dd407a8):
```
Wrong exit code for T15897()(expected 0 , actual 99 )
*** unexpected failure for T15897(profasm)
```
This was on the `validate-x86_64-linux-deb9-unreg` CI configuration, although it's unclear to me if the problem is exclusive to that configuration or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | osa1 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Nondeterministic T15897 timeout failures","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["osa1"],"type":"Bug","description":"I'm noticing sporadic test failures for `T15897`. Here is [https://ghc-gitlab.s3.amazonaws.com/43/4c/434c9b5ae514646bbd91b50032ca579efec8f22bf0b4aac12e65997c418e0dd6/2019_01_16/12262/16763/job.log?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content-disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190116T140554Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190116/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=a8e95f4ef77f5dc5fd38a8ee4f4ccdbb25c1671f8be3b767de21004a2dd407a8 one recent example]:\r\n\r\n{{{\r\nWrong exit code for T15897()(expected 0 , actual 99 )\r\n*** unexpected failure for T15897(profasm)\r\n}}}\r\n\r\nThis was on the `validate-x86_64-linux-deb9-unreg` CI configuration, although it's unclear to me if the problem is exclusive to that configuration or not.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16192Simplifier does not preserve dependency ordering of the program2019-07-07T18:01:01ZÖmer Sinan AğacanSimplifier does not preserve dependency ordering of the programI noticed this some time ago, but I thought this is expected, because
there's a comment in CoreLint that mentions this:
```
lintCoreBindings dflags pass local_in_scope binds
= initL dflags flags in_scope_set $
addLoc TopLevelBindi...I noticed this some time ago, but I thought this is expected, because
there's a comment in CoreLint that mentions this:
```
lintCoreBindings dflags pass local_in_scope binds
= initL dflags flags in_scope_set $
addLoc TopLevelBindings $
lintLetBndrs TopLevel binders $
-- Put all the top-level binders in scope at the start
-- This is because transformation rules can bring something
-- into use 'unexpectedly'
...
```
However talking to SPJ today he mentioned that in Core we should actually
preserve dependency ordering, hence this ticket.
I'll update with a reproducer.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"Simplifier does not preserve dependency ordering of the program","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I noticed this some time ago, but I thought this is expected, because\r\nthere's a comment in CoreLint that mentions this:\r\n\r\n{{{\r\nlintCoreBindings dflags pass local_in_scope binds\r\n = initL dflags flags in_scope_set $\r\n addLoc TopLevelBindings $\r\n lintLetBndrs TopLevel binders $\r\n -- Put all the top-level binders in scope at the start\r\n -- This is because transformation rules can bring something\r\n -- into use 'unexpectedly'\r\n ...\r\n}}}\r\n\r\nHowever talking to SPJ today he mentioned that in Core we should actually\r\npreserve dependency ordering, hence this ticket.\r\n\r\nI'll update with a reproducer.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16189ParsedSource (especially module name source span) not available from Source P...2020-01-23T19:38:55ZliteronParsedSource (especially module name source span) not available from Source PluginAs discovered in https://github.com/google/haskell-indexer/pull/89\#discussion_r248081268, the `TcGblEnv` received by a Source Plugin doesn't seem to have a way of accessing the SrcSpan of the module name.
When having access to the Pars...As discovered in https://github.com/google/haskell-indexer/pull/89\#discussion_r248081268, the `TcGblEnv` received by a Source Plugin doesn't seem to have a way of accessing the SrcSpan of the module name.
When having access to the ParsedModule, it contains ParsedSource, which is `Located (HsModule GhcPs)`, whose inner datatype contains `Maybe (Located ModuleName)`, with the location's span pointing to the module name span.
From `TcGblEnv` one can access the `ModSummary`, which has a `Maybe HsParsedModule`, but seems to be `Nothing` practically.
I know this is a minor nit, but all other declarations are accessible by the source plugin so far, just this bit seems missing. Without this, haskell-indexer has to resort to source-code heuristics to get the module name span.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ParsedSource (especially module name source span) not available from Source Plugin","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As discovered in https://github.com/google/haskell-indexer/pull/89#discussion_r248081268, the `TcGblEnv` received by a Source Plugin doesn't seem to have a way of accessing the SrcSpan of the module name.\r\n\r\nWhen having access to the ParsedModule, it contains ParsedSource, which is `Located (HsModule GhcPs)`, whose inner datatype contains `Maybe (Located ModuleName)`, with the location's span pointing to the module name span.\r\n\r\nFrom `TcGblEnv` one can access the `ModSummary`, which has a `Maybe HsParsedModule`, but seems to be `Nothing` practically.\r\n\r\nI know this is a minor nit, but all other declarations are accessible by the source plugin so far, just this bit seems missing. Without this, haskell-indexer has to resort to source-code heuristics to get the module name span.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16178Brackets and splices should be overloaded like the static keyword2019-07-07T18:01:06ZMatthew PickeringBrackets and splices should be overloaded like the static keywordIt's quite convenient that the `static` keyword is rebindable. To recap, if `e :: T` then `static e :: (IsStatic p) => p t`.
It should also be possible rebind brackets and splices in the same manner.
So we introduce two type classes `Is...It's quite convenient that the `static` keyword is rebindable. To recap, if `e :: T` then `static e :: (IsStatic p) => p t`.
It should also be possible rebind brackets and splices in the same manner.
So we introduce two type classes `IsBracket` and `IsSplice`. Now quoting a term `e :: T` has type `e :: IsBracket p => p T` and the argument to a splice
must have type `e :: IsSplice p => p T` which results in a value of type `T`.
```
class IsBracket p where
fromBracket :: Code t -> p t
class IsSplice p where
toBracket :: p t -> Code t
foo :: IsBracket p => p Int
foo = [|| 5 ||]
qux :: (IsSplice p, IsBracket p) => Int
qux = $$(foo)
```
As an aside, arguably the `static` form should only be rebindable when `RebindableSyntax` is enabled but that boat seems to have sailed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Brackets and splices should be overloaded like the static keyword","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["TypedTemplateHaskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"It's quite convenient that the `static` keyword is rebindable. To recap, if `e :: T` then `static e :: (IsStatic p) => p t`. \r\n\r\nIt should also be possible rebind brackets and splices in the same manner. \r\nSo we introduce two type classes `IsBracket` and `IsSplice`. Now quoting a term `e :: T` has type `e :: IsBracket p => p T` and the argument to a splice\r\nmust have type `e :: IsSplice p => p T` which results in a value of type `T`. \r\n\r\n{{{\r\nclass IsBracket p where\r\n fromBracket :: Code t -> p t\r\n\r\nclass IsSplice p where\r\n toBracket :: p t -> Code t\r\n\r\nfoo :: IsBracket p => p Int\r\nfoo = [|| 5 ||]\r\n\r\nqux :: (IsSplice p, IsBracket p) => Int\r\nqux = $$(foo)\r\n}}}\r\n\r\n\r\nAs an aside, arguably the `static` form should only be rebindable when `RebindableSyntax` is enabled but that boat seems to have sailed. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16176Let-insertion for template haskell2019-07-07T18:01:07ZMatthew PickeringLet-insertion for template haskellWhen using Template Haskell to generate programs it's very easy to end up with a lot of duplication as splices are naively spliced in place.
For example
```
foo x = [|| $$x + $$x ||]
```
Will generate a program which completely duplic...When using Template Haskell to generate programs it's very easy to end up with a lot of duplication as splices are naively spliced in place.
For example
```
foo x = [|| $$x + $$x ||]
```
Will generate a program which completely duplicates its argument. In this case I can manually remove the duplicate by inserting a let.
```
foo x = [|| let x' = $$x in x' + x' ||]
```
Not too bad but a bit annoying to have to do manually.
When constructing bigger programs however this process becomes tedious or impossible to do correctly by hand.
```
foo :: (Q (TExp (Bool)) -> Q (TExp Int)) -> Q (TExp Int)
foo xf = [|| (let x = True in $$(xf [|| x ||])) + (let x = False in $$(xf [|| x ||]) ||]
```
Now if I pass a constant function to `foo`, the resulting code won't mention `x` so it could be floated out. However, there's not way I can tell that without running `xf` so I can't perform the same transformation as I did for the earlier program and manually insert a let. In the case of splicing in fully static data you really want it to float to the top-level and turn into a CAF.
The proposal of this ticket is to implement something like the mechanism for let-insertion in
metaocaml.
http://okmij.org/ftp/meta-programming/\#let-insert
We add two new primitives:
```
genlet :: Q (TExp a) -> Q (TExp a)
let_locus :: Q (TExp a) -> Q (TExp a)
```
`genlet` marks a code value that we want to float. `let_locus` marks places where we want to insert a let. When we evaluate the code fragment and encounter a `genlet` call, whatever the argument evaluates to is floated as far upwards as possible and inserted at the position of one of the loci.
For example,
```
sqr :: Code Int -> Code Int
sqr c = [|| $$c + $$c ||]
sqr_let :: Code Int -> Code Int
sqr_let c = let_locus (sqr (genlet c))
```
Splicing `sqr [|| 1 ||]` will result in `1 + 1` but `sqr_let [|| c ||]` will equal `let x = 1 in x + x ||]`.
It's important to do this earlier rather than later as a lot of duplication can take place which the simplifier does not like.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Let-insertion for template haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["TypedTemplateHaskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When using Template Haskell to generate programs it's very easy to end up with a lot of duplication as splices are naively spliced in place. \r\n\r\nFor example\r\n\r\n{{{\r\nfoo x = [|| $$x + $$x ||]\r\n}}}\r\n\r\nWill generate a program which completely duplicates its argument. In this case I can manually remove the duplicate by inserting a let.\r\n\r\n{{{\r\nfoo x = [|| let x' = $$x in x' + x' ||]\r\n}}}\r\n\r\nNot too bad but a bit annoying to have to do manually. \r\n\r\nWhen constructing bigger programs however this process becomes tedious or impossible to do correctly by hand.\r\n\r\n{{{\r\nfoo :: (Q (TExp (Bool)) -> Q (TExp Int)) -> Q (TExp Int) \r\nfoo xf = [|| (let x = True in $$(xf [|| x ||])) + (let x = False in $$(xf [|| x ||]) ||]\r\n}}}\r\n\r\nNow if I pass a constant function to `foo`, the resulting code won't mention `x` so it could be floated out. However, there's not way I can tell that without running `xf` so I can't perform the same transformation as I did for the earlier program and manually insert a let. In the case of splicing in fully static data you really want it to float to the top-level and turn into a CAF.\r\n\r\nThe proposal of this ticket is to implement something like the mechanism for let-insertion in\r\nmetaocaml.\r\n\r\nhttp://okmij.org/ftp/meta-programming/#let-insert\r\n\r\nWe add two new primitives:\r\n\r\n{{{\r\ngenlet :: Q (TExp a) -> Q (TExp a)\r\nlet_locus :: Q (TExp a) -> Q (TExp a)\r\n}}}\r\n\r\n`genlet` marks a code value that we want to float. `let_locus` marks places where we want to insert a let. When we evaluate the code fragment and encounter a `genlet` call, whatever the argument evaluates to is floated as far upwards as possible and inserted at the position of one of the loci. \r\n\r\nFor example,\r\n\r\n{{{\r\nsqr :: Code Int -> Code Int\r\nsqr c = [|| $$c + $$c ||]\r\n\r\nsqr_let :: Code Int -> Code Int\r\nsqr_let c = let_locus (sqr (genlet c))\r\n}}}\r\n\r\nSplicing `sqr [|| 1 ||]` will result in `1 + 1` but `sqr_let [|| c ||]` will equal `let x = 1 in x + x ||]`. \r\n\r\nIt's important to do this earlier rather than later as a lot of duplication can take place which the simplifier does not like. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16175wrong wording (and possibly wrong location) in parse error message for "do $ ...2019-07-07T18:01:07Zwaldmann@imn.htwk-leipzig.dewrong wording (and possibly wrong location) in parse error message for "do $ bar"Not a bug, as GHC correctly rejects an invalid program. Still -
```
Prelude> foo x = do $ bar ; return ()
<interactive>:1:20: error:
Parse error: module header, import declaration
or top-level declaration expected.
```
Of the ...Not a bug, as GHC correctly rejects an invalid program. Still -
```
Prelude> foo x = do $ bar ; return ()
<interactive>:1:20: error:
Parse error: module header, import declaration
or top-level declaration expected.
```
Of the three suggestions, only "top-level declaration" can actually happen here (as this also happens deep inside a module).
For reference,
- ghc-7.10 : "parse error on input ‘=’"
- ghc-8.0 : "naked expression at top level"
- ghc-8.2 and later: as above
I think the wording was introduced with
#12146
Anyway one could also think that the actual error happened earlier, since after removing "return ()" as suggested by the error message, we get
```
Prelude> foo x = do $ bar
<interactive>:1:9: error: Empty 'do' block
```
so GHC could also use this as the original error message? By putting "; return ()" at the end, the 'do' block does not become non-empty?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"wrong wording (and possibly wrong location) in parse error message for \"do $ bar\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Not a bug, as GHC correctly rejects an invalid program. Still -\r\n{{{\r\nPrelude> foo x = do $ bar ; return ()\r\n\r\n<interactive>:1:20: error:\r\n Parse error: module header, import declaration\r\n or top-level declaration expected.\r\n}}}\r\nOf the three suggestions, only \"top-level declaration\" can actually happen here (as this also happens deep inside a module).\r\n\r\n\r\nFor reference, \r\n* ghc-7.10 : \"parse error on input ‘=’\"\r\n* ghc-8.0 : \"naked expression at top level\"\r\n* ghc-8.2 and later: as above\r\n\r\nI think the wording was introduced with \r\nhttps://ghc.haskell.org/trac/ghc/ticket/12146\r\n\r\nAnyway one could also think that the actual error happened earlier, since after removing \"return ()\" as suggested by the error message, we get\r\n{{{\r\nPrelude> foo x = do $ bar\r\n\r\n<interactive>:1:9: error: Empty 'do' block\r\n}}}\r\nso GHC could also use this as the original error message? By putting \"; return ()\" at the end, the 'do' block does not become non-empty?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16171"ApplicativeDo" disables -Wunused-do-binds?2023-03-31T13:19:35ZErik Schnetter"ApplicativeDo" disables -Wunused-do-binds?In the code below, the return value of `forkIO` is ignored. The compiler does not warn about this. When I disable the `ApplicativeDo` extension, the warning appears as expected.
```
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE ApplicativeDo #...In the code below, the return value of `forkIO` is ignored. The compiler does not warn about this. When I disable the `ApplicativeDo` extension, the warning appears as expected.
```
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE ApplicativeDo #-}
module Example (main) where
import Control.Concurrent
main :: IO ()
main = do x <- return ()
forkIO (putStrLn "hello")
putStrLn $ "world" ++ show x
```https://gitlab.haskell.org/ghc/ghc/-/issues/16169Unused variable warning affects compositionality when generating code2019-10-03T08:46:45ZMatthew PickeringUnused variable warning affects compositionality when generating codeIf I'm generating a program using template haskell, I might define
a combinator to help me generate lambdas.
```
type Code a = Q (TExp a)
_lam :: (Code a -> Code b) -> Code (a -> b)
_lam f = [|| \a -> $$(f [|| a ||]) ||]
```
However, ...If I'm generating a program using template haskell, I might define
a combinator to help me generate lambdas.
```
type Code a = Q (TExp a)
_lam :: (Code a -> Code b) -> Code (a -> b)
_lam f = [|| \a -> $$(f [|| a ||]) ||]
```
However, if I now pass a constant function into `_lam`, the generated code contains an unused variable `a` that I can do nothing about and desire not to do anything about.
```
c5 :: Code (a -> Int)
c5 = _lam (const [|| 5 ||])
```
However, GHC decides that it's wise to warn me about this when I splice it in.
```
> $$c5
F2.hs:6:5: warning: [-Wunused-matches] Defined but not used: ‘a’
|
6 | q = $$c5
| ^^^
```
As Ryan will tell you, I'm against emitting warnings from generated code as it breaks the abstraction. The code that is generated is guaranteed to be type and scope correct but any aesthetic warning is irrelevant to the consumer.
I see it in precisely the same way as warning if we use a function that contains an unused variable in a library. Once the definition is exported from the library, its definition is opaque. The same principle should be applied to code generated by template haskell.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"Unused variable warning affects compositionality when generating code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I'm generating a program using template haskell, I might define\r\na combinator to help me generate lambdas. \r\n\r\n{{{\r\ntype Code a = Q (TExp a)\r\n\r\n_lam :: (Code a -> Code b) -> Code (a -> b)\r\n_lam f = [|| \\a -> $$(f [|| a ||]) ||]\r\n}}}\r\n\r\nHowever, if I now pass a constant function into `_lam`, the generated code contains an unused variable `a` that I can do nothing about and desire not to do anything about.\r\n\r\n{{{\r\nc5 :: Code (a -> Int)\r\nc5 = _lam (const [|| 5 ||])\r\n}}}\r\n\r\nHowever, GHC decides that it's wise to warn me about this when I splice it in.\r\n\r\n{{{\r\n> $$c5\r\nF2.hs:6:5: warning: [-Wunused-matches] Defined but not used: ‘a’\r\n |\r\n6 | q = $$c5\r\n | ^^^\r\n}}}\r\n\r\nAs Ryan will tell you, I'm against emitting warnings from generated code as it breaks the abstraction. The code that is generated is guaranteed to be type and scope correct but any aesthetic warning is irrelevant to the consumer. \r\n\r\nI see it in precisely the same way as warning if we use a function that contains an unused variable in a library. Once the definition is exported from the library, its definition is opaque. The same principle should be applied to code generated by template haskell. \r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16162External interpreter is broken on Windows2019-07-07T18:01:13ZBen GamariExternal interpreter is broken on WindowsThere is plenty of evidence to suggest that the external interpreter is currently broken on Windows:
- #14271 reports crashes when running `ghci`
- #16156 reports a number of testsuite failures, particularly in the `ghci-ext-prof` way.There is plenty of evidence to suggest that the external interpreter is currently broken on Windows:
- #14271 reports crashes when running `ghci`
- #16156 reports a number of testsuite failures, particularly in the `ghci-ext-prof` way.https://gitlab.haskell.org/ghc/ghc/-/issues/16161plugin-recomp-impure fails on Windows2021-08-09T14:21:33ZBen Gamariplugin-recomp-impure fails on Windows```
Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 )
Stdout ( plugin-recomp-impure ):
[1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o )
Stderr ( plugin-recomp-impure ):
Access violation...```
Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 )
Stdout ( plugin-recomp-impure ):
[1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o )
Stderr ( plugin-recomp-impure ):
Access violation in generated code when executing data at 0x0
Attempting to reconstruct a stack trace...
Frame Code address
Null address
make[2]: *** [Makefile:98: plugin-recomp-impure] Error 11
*** unexpected failure for plugin-recomp-impure(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"plugin-recomp-impure fails on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nWrong exit code for plugin-recomp-impure()(expected 0 , actual 2 )\r\nStdout ( plugin-recomp-impure ):\r\n[1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o )\r\nStderr ( plugin-recomp-impure ):\r\nAccess violation in generated code when executing data at 0x0\r\n\r\n Attempting to reconstruct a stack trace...\r\n\r\n Frame\tCode address\r\nNull address\r\n\r\nmake[2]: *** [Makefile:98: plugin-recomp-impure] Error 11\r\n*** unexpected failure for plugin-recomp-impure(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16160TH_NestedSplices fails on Windows2019-07-07T18:01:14ZBen GamariTH_NestedSplices fails on Windows```
Compile failed (exit code 11) errors were:
Access violation in generated code when executing data at 0x0
Attempting to reconstruct a stack trace...
Frame Code address
Null address
*** unexpected failure for TH_NestedSplices(...```
Compile failed (exit code 11) errors were:
Access violation in generated code when executing data at 0x0
Attempting to reconstruct a stack trace...
Frame Code address
Null address
*** unexpected failure for TH_NestedSplices(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"TH_NestedSplices fails on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nCompile failed (exit code 11) errors were:\r\n\r\nAccess violation in generated code when executing data at 0x0\r\n\r\n Attempting to reconstruct a stack trace...\r\n\r\n Frame\tCode address\r\nNull address\r\n\r\n\r\n*** unexpected failure for TH_NestedSplices(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.4https://gitlab.haskell.org/ghc/ghc/-/issues/16159plugin-recomp-change fails on Windows2021-08-09T14:21:08ZBen Gamariplugin-recomp-change fails on Windows```
Wrong exit code for plugin-recomp-change()(expected 0 , actual 2 )
Stderr ( plugin-recomp-change ):
Simple Plugin Passes Queried
Got options:
Simple Plugin Pass Run
C://GitLabRunner//builds//78d7d3f9//0//ghc//ghc//inplace//mingw//bi...```
Wrong exit code for plugin-recomp-change()(expected 0 , actual 2 )
Stderr ( plugin-recomp-change ):
Simple Plugin Passes Queried
Got options:
Simple Plugin Pass Run
C://GitLabRunner//builds//78d7d3f9//0//ghc//ghc//inplace//mingw//bin/ld.exe: cannot find -lHSplugin-recompilation-0.1-7bwXt6gOi6GLkV25gq6uB8
collect2.exe: error: ld returned 1 exit status
`gcc.exe' failed in phase `Linker'. (Exit code: 1)
make[2]: *** [Makefile:112: plugin-recomp-change] Error 1
*** unexpected failure for plugin-recomp-change(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"plugin-recomp-change fails on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nWrong exit code for plugin-recomp-change()(expected 0 , actual 2 )\r\nStderr ( plugin-recomp-change ):\r\nSimple Plugin Passes Queried\r\nGot options: \r\nSimple Plugin Pass Run\r\nC://GitLabRunner//builds//78d7d3f9//0//ghc//ghc//inplace//mingw//bin/ld.exe: cannot find -lHSplugin-recompilation-0.1-7bwXt6gOi6GLkV25gq6uB8\r\ncollect2.exe: error: ld returned 1 exit status\r\n`gcc.exe' failed in phase `Linker'. (Exit code: 1)\r\nmake[2]: *** [Makefile:112: plugin-recomp-change] Error 1\r\n*** unexpected failure for plugin-recomp-change(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16158T15094 fails on Windows2019-07-07T18:01:15ZBen GamariT15094 fails on Windows`T15904` fails with:
```
=====> T15904(normal) 1996 of 6747 [0, 6, 0]
cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904
Wrong exit code for T15904()(expected 0 , actual 2 )
Stdout ( T15904 ):
[1 of 1] Compiling T15904 ...`T15904` fails with:
```
=====> T15904(normal) 1996 of 6747 [0, 6, 0]
cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904
Wrong exit code for T15904()(expected 0 , actual 2 )
Stdout ( T15904 ):
[1 of 1] Compiling T15904 ( T15904.hs, T15904.o )
Linking "T15904".exe ...
Stderr ( T15904 ):
"T15904".exe.manifest: openFile: invalid argument (Invalid argument)
make[2]: *** [Makefile:7: T15904] Error 1
*** unexpected failure for T15904(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Phyx |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T15094 fails on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["Phyx"],"type":"Bug","description":"`T15904` fails with:\r\n{{{\r\n=====> T15904(normal) 1996 of 6747 [0, 6, 0]\r\ncd \"hp2ps/T15904.run\" && $MAKE -s --no-print-directory T15904 \r\nWrong exit code for T15904()(expected 0 , actual 2 )\r\nStdout ( T15904 ):\r\n[1 of 1] Compiling T15904 ( T15904.hs, T15904.o )\r\nLinking \"T15904\".exe ...\r\nStderr ( T15904 ):\r\n\"T15904\".exe.manifest: openFile: invalid argument (Invalid argument)\r\nmake[2]: *** [Makefile:7: T15904] Error 1\r\n*** unexpected failure for T15904(normal)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16157Duplicate symbol error on Windows2019-07-07T18:01:15ZBen GamariDuplicate symbol error on Windows`T11072gcc` is failing on Windows with
```
Wrong exit code for T11072gcc()(expected 0 , actual 2 )
Stderr ( T11072gcc ):
GHC runtime linker: fatal error: I found a duplicate definition for symbol
ghczmprim_GHCziClasses_zdp31ZLzvz2cUz...`T11072gcc` is failing on Windows with
```
Wrong exit code for T11072gcc()(expected 0 , actual 2 )
Stderr ( T11072gcc ):
GHC runtime linker: fatal error: I found a duplicate definition for symbol
ghczmprim_GHCziClasses_zdp31ZLzvz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUzvZR_info
whilst processing object file
C:\GitLabRunner\builds\78d7d3f9\0\ghc\ghc\testsuite\tests\ghci\linking\dyn\T11072gcc.run\bin_impl_gcc\libASx.dll.a
The symbol was previously defined in
C:\GitLabRunner\builds\78d7d3f9\0\ghc\ghc\libraries\ghc-prim\dist-install\build\HSghc-prim-0.5.3.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
ghc-stage2.exe: panic! (the 'impossible' happened)
(GHC version 8.7.20190106 for x86_64-unknown-mingw32):
loadArchive "C:\\GitLabRunner\\builds\\78d7d3f9\\0\\ghc\\ghc\\testsuite\\tests\\ghci\\linking\\dyn\\T11072gcc.run\\bin_impl_gcc\\libASx.dll.a": failed
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
make[2]: *** [Makefile:85: compile_libAS_impl_gcc] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"Duplicate symbol error on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`T11072gcc` is failing on Windows with\r\n{{{\r\nWrong exit code for T11072gcc()(expected 0 , actual 2 )\r\nStderr ( T11072gcc ):\r\nGHC runtime linker: fatal error: I found a duplicate definition for symbol\r\n ghczmprim_GHCziClasses_zdp31ZLzvz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUzvZR_info\r\nwhilst processing object file\r\n C:\\GitLabRunner\\builds\\78d7d3f9\\0\\ghc\\ghc\\testsuite\\tests\\ghci\\linking\\dyn\\T11072gcc.run\\bin_impl_gcc\\libASx.dll.a\r\nThe symbol was previously defined in\r\n C:\\GitLabRunner\\builds\\78d7d3f9\\0\\ghc\\ghc\\libraries\\ghc-prim\\dist-install\\build\\HSghc-prim-0.5.3.o\r\nThis could be caused by:\r\n * Loading two different object files which export the same symbol\r\n * Specifying the same object file twice on the GHCi command line\r\n * An incorrect `package.conf' entry, causing some object to be\r\n loaded twice.\r\nghc-stage2.exe: panic! (the 'impossible' happened)\r\n (GHC version 8.7.20190106 for x86_64-unknown-mingw32):\r\n\tloadArchive \"C:\\\\GitLabRunner\\\\builds\\\\78d7d3f9\\\\0\\\\ghc\\\\ghc\\\\testsuite\\\\tests\\\\ghci\\\\linking\\\\dyn\\\\T11072gcc.run\\\\bin_impl_gcc\\\\libASx.dll.a\": failed\r\n\r\nPlease report this as a GHC bug: https://www.haskell.org/ghc/reportabug\r\n\r\nmake[2]: *** [Makefile:85: compile_libAS_impl_gcc] Error 1\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16155Pattern Synonym for Ratio2019-07-07T18:01:16ZZemylaPattern Synonym for Ratio`Data.Ratio` should export a simple pattern synonym that can be used by `Safe` code.
```hs
infixl 7 :%:
pattern n :%: d <- n :% d where
n :%: d = n % d
```
It'd be much simpler to use than `numerator` and `denominator`, and pattern ...`Data.Ratio` should export a simple pattern synonym that can be used by `Safe` code.
```hs
infixl 7 :%:
pattern n :%: d <- n :% d where
n :%: d = n % d
```
It'd be much simpler to use than `numerator` and `denominator`, and pattern matching on it would turn into a regular pattern match, hopefully for free.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pattern Synonym for Ratio","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["PatternSynonyms,","Ratio"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"`Data.Ratio` should export a simple pattern synonym that can be used by `Safe` code.\r\n\r\n{{{#!hs\r\ninfixl 7 :%:\r\n\r\npattern n :%: d <- n :% d where\r\n n :%: d = n % d\r\n}}}\r\n\r\nIt'd be much simpler to use than `numerator` and `denominator`, and pattern matching on it would turn into a regular pattern match, hopefully for free.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16154-Wredundant-constraints: False positive2023-04-03T10:46:04ZFumiaki Kinoshita-Wredundant-constraints: False positiveGHC produces a warning for the attached source, although it won't compile if the suggested constraints are removed:
```
redundant-constraint.hs:24:1: warning: [-Wredundant-constraints]
• Redundant constraints: (KnownNat 42, Capture ...GHC produces a warning for the attached source, although it won't compile if the suggested constraints are removed:
```
redundant-constraint.hs:24:1: warning: [-Wredundant-constraints]
• Redundant constraints: (KnownNat 42, Capture 42 p)
• In the type signature for:
foo :: Foo 42
|
24 | foo :: Foo 42
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.3 |
| 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":"-Wredundant-constraints: False positive","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC produces a warning for the attached source, although it won't compile if the suggested constraints are removed:\r\n\r\n{{{\r\nredundant-constraint.hs:24:1: warning: [-Wredundant-constraints]\r\n • Redundant constraints: (KnownNat 42, Capture 42 p)\r\n • In the type signature for:\r\n foo :: Foo 42\r\n |\r\n24 | foo :: Foo 42\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16153ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10...2019-07-07T18:01:16Zfxcoudertghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14)We at Homebrew are trying to upgrade the ghc version we ship to 8.6.3. However, many test failures are occurring: https://github.com/Homebrew/homebrew-core/pull/35773
```
SUMMARY for test run started at Tue Jan 8 18:16:47 2019 GMT
0:5...We at Homebrew are trying to upgrade the ghc version we ship to 8.6.3. However, many test failures are occurring: https://github.com/Homebrew/homebrew-core/pull/35773
```
SUMMARY for test run started at Tue Jan 8 18:16:47 2019 GMT
0:55:14 spent to go through
6521 total tests, which gave rise to
25300 test cases, of which
18851 were skipped
28 had missing libraries
5900 expected passes
90 expected failures
0 caused framework failures
0 caused framework warnings
1 unexpected passes
422 unexpected failures
8 unexpected stat failures
```
I am attaching the full build output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"We at Homebrew are trying to upgrade the ghc version we ship to 8.6.3. However, many test failures are occurring: https://github.com/Homebrew/homebrew-core/pull/35773\r\n\r\n{{{\r\nSUMMARY for test run started at Tue Jan 8 18:16:47 2019 GMT\r\n 0:55:14 spent to go through\r\n 6521 total tests, which gave rise to\r\n 25300 test cases, of which\r\n 18851 were skipped\r\n\r\n 28 had missing libraries\r\n 5900 expected passes\r\n 90 expected failures\r\n\r\n 0 caused framework failures\r\n 0 caused framework warnings\r\n 1 unexpected passes\r\n 422 unexpected failures\r\n 8 unexpected stat failures\r\n}}}\r\n\r\nI am attaching the full build output.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16151GHC 8.6 build failure on ARM2022-02-07T20:01:13ZdustinGHC 8.6 build failure on ARMI'm attempting to build the ghc-8.6 branch on ARM linux. I have GHC 8.2.2 and LLVM 6.0.1 installed.
My only build.mk change is to set BuildFlavour=quick
I've made it as far as "final phase" where I get the following failure:
```
===--...I'm attempting to build the ghc-8.6 branch on ARM linux. I have GHC 8.2.2 and LLVM 6.0.1 installed.
My only build.mk change is to set BuildFlavour=quick
I've made it as far as "final phase" where I get the following failure:
```
===--- building final phase
/usr/bin/make --no-print-directory -f ghc.mk phase=final all
"inplace/bin/ghc-stage1" -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -optc-D
NOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
/tmp/ghc154171_0/ghc_8.s: Assembler messages:
/tmp/ghc154171_0/ghc_8.s:32:0: error:
Error: selected processor does not support `movw r7,:lower16:stg_enter_info' in ARM mode
|
32 | movw r7, :lower16:stg_enter_info
| ^
/tmp/ghc154171_0/ghc_8.s:33:0: error:
Error: selected processor does not support `movt r7,:upper16:stg_enter_info' in ARM mode
|
33 | movt r7, :upper16:stg_enter_info
| ^
/tmp/ghc154171_0/ghc_8.s:231:0: error:
Error: selected processor does not support `movw r2,#32512' in ARM mode
|
231 | movw r2, #32512
| ^
/tmp/ghc154171_0/ghc_8.s:233:0: error:
Error: selected processor does not support `movt r2,#640' in ARM mode
|
233 | movt r2, #640
| ^
`gcc' failed in phase `Assembler'. (Exit code: 1)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"GHC 8.6 build failure on ARM","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm attempting to build the ghc-8.6 branch on ARM linux. I have GHC 8.2.2 and LLVM 6.0.1 installed.\r\n\r\nMy only build.mk change is to set BuildFlavour=quick\r\n\r\nI've made it as far as \"final phase\" where I get the following failure:\r\n\r\n{{{\r\n===--- building final phase \r\n/usr/bin/make --no-print-directory -f ghc.mk phase=final all \r\n\"inplace/bin/ghc-stage1\" -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -optc-D\r\nNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o\r\n/tmp/ghc154171_0/ghc_8.s: Assembler messages: \r\n \r\n/tmp/ghc154171_0/ghc_8.s:32:0: error: \r\n Error: selected processor does not support `movw r7,:lower16:stg_enter_info' in ARM mode \r\n | \r\n32 | movw r7, :lower16:stg_enter_info\r\n | ^ \r\n \r\n/tmp/ghc154171_0/ghc_8.s:33:0: error: \r\n Error: selected processor does not support `movt r7,:upper16:stg_enter_info' in ARM mode\r\n | \r\n33 | movt r7, :upper16:stg_enter_info\r\n | ^ \r\n \r\n/tmp/ghc154171_0/ghc_8.s:231:0: error: \r\n Error: selected processor does not support `movw r2,#32512' in ARM mode \r\n | \r\n231 | movw r2, #32512 \r\n | ^ \r\n \r\n/tmp/ghc154171_0/ghc_8.s:233:0: error: \r\n Error: selected processor does not support `movt r2,#640' in ARM mode\r\n | \r\n233 | movt r2, #640 \r\n | ^ \r\n`gcc' failed in phase `Assembler'. (Exit code: 1) \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16149GHC for NetBSD2019-07-07T18:01:17Zgh1GHC for NetBSDI tried to build GHC for NetBSD from source but it faild and it took a long time. So, may I ask for:
a binaries for NetBSD
or
published manual how to build GHC from source for NetBSD ?
<details><summary>Trac metadata</summary>
| Trac f...I tried to build GHC for NetBSD from source but it faild and it took a long time. So, may I ask for:
a binaries for NetBSD
or
published manual how to build GHC from source for NetBSD ?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| 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":"GHC for NetBSD","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I tried to build GHC for NetBSD from source but it faild and it took a long time. So, may I ask for:\r\na binaries for NetBSD\r\nor\r\npublished manual how to build GHC from source for NetBSD ?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16148Better type inference for Constraint vs Type2023-03-31T13:27:23ZSimon Peyton JonesBetter type inference for Constraint vs TypeAn enduring infelicity in GHC’s type inference is the treatment of tuples. Consider, this from `RaeJobTalk`:
```
type family F c sch where
F _ '[] = (() :: Constraint)
F c (col ': cols) = (c Int, F c cols)
```
When kind-checking `F...An enduring infelicity in GHC’s type inference is the treatment of tuples. Consider, this from `RaeJobTalk`:
```
type family F c sch where
F _ '[] = (() :: Constraint)
F c (col ': cols) = (c Int, F c cols)
```
When kind-checking `F`, we initially give it a return kind of kappa, a unification variable. Suppose we kind-check the second equation first. Then what kind of tuple is it, a constraint tuple, or an ordinary type tuple. We must unify kappa with `Type` or `Constraint` respectively – and they are different kinds. How can we choose which?
Currently we have the following unsatisfactory ruse:
1. Look at the “expected kind”. If we kind-check the second equation first we learn nothing from that
1. Infer kinds for all of the elements of the type. Again in this case we learn nothing.
1. If we still know nothing, arbitrarily pick Type
This is horrible. If we kind check the first equation first, step 1 will discover Constraint, and kind checking succeeds. But if we put the equations in the other order, kind checking fails. Ugh!
Another example with exactly the same cause is #16139.
What to do? I can only think of three approaches:
A. Add a pseudo constraint `(TC kappa)` meaning “kappa must eventually turn out to be either `Type` or `Constraint`”. When generalising, default to `Type`.
B. Same, but by having a special sort of TauTv, a TCTv, which can only unify with Type or Constraint. Again, do not generalise over such type variables.
C. Define
```
type Type = TYPE (LiftedRep T)
type Constraint = TYPE (LiftedRep C)
```
> So now we can unify `kappa` with `(TYPE (LiftedRep zeta))` where `zeta` is a unification variable that we must eventually unify with `T` or `C`.
Of these, (C) seems most principled, but somehow over-elaborate for our purposes. And the others also seem to be rather too much work to solve a simple, local problem.
-------------
For reference, here are the current kinding rules
```
t1 : TYPE rep1
t2 : TYPE rep2
(FUN) ----------------
t1 -> t2 : Type
t1 : Constraint
t2 : TYPE rep
(PRED1) ----------------
t1 => t2 : Type
t1 : Constraint
t2 : Constraint
(PRED2) ---------------------
t1 => t2 : Constraint
ty : TYPE rep
`a` is not free in rep
(FORALL1) -----------------------
forall a. ty : TYPE rep
ty : Constraint
(FORALL2) -------------------------
forall a. ty : Constraint
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| 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":"Better type inference for Constraint vs Type","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"An enduring infelicity in GHC’s type inference is the treatment of tuples. Consider, this from `RaeJobTalk`:\r\n{{{\r\ntype family F c sch where\r\n F _ '[] = (() :: Constraint)\r\n F c (col ': cols) = (c Int, F c cols)\r\n}}}\r\nWhen kind-checking `F`, we initially give it a return kind of kappa, a unification variable. Suppose we kind-check the second equation first. Then what kind of tuple is it, a constraint tuple, or an ordinary type tuple. We must unify kappa with `Type` or `Constraint` respectively – and they are different kinds. How can we choose which?\r\nCurrently we have the following unsatisfactory ruse:\r\n\r\n1. Look at the “expected kind”. If we kind-check the second equation first we learn nothing from that\r\n2. Infer kinds for all of the elements of the type. Again in this case we learn nothing.\r\n3. If we still know nothing, arbitrarily pick Type\r\n\r\nThis is horrible. If we kind check the first equation first, step 1 will discover Constraint, and kind checking succeeds. But if we put the equations in the other order, kind checking fails. Ugh!\r\n\r\nAnother example with exactly the same cause is #16139.\r\n\r\nWhat to do? I can only think of three approaches:\r\n\r\nA. Add a pseudo constraint `(TC kappa)` meaning “kappa must eventually turn out to be either `Type` or `Constraint`”. When generalising, default to `Type`.\r\n\r\nB. Same, but by having a special sort of TauTv, a TCTv, which can only unify with Type or Constraint. Again, do not generalise over such type variables.\r\n\r\nC. Define\r\n{{{\r\ntype Type = TYPE (LiftedRep T)\r\ntype Constraint = TYPE (LiftedRep C)\r\n}}}\r\n So now we can unify `kappa` with `(TYPE (LiftedRep zeta))` where `zeta` is a unification variable that we must eventually unify with `T` or `C`.\r\n\r\nOf these, (C) seems most principled, but somehow over-elaborate for our purposes. And the others also seem to be rather too much work to solve a simple, local problem.\r\n\r\n-------------\r\nFor reference, here are the current kinding rules\r\n{{{\r\n t1 : TYPE rep1\r\n t2 : TYPE rep2\r\n (FUN) ----------------\r\n t1 -> t2 : Type\r\n\r\n t1 : Constraint\r\n t2 : TYPE rep\r\n (PRED1) ----------------\r\n t1 => t2 : Type\r\n\r\n t1 : Constraint\r\n t2 : Constraint\r\n (PRED2) ---------------------\r\n t1 => t2 : Constraint\r\n\r\n ty : TYPE rep\r\n `a` is not free in rep\r\n(FORALL1) -----------------------\r\n forall a. ty : TYPE rep\r\n\r\n ty : Constraint\r\n(FORALL2) -------------------------\r\n forall a. ty : Constraint\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->