GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-10-24T17:04:31Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4267Strictness analyser is to conservative about passing a boxed parameter2021-10-24T17:04:31ZtibbeStrictness analyser is to conservative about passing a boxed parameterGiven the following two modules:
`Fold.hs`:
```
module Fold (Tree, fold') where
data Tree a = Leaf | Node a !(Tree a) !(Tree a)
-- Strict, pre-order fold.
fold' :: (a -> b -> a) -> a -> Tree b -> a
fold' f = go
where
go z Leaf ...Given the following two modules:
`Fold.hs`:
```
module Fold (Tree, fold') where
data Tree a = Leaf | Node a !(Tree a) !(Tree a)
-- Strict, pre-order fold.
fold' :: (a -> b -> a) -> a -> Tree b -> a
fold' f = go
where
go z Leaf = z
go z (Node a l r) = let z' = go z l
z'' = f z' a
in z' `seq` z'' `seq` go z'' r
{-# INLINE fold' #-}
```
`FoldTest.hs`:
```
module FoldTest (sumTree) where
import Fold
sumTree :: Tree Int -> Int
sumTree = fold' (+) 0
```
I'd expect that the accumulator `z` used in `go` to be an unboxed
`Int#`. However, it's boxed:
```
sumTree1 :: Int
sumTree1 = I# 0
sumTree_go :: Int -> Fold.Tree Int -> Int
sumTree_go =
\ (z :: Int) (ds_ddX :: Fold.Tree Int) ->
case ds_ddX of _ {
Fold.Leaf -> z;
Fold.Node a l r ->
case sumTree_go z l of _ { I# z' ->
case a of _ { I# a# ->
sumTree_go (I# (+# z' a#)) r
}
}
}
sumTree :: Fold.Tree Int -> Int
sumTree =
\ (eta1_B1 :: Fold.Tree Int) ->
sumTree_go sumTree1 eta1_B1
```
Given this definition of `fold'`
```
fold' :: (a -> b -> a) -> a -> Tree b -> a
fold' f = go
where
go z _ | z `seq` False = undefined
go z Leaf = z
go z (Node a l r) = go (f (go z l) a) r
{-# INLINE fold' #-}
```
I get the core I want. However, this version isn't explicit in that
the left branch (i.e. `go z l`) should be evaluated before `f` is
called on the result. In other words, I think my first definition is
the one that correctly expresses the evaluation order, yet it results
in worse core.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Missing unboxing in pre-order fold over binary tree","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Given the following two modules:\r\n\r\n`Fold.hs`:\r\n\r\n{{{\r\nmodule Fold (Tree, fold') where\r\n\r\ndata Tree a = Leaf | Node a !(Tree a) !(Tree a)\r\n\r\n-- Strict, pre-order fold.\r\nfold' :: (a -> b -> a) -> a -> Tree b -> a\r\nfold' f = go\r\n where\r\n go z Leaf = z\r\n go z (Node a l r) = let z' = go z l\r\n z'' = f z' a\r\n in z' `seq` z'' `seq` go z'' r\r\n{-# INLINE fold' #-}\r\n}}}\r\n\r\n`FoldTest.hs`:\r\n\r\n{{{\r\nmodule FoldTest (sumTree) where\r\n\r\nimport Fold\r\n\r\nsumTree :: Tree Int -> Int\r\nsumTree = fold' (+) 0\r\n}}}\r\n\r\nI'd expect that the accumulator `z` used in `go` to be an unboxed\r\n`Int#`. However, it's boxed:\r\n\r\n{{{\r\nsumTree1 :: Int\r\nsumTree1 = I# 0\r\n\r\nsumTree_go :: Int -> Fold.Tree Int -> Int\r\nsumTree_go =\r\n \\ (z :: Int) (ds_ddX :: Fold.Tree Int) ->\r\n case ds_ddX of _ {\r\n Fold.Leaf -> z;\r\n Fold.Node a l r ->\r\n case sumTree_go z l of _ { I# z' ->\r\n case a of _ { I# a# ->\r\n sumTree_go (I# (+# z' a#)) r\r\n }\r\n }\r\n }\r\n\r\nsumTree :: Fold.Tree Int -> Int\r\nsumTree =\r\n \\ (eta1_B1 :: Fold.Tree Int) ->\r\n sumTree_go sumTree1 eta1_B1\r\n}}}\r\n\r\nGiven this definition of `fold'`\r\n\r\n{{{\r\nfold' :: (a -> b -> a) -> a -> Tree b -> a\r\nfold' f = go\r\n where\r\n go z _ | z `seq` False = undefined\r\n go z Leaf = z\r\n go z (Node a l r) = go (f (go z l) a) r\r\n{-# INLINE fold' #-}\r\n}}}\r\n\r\nI get the core I want. However, this version isn't explicit in that\r\nthe left branch (i.e. `go z l`) should be evaluated before `f` is\r\ncalled on the result. In other words, I think my first definition is\r\nthe one that correctly expresses the evaluation order, yet it results\r\nin worse core.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/4254Fundeps and equalities2019-07-07T18:59:49ZSimon Peyton JonesFundeps and equalitiesClaus asks what behavior these functions should have:
```
class FD a b | a -> b where
op :: a -> b;
op = undefined
instance FD Int Bool
ok1 :: forall a b. (a~Int,FD a b) => a -> b
ok1 = op
ok2 :: forall a b. (a~Int,FD a...Claus asks what behavior these functions should have:
```
class FD a b | a -> b where
op :: a -> b;
op = undefined
instance FD Int Bool
ok1 :: forall a b. (a~Int,FD a b) => a -> b
ok1 = op
ok2 :: forall a b. (a~Int,FD a b,b~Bool) => a -> Bool
ok2 = op
fails :: forall a b. (a~Int,FD a b) => a -> Bool
fails = op
```
In 6.12, `ok1` and `ok2` typecheck, but `fails` doesn't. I think
- `ok1` should fail because it requires the skolem `b` to be `Bool`, but has no way to prove it.
- `ok1` should succeed, because the caller passes in evidence that `b~Bool`
- `fails` should fail for the same reason as `ok1`
This isn't very high priority, but this ticket is just to make us check in due course that the new type checker does the right thing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | dimitris@microsoft.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fundeps and equalities","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["dimitris@microsoft.com"],"type":"Bug","description":"Claus asks what behavior these functions should have:\r\n{{{\r\nclass FD a b | a -> b where \r\n op :: a -> b; \r\n op = undefined \r\n\r\ninstance FD Int Bool\r\n\r\nok1 :: forall a b. (a~Int,FD a b) => a -> b\r\nok1 = op\r\n\r\nok2 :: forall a b. (a~Int,FD a b,b~Bool) => a -> Bool\r\nok2 = op\r\n\r\nfails :: forall a b. (a~Int,FD a b) => a -> Bool \r\nfails = op\r\n}}}\r\nIn 6.12, `ok1` and `ok2` typecheck, but `fails` doesn't. I think\r\n * `ok1` should fail because it requires the skolem `b` to be `Bool`, but has no way to prove it.\r\n * `ok1` should succeed, because the caller passes in evidence that `b~Bool`\r\n * `fails` should fail for the same reason as `ok1`\r\n\r\nThis isn't very high priority, but this ticket is just to make us check in due course that the new type checker does the right thing.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4230Template Haskell: less type checking in quotations?2019-07-07T18:59:57ZSimon Peyton JonesTemplate Haskell: less type checking in quotations?This ticket introduces two related Template Haskell design questions. It's inspired by several other tickets, for which these issues are the underlying cause
- #4135
- #4128
- #4170
- #4125
- #4124
-----------------------
= ISSUE 1 =
...This ticket introduces two related Template Haskell design questions. It's inspired by several other tickets, for which these issues are the underlying cause
- #4135
- #4128
- #4170
- #4125
- #4124
-----------------------
= ISSUE 1 =
Consider this module
```
module M where
import ...
f x = x
$(th1 4)
h y = k y y
$(th2 10)
```
In our present setup we typecheck down to the first splice, run the splice, then typecheck to the second splice, run that, and so on.
But GHC's main structure is:
- parse
- rename (resolve lexical scopes)
- typecheck
The above setup makes this impossible. We can't even rename the definition of h until we've run the splice $(th1 4) because that might be what brings k into scope. All this is a bit hard to explain to users.
Now suppose that instead we did the following.
- Typecheck and run **top-level** splices in the renamer
That is, when the renamer finds a top-level splice:
- rename it
- typecheck it
- run it
- replace the splice by the result of running it
- and then rename \*that\* as if that's what the user had written in the first place
But what about nested quotes? eg
```
$(th1 [| f x |])
```
Well we can't typecheck that quote, because we don't have a type for f and x, because we are in the renamer. But we don't **need** to typecheck the quote to be able to typecheck and run the splice! Remember, we already have a staging restriction that only imported functions can be **run** in a top-level splice.
So the proposal would mean that we don't attempt to typecheck those nested quotes. Instead they'll be checked after the top-level splice is run, the result spliced in, and the whole shebang typechecked in the context of the program as a whole.
This defers the error message, but not too muce, since typechecking the output of the splice is what will happen next.
This approach would have a number of rather compelling advantages:
- It would allow us to show the program after renaming and splice
expansion, but before typechecking. That's quite helpful. It
makes it easier to say that we
- rename the program, and then
- typecheck the program
Remember, GHC is also a Haskell library, and the current
> story (a bit of renaming, a bit of typechecking, then a bit more
> renaming and a bit more typechecking) complicates the API.
- Geoff Mainland's quasi-quotation mechanism is run in the
renamer (because it can expand to patterns) so it would make
all the TH stuff more consistent.
- Even more exciting, we could support pattern splices, thus
```
f $(g 4) = x+y
```
because the splice $(g 4) would be typechecked and run, perhaps
expanding to (x,y), say, by the renamer \*before\* it goes on to
do scope-analysis on x+y. This is exactly why quasiquoting
- can\* do pattern splicing at the moment, and TH cannot.
\[\[BR\]\]\[\[BR\]\]
> This would fix a long-standing infelicity in TH, namely the
> absence of pattern splices.
- In the same way we could support local declaration
splices (which are currently ruled out)
```
f x = let $(g [| x |]) in ....
```
- At the top level we could get rid of the top-to-bottom bias.
We could allow, say
```
f x = x+x
$(th [| g |] [| f |])
g y = y+1
```
One disadvantage is that it'd "bake in" the staging restriction that a splice can only (typecheck and) run functions imported from another module. Currently this is only an implementation restriction, which in principle might be lifted. On the other hand, I have no plans to lift it, and in practice people don't complain about it.
------------------
= ISSUE 2 =
Consider this:
```
f :: Q Type -> Q [Dec]
f t = [d| data T = MkT $t;
g (MkT x) = g+1 |]
```
This function f returns a declaration splice, declaring T and g.
You'll see that the constructor MkT takes an argument whose type is passed (as a quotation) to f -- a type splice.
The difficulty is that we can't typecheck the declaration of 'g'
until we know what $t is; and we won't know that until f is called.
So
- we can't really typecheck the declaration quote at all
In the case of **term** splices in a quotation we can simply give them type (forall a. a), which never gets in the way. But there is no equivalent for \*type\* splices. An analogous problem occurs in other declaration splices, for example
```
f t = [d| instance C $t where ... |]
```
Here GHC's check that an instance decl is always of form
```
instance C (T a b c)
```
falls over, again because we don't know what $t will be.
It's hard to see what to do about this.
- We could get rid of type splices (but people like them)
- We could refrain from typechecking quotations \*at all\*
I have users asking me for exactly this: #4125, #4135
- We could refrain from typechecking \*declaration\* quotes.
But the problem still happens for terms
```
[| let { f :: $t; f = e } in .. |]
```
- We could refrain from typechecking any quotation that
included a type splice. This is probably the most benign:
it switches off the type checker just when it's problematic,
and it's very predictable when that is. Awkward to implement
though.
Do you have any other ideas?
----------------------
= DISCUSSION =
The two issues are related of course, because both involve doing
less typechecking of quotations.
That seems a pity, because it'd lose one of TH's advantages --
that of typechecking meta programs rather than just typechecking
the output of the meta programs. And in the case of ISSUE 2,
error messages might get delayed, perhpas to another module
altogether.
However, we deliberately designed TH so that it *is* possible to
get a type error when typechecking the result of a type-correct
top-level splice. Reason: we use type Exp rather than (Exp t) as
in MetaML. That gave us (a lot) more flexibility. Apart from
anything else, declaration splices would be problematic in the
MetaML approach.
Seen in that light, the proposals here just move a bit further in
the direction of flexibility, at the cost of somewhat-increased
danger of errors being reported later than is ideal. 7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4218System.Random is way too lazy2019-07-07T19:00:04ZEyalLotemSystem.Random is way too lazyrandomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.
Test program is attached.
Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO \>\>= evaluate) is fine, however.
F...randomRs is too lazy, generates lists of large lazy-state thunks, rather than lists of strict values.
Test program is attached.
Also, randomIO is too lazy, and builds up huge thunks. Using (randomIO \>\>= evaluate) is fine, however.
Fails with stack overflow:
```
rs <- replicateM 1000000 evaluate :: IO [Int]
print $ last rs
```
Works:
```
rs <- replicateM 1000000 (evaluate =<< randomIO) :: IO [Int]
print $ last rs
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/4215canonicalizePath behaves strangely with paths that do not exist2019-07-07T19:00:04ZcreswickcanonicalizePath behaves strangely with paths that do not existThe behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior woul...The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.
This is complicated by differing behaviors of the underlying realpath(char\*, char\*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:
- $HOME/tmp/foo is a file.
- $HOME/tmp/bar is a directory.
- $HOME/tmp/baz does not exist.
Linux:
```
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/foo/subdir"
"/home/creswick/tmp/foo"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/bar/subdir"
"/home/creswick/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/baz/subdir"
"/home/creswick/tmp/baz"
```
OS-X:
```
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/foo/subdir"
"/Users/hudson/tmp/foo/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/bar/subdir"
"/Users/hudson/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/baz/subdir"
"/Users/hudson/tmp/baz"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"canonicalizePath behaves strangely with paths that do not exist","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.\r\n\r\nThis is complicated by differing behaviors of the underlying realpath(char*, char*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:\r\n\r\n * $HOME/tmp/foo is a file.\r\n * $HOME/tmp/bar is a directory.\r\n * $HOME/tmp/baz does not exist.\r\n\r\nLinux:\r\n{{{\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/foo/subdir\"\r\n\"/home/creswick/tmp/foo\"\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/bar/subdir\"\r\n\"/home/creswick/tmp/bar/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/baz/subdir\"\r\n\"/home/creswick/tmp/baz\"\r\n}}}\r\n\r\nOS-X:\r\n{{{\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/foo/subdir\" \r\n\"/Users/hudson/tmp/foo/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/bar/subdir\"\r\n\"/Users/hudson/tmp/bar/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/baz/subdir\"\r\n\"/Users/hudson/tmp/baz\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/4213LLVM: Add support for TNTC to LLVM compiler suite2019-07-07T19:00:05ZdtereiLLVM: Add support for TNTC to LLVM compiler suiteAt the moment we handle TNTC in the LLVM backend in two different ways:
Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments...At the moment we handle TNTC in the LLVM backend in two different ways:
Linux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)
Mac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.
Both these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 6.13 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM: Add support for TNTC to LLVM compiler suite","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dterei"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"At the moment we handle TNTC in the LLVM backend in two different ways:\r\n\r\nLinux/Windows: We use the GNU As subsections feature to order sections. Works very nicely. Slight hack in that we create special section names that contain comments. (Asm injection)\r\n\r\nMac: Mac assembler doesn't support the GNU As subsections feature, so we post-process the assembly code produced by llc.\r\n\r\nBoth these methods (especially Mac) are hacks. It would be better to extend LLVM to support the TNTC feature.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/4210LLVM: Dynamic Library Support2019-07-07T19:00:05ZdtereiLLVM: Dynamic Library Supportdynamic library status:
```
* Supported: Linux 64bit, Mac OSX 64bit
* Unsupported: Linux 32bit, Mac OSX 32bit, Windows 32bit
```
The LLVM backend doesn't support dynamic libraries at the moment.
LLC supports a flag called '-relocati...dynamic library status:
```
* Supported: Linux 64bit, Mac OSX 64bit
* Unsupported: Linux 32bit, Mac OSX 32bit, Windows 32bit
```
The LLVM backend doesn't support dynamic libraries at the moment.
LLC supports a flag called '-relocation-mode' that can be used to support this, it takes the following options:
```
default - let the target choose.
static - static code.
pic - PIC code.
dynamic-no-pic - Dynamic references but static code
```
This roughly corresponds to GHC -fPIC, and -dynamic flags.
Linux: Simply adding the correct flag to LLC seems to work fine.
Mac OSX, Windows: Adding the correct flag doesn't work at all, all programs segfault.7.6.2dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/4197clarify which names can not be quoted2019-07-07T19:00:09ZChristian Maederclarify which names can not be quotedhttp://www.haskell.org/ghc/docs/6.12.2/html/users_guide/template-haskell.html\#id665813
I suppose a primed identifier like x' or T' can not be quoted, because they would be scanned as character.
Maybe all identifiers containing primes ...http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/template-haskell.html\#id665813
I suppose a primed identifier like x' or T' can not be quoted, because they would be scanned as character.
Maybe all identifiers containing primes should be disallowed being quoted by one or two leading primes.
In any case, the documentation should match the implementation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.12.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"clarify which names can not be quoted","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/template-haskell.html#id665813\r\n\r\nI suppose a primed identifier like x' or T' can not be quoted, because they would be scanned as character.\r\n\r\nMaybe all identifiers containing primes should be disallowed being quoted by one or two leading primes.\r\n\r\nIn any case, the documentation should match the implementation.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/4196add more stolen syntax to the user guide2019-07-07T19:00:09ZChristian Maederadd more stolen syntax to the user guidelanguage extensions:
- Bang Patterns disallow an infix funlhs for "!"
- Magic Hash disallows sections like "(3\#)" and infix terms like "3\# 1" without a space before \# (for a user-defined operator "\#" or "\#\#")
<details><summary>T...language extensions:
- Bang Patterns disallow an infix funlhs for "!"
- Magic Hash disallows sections like "(3\#)" and infix terms like "3\# 1" without a space before \# (for a user-defined operator "\#" or "\#\#")
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.12.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"add more stolen syntax to the user guide","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"language extensions:\r\n\r\n- Bang Patterns disallow an infix funlhs for \"!\"\r\n\r\n- Magic Hash disallows sections like \"(3#)\" and infix terms like \"3# 1\" without a space before # (for a user-defined operator \"#\" or \"##\")","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4185Deriving higher-arity instances for newtype family instances fails2019-07-07T19:00:12ZLouisWassermanDeriving higher-arity instances for newtype family instances fails```
{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}
module Baz where
class Bar f where
bar :: f a -> Int
data family Foo k :: * -> *
instance Bar Maybe where
bar Nothing = 0
bar Just{} = 1
newtype instance Foo Int a = Fo...```
{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}
module Baz where
class Bar f where
bar :: f a -> Int
data family Foo k :: * -> *
instance Bar Maybe where
bar Nothing = 0
bar Just{} = 1
newtype instance Foo Int a = FooInt (Maybe a) deriving (Bar)
```
fails with
```
Baz.hs:13:56:
Derived instance `Bar (Foo Int)'
requires illegal partial application of data type family Foo
In the newtype instance declaration for `Foo'
```
Attempting to use StandaloneDeriving:
```
{-# LANGUAGE StandaloneDeriving, TypeFamilies, GeneralizedNewtypeDeriving #-}
module Baz where
class Bar f where
bar :: f a -> Int
data family Foo k :: * -> *
instance Bar Maybe where
bar Nothing = 0
bar Just{} = 1
newtype instance Foo Int a = FooInt (Maybe a)
deriving instance Bar (Foo Int)
```
gives the super-weird error
```
Baz.hs:15:0:
No family instance for `Foo Int'
In the stand-alone deriving instance for `Bar (Foo Int)'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Deriving higher-arity instances for newtype family instances fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\n{-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-}\r\nmodule Baz where\r\n\r\nclass Bar f where\r\n\tbar :: f a -> Int\r\n\r\ndata family Foo k :: * -> *\r\n\r\ninstance Bar Maybe where\r\n\tbar Nothing = 0\r\n\tbar Just{} = 1\r\n\r\nnewtype instance Foo Int a = FooInt (Maybe a) deriving (Bar)\r\n}}}\r\nfails with\r\n\r\n\r\n{{{\r\nBaz.hs:13:56:\r\n Derived instance `Bar (Foo Int)'\r\n requires illegal partial application of data type family Foo\r\n In the newtype instance declaration for `Foo'\r\n}}}\r\n\r\nAttempting to use StandaloneDeriving:\r\n\r\n{{{\r\n{-# LANGUAGE StandaloneDeriving, TypeFamilies, GeneralizedNewtypeDeriving #-}\r\nmodule Baz where\r\n\r\nclass Bar f where\r\n\tbar :: f a -> Int\r\n\r\ndata family Foo k :: * -> *\r\n\r\ninstance Bar Maybe where\r\n\tbar Nothing = 0\r\n\tbar Just{} = 1\r\n\r\nnewtype instance Foo Int a = FooInt (Maybe a)\r\n\r\nderiving instance Bar (Foo Int)\r\n}}}\r\n\r\ngives the super-weird error\r\n\r\n{{{\r\n\r\nBaz.hs:15:0:\r\n No family instance for `Foo Int'\r\n In the stand-alone deriving instance for `Bar (Foo Int)'\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/4177GHCi should allow custom definition of print for implicit output2019-07-07T19:00:14ZEdward Z. YangGHCi should allow custom definition of print for implicit outputRight now, a value of type a desugars to:
```
let it = expr
print it
```
Where print is actually an identifier referencing System.IO.print. This makes it a tad difficult for users to overload the behavior of print for their own nefario...Right now, a value of type a desugars to:
```
let it = expr
print it
```
Where print is actually an identifier referencing System.IO.print. This makes it a tad difficult for users to overload the behavior of print for their own nefarious (debugging) purposes.
I propose that we allow some way of overriding the print used for printing statements. I think there are few ways we could do this:
- We could look in the user bindings and check to see if there is print defined, and then use that instead. This would truly make this “just an extension to the Prelude”, but if there are conflicting definitions of print the user may not appreciate the breakage (though they'd be able to just let print = ... to resolve the ambiguity).
- We could look in the user bindings and check to see if there is some magic variable corresponding to print defined, and use that instead.
- We could add a command that adds a special binding for print and references that instead (default being System.IO.Print).
I have a vague idea how you might implement the first two by editing ./compiler/typecheck/TcRnDriver.lhs, although I don't know how one would make the local binding information available at that location. I have no idea how to implement the latter.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi should allow custom definition of print for implicit output","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Right now, a value of type a desugars to:\r\n\r\n{{{\r\nlet it = expr\r\nprint it\r\n}}}\r\n\r\nWhere print is actually an identifier referencing System.IO.print. This makes it a tad difficult for users to overload the behavior of print for their own nefarious (debugging) purposes.\r\n\r\nI propose that we allow some way of overriding the print used for printing statements. I think there are few ways we could do this:\r\n\r\n * We could look in the user bindings and check to see if there is print defined, and then use that instead. This would truly make this “just an extension to the Prelude”, but if there are conflicting definitions of print the user may not appreciate the breakage (though they'd be able to just let print = ... to resolve the ambiguity).\r\n\r\n * We could look in the user bindings and check to see if there is some magic variable corresponding to print defined, and use that instead.\r\n\r\n * We could add a command that adds a special binding for print and references that instead (default being System.IO.Print).\r\n\r\nI have a vague idea how you might implement the first two by editing ./compiler/typecheck/TcRnDriver.lhs, although I don't know how one would make the local binding information available at that location. I have no idea how to implement the latter.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4175GHCi support for type/data families should match that of related features2019-07-07T19:00:15Zclaus.reinke@talk21.comGHCi support for type/data families should match that of related featuresCurrently, GHCi queries are not as helpful with type and data families as they are with type synonyms or class instances. Consider this module:
```
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGU...Currently, GHCi queries are not as helpful with type and data families as they are with type synonyms or class instances. Consider this module:
```
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
type family TF a
type instance TF Bool = Char
type instance TF Int = Bool
data family DF a
data instance DF Bool = DFC Char
data instance DF Int = DFB Bool
class FD a b | a -> b
instance FD Bool Char
instance FD Int Bool
type TS a = (a,a)
```
and compare the output of `:info` for these items:
```
*Main> :i TS
type TS a = (a, a)
-- Defined at C:\Users\claus\Desktop\tmp\fd-tf\tf-df-info.hs:17:5-6
*Main> :i TF
type family TF a :: *
-- Defined at C:\Users\claus\Desktop\tmp\fd-tf\tf-df-info.hs:5:12-13
*Main> :i FD
class FD a b | a -> b
-- Defined at C:\Users\claus\Desktop\tmp\fd-tf\tf-df-info.hs:13:6-7
instance FD Bool Char
-- Defined at C:\Users\claus\Desktop\tmp\fd-tf\tf-df-info.hs:14:9-20
instance FD Int Bool
-- Defined at C:\Users\claus\Desktop\tmp\fd-tf\tf-df-info.hs:15:9-20
*Main> :i DF
data family DF a
-- Defined at C:\Users\claus\Desktop\tmp\fd-tf\tf-df-info.hs:9:12-13
```
Neither the type family definition nor the data family instances are listed. If we try `:browse` instead
```
*Main> :browse
type family TF a :: *
data family DF a
data instance Main.R:DFBool Bool = DFC Char
data instance Main.R:DFInt Int = DFB Bool
class FD a b | a -> b
type TS a = (a, a)
```
we get some form of info about the data family instances, though no instances are listed for the plain old class, and the data family instance info shows internal encoding details.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi support for type/data families should match that of related features","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["FD","TF"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently, GHCi queries are not as helpful with type and data families as they are with type synonyms or class instances. Consider this module:\r\n{{{\r\n{-# LANGUAGE FunctionalDependencies #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family TF a\r\ntype instance TF Bool = Char\r\ntype instance TF Int = Bool\r\n\r\ndata family DF a\r\ndata instance DF Bool = DFC Char\r\ndata instance DF Int = DFB Bool\r\n\r\nclass FD a b | a -> b\r\ninstance FD Bool Char\r\ninstance FD Int Bool\r\n\r\ntype TS a = (a,a)\r\n}}}\r\nand compare the output of `:info` for these items:\r\n{{{\r\n*Main> :i TS\r\ntype TS a = (a, a)\r\n -- Defined at C:\\Users\\claus\\Desktop\\tmp\\fd-tf\\tf-df-info.hs:17:5-6\r\n*Main> :i TF\r\ntype family TF a :: *\r\n -- Defined at C:\\Users\\claus\\Desktop\\tmp\\fd-tf\\tf-df-info.hs:5:12-13\r\n*Main> :i FD\r\nclass FD a b | a -> b\r\n -- Defined at C:\\Users\\claus\\Desktop\\tmp\\fd-tf\\tf-df-info.hs:13:6-7\r\ninstance FD Bool Char\r\n -- Defined at C:\\Users\\claus\\Desktop\\tmp\\fd-tf\\tf-df-info.hs:14:9-20\r\ninstance FD Int Bool\r\n -- Defined at C:\\Users\\claus\\Desktop\\tmp\\fd-tf\\tf-df-info.hs:15:9-20\r\n*Main> :i DF\r\ndata family DF a\r\n -- Defined at C:\\Users\\claus\\Desktop\\tmp\\fd-tf\\tf-df-info.hs:9:12-13\r\n}}}\r\nNeither the type family definition nor the data family instances are listed. If we try `:browse` instead\r\n{{{\r\n*Main> :browse\r\ntype family TF a :: *\r\ndata family DF a\r\ndata instance Main.R:DFBool Bool = DFC Char\r\ndata instance Main.R:DFInt Int = DFB Bool\r\nclass FD a b | a -> b\r\ntype TS a = (a, a)\r\n}}}\r\nwe get some form of info about the data family instances, though no instances are listed for the plain old class, and the data family instance info shows internal encoding details.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4170Invalid "duplicate instance" error2019-07-07T19:00:16ZverdelyiInvalid "duplicate instance" errorTest case:
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
class LOL a
lol :: Q [Dec]
lol = [d|
instance LOL Int
|]
instance LOL Int
```
Error:
```
duplicateinstance.hs:9:13:
Duplicate instance declarat...Test case:
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
class LOL a
lol :: Q [Dec]
lol = [d|
instance LOL Int
|]
instance LOL Int
```
Error:
```
duplicateinstance.hs:9:13:
Duplicate instance declarations:
instance LOL Int -- Defined at duplicateinstance.hs:9:13-19
instance LOL Int -- Defined at duplicateinstance.hs:12:9-15
In the Template Haskell quotation
[d|
instance LOL Int where |]
In the expression:
[d|
instance LOL Int where |]
In the definition of `lol':
lol = [d|
instance LOL Int where |]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Invalid \"duplicate instance\" error","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test case:\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nimport Language.Haskell.TH\r\n\r\nclass LOL a\r\n\r\nlol :: Q [Dec]\r\nlol = [d|\r\n instance LOL Int\r\n |]\r\n\r\ninstance LOL Int\r\n}}}\r\nError:\r\n\r\n{{{\r\nduplicateinstance.hs:9:13:\r\n Duplicate instance declarations:\r\n instance LOL Int -- Defined at duplicateinstance.hs:9:13-19\r\n instance LOL Int -- Defined at duplicateinstance.hs:12:9-15\r\n In the Template Haskell quotation\r\n [d| \r\n instance LOL Int where |]\r\n In the expression:\r\n [d| \r\n instance LOL Int where |]\r\n In the definition of `lol':\r\n lol = [d| \r\n instance LOL Int where |]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4148improve new recursive do syntax2019-07-07T19:00:23Zguestimprove new recursive do syntaxThis is a request for an adjustment of the syntax for the new
recursive do notation. "rec { ... }" should parse/type check as an expression
such that:
```
mdo
a <- getChar
b <- f c
c <- g b
putChar c
retu...This is a request for an adjustment of the syntax for the new
recursive do notation. "rec { ... }" should parse/type check as an expression
such that:
```
mdo
a <- getChar
b <- f c
c <- g b
putChar c
return b
```
can be written as
```
do rec
a <- getChar
b <- f c
c <- g b
putChar c
return b
```
at moment the closest you can get is ...
```
t5 =
do rec
a <- getChar
b <- f c
c <- g b
putChar c
return b
```
it seems rec { ... } is a binding construct not an expression and therefore
can not be used in the final position (or sole component) of a do block
benefits
- drop in replacement for mdo, that is the construct "do rec"
> becomes semantically and syntactically equivalent to the mdo
> notation
- current layout is maintained (which is much neater)
- I would argue that it is more intuitive
dificulty
- it seems to be a minor change?.
related
- this change seems to have been introduced as
> [http://hackage.haskell.org/trac/ghc/ticket/2798](http://hackage.haskell.org/trac/ghc/ticket/2798)
> somewhat surreptitiously (well, cought me by surprise, anyway.).
## background
1. 12.1 introduced a change to the recursive do syntax
[http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html](http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html)
Instead of writing
```
mdo
a <- getChar
b <- f c
c <- g b
putChar c
return b
```
you would write
```
do
a <- getChar
rec { b <- f c
; c <- g b }
putChar c
return b
```
A couple of issues about the change:
- the new syntax spoils layout (see above)
- migrating to the new syntax with the current limitation is
> non-trivial, requires analysis of code (in some cases).
for the record ...
```
> t2 =
> do rec
> a <- getChar
> b <- f c
> c <- g b
> putChar c
> return b
> f = return . (const 'a')
> g = return
eg.lhs:23:6:
The last statement in a 'do' construct must be an expression
Failed, modules loaded: none.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 6.12.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | jvlask@hotmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"improve new recursive do syntax","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["jvlask@hotmail.com"],"type":"FeatureRequest","description":"This is a request for an adjustment of the syntax for the new\r\nrecursive do notation. \"rec { ... }\" should parse/type check as an expression\r\nsuch that:\r\n\r\n{{{\r\n mdo\r\n a <- getChar\r\n b <- f c\r\n c <- g b\r\n putChar c\r\n return b\r\n}}}\r\n\r\ncan be written as\r\n\r\n{{{\r\n do rec\r\n a <- getChar\r\n b <- f c\r\n c <- g b\r\n putChar c\r\n return b\r\n}}}\r\n\r\nat moment the closest you can get is ...\r\n\r\n{{{\r\nt5 =\r\n do rec \r\n a <- getChar\r\n b <- f c\r\n c <- g b\r\n putChar c\r\n return b \r\n}}}\r\n\r\nit seems rec { ... } is a binding construct not an expression and therefore\r\ncan not be used in the final position (or sole component) of a do block\r\n\r\nbenefits\r\n - drop in replacement for mdo, that is the construct \"do rec\"\r\n becomes semantically and syntactically equivalent to the mdo\r\n notation\r\n - current layout is maintained (which is much neater)\r\n - I would argue that it is more intuitive\r\n\r\n\r\ndificulty\r\n - it seems to be a minor change?.\r\n\r\nrelated\r\n - this change seems to have been introduced as\r\n [http://hackage.haskell.org/trac/ghc/ticket/2798]\r\n somewhat surreptitiously (well, cought me by surprise, anyway.).\r\n\r\n== background ==\r\n\r\n6.12.1 introduced a change to the recursive do syntax\r\n[http://old.nabble.com/Update-on-GHC-6.12.1-td26103595.html]\r\n\r\nInstead of writing\r\n\r\n{{{\r\n mdo\r\n a <- getChar\r\n b <- f c\r\n c <- g b\r\n putChar c\r\n return b\r\n}}}\r\n\r\nyou would write\r\n\r\n{{{\r\n do\r\n a <- getChar\r\n rec { b <- f c\r\n ; c <- g b }\r\n putChar c\r\n return b\r\n}}}\r\n\r\nA couple of issues about the change:\r\n\r\n\r\n\r\n - the new syntax spoils layout (see above)\r\n - migrating to the new syntax with the current limitation is\r\n non-trivial, requires analysis of code (in some cases).\r\n\r\nfor the record ...\r\n\r\n{{{\r\n> t2 =\r\n> do rec\r\n> a <- getChar\r\n> b <- f c\r\n> c <- g b\r\n> putChar c\r\n> return b\r\n\r\n> f = return . (const 'a')\r\n> g = return\r\n\r\neg.lhs:23:6:\r\n The last statement in a 'do' construct must be an expression\r\nFailed, modules loaded: none.\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/4140dynHelloWorld(dyn) fails in an unreg build2020-06-06T07:23:28ZIan Lynagh <igloo@earth.li>dynHelloWorld(dyn) fails in an unreg buildIn an unregisterised build, `dynHelloWorld(dyn)` is failing: there is nothing on stdout when output is redirected to a file.
It looks like `GHC.TopHandler.cleanUp` is flushing the wrong `stdout`.
<details><summary>Trac metadata</summar...In an unregisterised build, `dynHelloWorld(dyn)` is failing: there is nothing on stdout when output is redirected to a file.
It looks like `GHC.TopHandler.cleanUp` is flushing the wrong `stdout`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"dynHelloWorld(dyn) fails in an unreg build","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In an unregisterised build, `dynHelloWorld(dyn)` is failing: there is nothing on stdout when output is redirected to a file.\r\n\r\nIt looks like `GHC.TopHandler.cleanUp` is flushing the wrong `stdout`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4135Can't Quote Instance Associated Types in Template Haskell2019-07-07T19:00:26ZAshley YakeleyCan't Quote Instance Associated Types in Template HaskellGive this a whirl:
```
{-# LANGUAGE TypeFamilies,TemplateHaskell #-}
module Bug where
class C a where
type T a
$([d|
instance C (Maybe a) where
type T (Maybe a) = Char
|])
```
```
$ ghc -...Give this a whirl:
```
{-# LANGUAGE TypeFamilies,TemplateHaskell #-}
module Bug where
class C a where
type T a
$([d|
instance C (Maybe a) where
type T (Maybe a) = Char
|])
```
```
$ ghc -c Bug.hs
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.0 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
Bug.hs:7:6:
Type indexes must match class instance head
Found `Maybe a[aMy]' but expected `Maybe a[aMx]'
In the associated type instance for `T'
In the instance declaration for `C (Maybe a[aMx])'
[glastonbury:~/Projects/Haskell/Truth/Core]$
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.1 |
| 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":"Can't Quote Instance Associated Types in Template Haskell","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Give this a whirl:\r\n{{{\r\n{-# LANGUAGE TypeFamilies,TemplateHaskell #-}\r\nmodule Bug where\r\n\r\n class C a where\r\n type T a\r\n\r\n $([d| \r\n instance C (Maybe a) where\r\n type T (Maybe a) = Char\r\n |])\r\n}}}\r\n\r\n{{{\r\n$ ghc -c Bug.hs \r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nLoading package array-0.3.0.0 ... linking ... done.\r\nLoading package containers-0.3.0.0 ... linking ... done.\r\nLoading package pretty-1.0.1.1 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\n\r\nBug.hs:7:6:\r\n Type indexes must match class instance head\r\n Found `Maybe a[aMy]' but expected `Maybe a[aMx]'\r\n In the associated type instance for `T'\r\n In the instance declaration for `C (Maybe a[aMx])'\r\n[glastonbury:~/Projects/Haskell/Truth/Core]$ \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4128Can't capture classes inside a template haskell type quotation2019-07-07T19:00:27ZlilacCan't capture classes inside a template haskell type quotationGHC rejects the following:
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
class C a where
data X = X
fmap return $ instanceD (cxt []) [t| C $(conT ''X) |] []
```
with the error:
```
test.hs:5:23:
Class `C' used as...GHC rejects the following:
```
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
class C a where
data X = X
fmap return $ instanceD (cxt []) [t| C $(conT ''X) |] []
```
with the error:
```
test.hs:5:23:
Class `C' used as a type
In the Template Haskell quotation [t| C $(conT 'X) |]
In the second argument of `instanceD', namely `[t| C $(conT 'X) |]'
In the expression: instanceD (cxt []) [t| C $(conT 'X) |] []
```
This is frustrating, since that quotation would have resulted in exactly the TH AST fragment I wanted, had the error not occurred. Instead I must resort to:
```
instanceD (cxt []) (appT (conT ''Storable) (conT ''X)) []
```
Incidentally, the error message produced is wrong: The error says 'X whereas I wrote ''X.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.1 |
| 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":"Can't capture classes inside a template haskell type quotation","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC rejects the following:\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nimport Language.Haskell.TH\r\nclass C a where\r\ndata X = X\r\nfmap return $ instanceD (cxt []) [t| C $(conT ''X) |] []\r\n}}}\r\n\r\nwith the error:\r\n\r\n{{{\r\ntest.hs:5:23:\r\n Class `C' used as a type\r\n In the Template Haskell quotation [t| C $(conT 'X) |]\r\n In the second argument of `instanceD', namely `[t| C $(conT 'X) |]'\r\n In the expression: instanceD (cxt []) [t| C $(conT 'X) |] []\r\n}}}\r\n\r\nThis is frustrating, since that quotation would have resulted in exactly the TH AST fragment I wanted, had the error not occurred. Instead I must resort to:\r\n\r\n{{{\r\ninstanceD (cxt []) (appT (conT ''Storable) (conT ''X)) []\r\n}}}\r\n\r\nIncidentally, the error message produced is wrong: The error says 'X whereas I wrote ''X.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4124GHC rejects instance quotations with splices in the instance head2019-07-07T19:00:28ZlilacGHC rejects instance quotations with splices in the instance headI think the following code should be accepted.
```
{-# LANGUAGE TemplateHaskell #-}
class Storable a where
data X = X
[d| instance Storable $( [t| X |] ) where |]
```
GHC disagrees, saying:
```
test.hs:4:4:
Illegal instance declar...I think the following code should be accepted.
```
{-# LANGUAGE TemplateHaskell #-}
class Storable a where
data X = X
[d| instance Storable $( [t| X |] ) where |]
```
GHC disagrees, saying:
```
test.hs:4:4:
Illegal instance declaration for `Storable t_aKj'
(All instance types must be of the form (T a1 ... an)
where a1 ... an are type *variables*,
and each type variable appears at most once in the instance head.
Use -XFlexibleInstances if you want to disable this.)
In the instance declaration for `Storable $[t| X |]'
In the Template Haskell quotation
[d|
instance Storable $[t| X |] where |]
In the expression:
[d|
instance Storable $[t| X |] where |]
```
This checking seems inappropriate before the type is actually spliced in!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.12.1 |
| 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":"GHC rejects instance quotations with splices in the instance head","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think the following code should be accepted.\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nclass Storable a where\r\ndata X = X\r\n[d| instance Storable $( [t| X |] ) where |]\r\n}}}\r\n\r\nGHC disagrees, saying:\r\n\r\n{{{\r\ntest.hs:4:4:\r\n Illegal instance declaration for `Storable t_aKj'\r\n (All instance types must be of the form (T a1 ... an)\r\n where a1 ... an are type *variables*,\r\n and each type variable appears at most once in the instance head.\r\n Use -XFlexibleInstances if you want to disable this.)\r\n In the instance declaration for `Storable $[t| X |]'\r\n In the Template Haskell quotation\r\n [d| \r\n instance Storable $[t| X |] where |]\r\n In the expression:\r\n [d| \r\n instance Storable $[t| X |] where |]\r\n}}}\r\n\r\nThis checking seems inappropriate before the type is actually spliced in!","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/4121Refactor the plumbing of CafInfo to make it more robust2019-07-07T19:00:29ZdtereiRefactor the plumbing of CafInfo to make it more robustWhile comping GHC Head using the devel1 flavour and ghc-6.12.2 as the bootstrap compiler, I get the following assertion failure:
```
"inplace/bin/ghc-stage1" -H64m -O -fasm -package-name base-4.3.0.0 -hide-all-packages -i -ilibrari...While comping GHC Head using the devel1 flavour and ghc-6.12.2 as the bootstrap compiler, I get the following assertion failure:
```
"inplace/bin/ghc-stage1" -H64m -O -fasm -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.0 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O -dcore-lint -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./Control/Applicative.hs -o libraries/base/dist-install/build/Control/Applicative.o
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/simplCore/CSE.lhs line 349 a_aup
WARNING: file compiler/stgSyn/CoreToStg.lhs line 220
Control.Applicative.$fAlternativeSTM
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 6.13 for i386-unknown-linux):
ASSERT failed! file compiler/stgSyn/CoreToStg.lhs line 187
...blah...
base:Control.Applicative.$fAlternativeSTM{v rk} [gid[DFunId]] =
[] \u srt:SRT:[] []
let {
sat_s1oj{v} [lid] =
[] \r srt:SRT:[] [eta_B1{v} [lid]] retry#{v} [eta_B1{v} [lid]];
} in
base:Control.Applicative.D:Alternative{d rra} [base:Control.Applicative.$fApplicativeSTM{v r2q} [gid[DFunId]]
sat_s1oj{v} [lid]
base:GHC.Conc.orElse1{v re9} [gid]
base:Control.Applicative.$fAlternativeSTM3{v r2n} [gid]
base:Control.Applicative.$fAlternativeSTM1{v r2l} [gid]];
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This is on the 32bit MSRC machine by the way. On my own laptop running Ubuntu 10.04 I don't get this (bootstrap compiler is 6.12.1 though).8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4069ASSERTION FAILED: file rts/Schedule.c, line 13052019-07-07T19:00:49ZjutaroASSERTION FAILED: file rts/Schedule.c, line 1305From time to time Leksah crashes with the above message.
GHC version 6.12.1 for x86_64_unknown_linux.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Ver...From time to time Leksah crashes with the above message.
GHC version 6.12.1 for x86_64_unknown_linux.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"ASSERTION FAILED: file rts/Schedule.c, line 1305","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"From time to time Leksah crashes with the above message.\r\nGHC version 6.12.1 for x86_64_unknown_linux.\r\n \r\n","type_of_failure":"OtherFailure","blocking":[]} -->