GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-11-21T19:11:37Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/17507Static Pointers with type classes generate misleading errors2021-11-21T19:11:37ZSimon BealStatic Pointers with type classes generate misleading errors## Summary
Using static with members of type classes generates unexpected and misleading type errors. The type errors produced by GHC complain about unsatisfiable type class constraints when the problem is (implicitly) that there is an ...## Summary
Using static with members of type classes generates unexpected and misleading type errors. The type errors produced by GHC complain about unsatisfiable type class constraints when the problem is (implicitly) that there is an unclosed argument.
## Steps to reproduce
```
{-# LANGUAGE StaticPointers #-}
{-# LANGUAGE GADTs #-}
import Type.Reflection (TypeRep, Typeable, typeRep)
import GHC.StaticPtr
data Dynamic where
Typed :: a -> StaticPtr (TypeRep a) -> Dynamic
toDyn :: (Typeable a) => a -> Dynamic
toDyn x = Typed x (static typeRep)
main :: IO ()
main = undefined
```
Compiling this produces the following error:
```
• No instance for (Typeable a) arising from a use of ‘typeRep’
• In the body of a static form: typeRep
In the second argument of ‘Typed’, namely ‘(static typeRep)’
In the expression: Typed x (static typeRep)
|
11 | toDyn x = Typed x (static typeRep)
| ^^^^^^^
```
The type error is unexpected, given that the assumption that `static` can be thought of as `static :: a -> StaticPtr a`. We can then introduce a function
```
static2 :: a -> StaticPtr a
static2 = undefined
```
and replacing `static` with `static2` allows the code to typecheck.
## Expected behavior
When using `static` with the member of a type class, this should be treated the same, or similar to using `static` with an unclosed argument.
## Environment
* GHC version used: 8.6.5
Optional:
* Operating System: Windows 10
* System Architecture: 64 bithttps://gitlab.haskell.org/ghc/ghc/-/issues/17478Add an optional Core pass to maximize shadowing2023-06-12T11:39:26ZKrzysztof GogolewskiAdd an optional Core pass to maximize shadowingThe goal of this ticket is to add an optional Core pass which changes all Uniques to maximize shadowing. This should help with finding bugs caused by shadowing.
Idea taken from comment https://gitlab.haskell.org/ghc/ghc/merge_requests/1...The goal of this ticket is to add an optional Core pass which changes all Uniques to maximize shadowing. This should help with finding bugs caused by shadowing.
Idea taken from comment https://gitlab.haskell.org/ghc/ghc/merge_requests/1496#note_218372.
This is similar to the option `-dunique-increment=` in the sense that it should have no visible effect in a correct compiler.https://gitlab.haskell.org/ghc/ghc/-/issues/17155Code coverage requires all derived methods to be tested2020-01-23T19:43:03ZhilcodeCode coverage requires all derived methods to be tested## Summary
Running "stack --coverage test" yields incorrect results.
## Steps to reproduce
Untar coverage-bug.tbz2 and run "stack --coverage test". Then look at the generated HTML page for Lib.hs (Lib.hs.html). It shows zero coverage ...## Summary
Running "stack --coverage test" yields incorrect results.
## Steps to reproduce
Untar coverage-bug.tbz2 and run "stack --coverage test". Then look at the generated HTML page for Lib.hs (Lib.hs.html). It shows zero coverage for Ord even though it was clearly tested.
[coverage-bug.tbz2](/uploads/4f3cdd657ff85dcf027ad655f9b4bf68/coverage-bug.tbz2)
## Expected behavior
Correct coverage numbers.
## Environment
I tried it with everything listed on https://www.stackage.org/.
* Nightly 2019-09-04
* LTS 14.4 for ghc-8.6.5
* LTS 13.19 for ghc-8.6.4
* LTS 13.11 for ghc-8.6.3
* LTS 12.26 for ghc-8.4.4
* LTS 12.14 for ghc-8.4.3
* LTS 11.22 for ghc-8.2.2
* LTS 9.21 for ghc-8.0.2
* LTS 7.24 for ghc-8.0.1
* LTS 6.35 for ghc-7.10.3
* LTS 3.22 for ghc-7.10.2
Optional:
* Operating System: Gentoo
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/17127Remove `StringBuffer` in favor of `Text` or `ByteString`2021-04-22T08:13:57ZSebastian GrafRemove `StringBuffer` in favor of `Text` or `ByteString`@mpickering noticed that GHC seems to have its own type that is practically identical to `Text`/`ByteString`, called `StringBuffer`.
We should investigate how to remove it/make it a newtype around `Text` or `ByteString` without incurrin...@mpickering noticed that GHC seems to have its own type that is practically identical to `Text`/`ByteString`, called `StringBuffer`.
We should investigate how to remove it/make it a newtype around `Text` or `ByteString` without incurring any performance hit.⊥https://gitlab.haskell.org/ghc/ghc/-/issues/17117Subscript numerals in type error reporting2021-06-30T21:49:38ZVanessa McHaleSubscript numerals in type error reporting## Motivation
The Futhark compiler reports type errors like so:
```
Cannot unify `t₅`' with type
[]t₄
as `t₅` must be one of i8, i16, i32, i64, u8, u16, u32, u64, f32, f64 due to integer literal at [6]> :1:19-19).
When matching type
...## Motivation
The Futhark compiler reports type errors like so:
```
Cannot unify `t₅`' with type
[]t₄
as `t₅` must be one of i8, i16, i32, i64, u8, u16, u32, u64, f32, f64 due to integer literal at [6]> :1:19-19).
When matching type
[]t₄
with
t₅
```
## Proposal
GHC reports type unification using things like `a0` or `b1`. I propose that it instead report not being able to match `a₀` with `b₁`, for example.https://gitlab.haskell.org/ghc/ghc/-/issues/17040Proposal: add HasCallStack for all partial functions2021-12-09T14:57:56ZLuo ChenProposal: add HasCallStack for all partial functionsMotivation
----------
Partial functions in base (especially Prelude) often cause runtime errors and is hard to locate.
For example, consider the following piece of code:
```
import GHC.Stack
foo :: HasCallStack => [Int] -> Int
foo xs...Motivation
----------
Partial functions in base (especially Prelude) often cause runtime errors and is hard to locate.
For example, consider the following piece of code:
```
import GHC.Stack
foo :: HasCallStack => [Int] -> Int
foo xs = last xs + 1
xs :: [Int]
xs = []
main :: IO ()
main = do
print $ foo xs
```
In this case, the error message will tell nothing about `foo`, and the `HasCallStack` constraint is totally helpless, because the call stack is cut off by the call to `last` which without `HasCallStack` constraint.
My current workaround is define my own wrapper functions with `HasCallStack` constraint for some mostly used partial functions to make them traceable, and use the wrapper (the traceable version) whenever I need them.
e.g.
```
last' :: HasCallStack => [a] -> a
last' xs = case xs of [] -> error "abuse last"; _ -> last xs
```
So, IMHO, if our goal is to make errors in haskell traceable, then **only providing `HasCallStack` mechanism is not enough, we have to provide traceable base package at the same time**.
Further more, all untraceable partial functions are considered to be harmful, and should not be exported by any package. Because an improper call to an untraceable partial function will cut off the call stack ([here is a demonstration about that](https://gist.github.com/luochen1990/94179a2492ff7d1ca45153645f1bb449)).
On the other hand, it is never necessary for us to add `HasCallStack` for a total function, so I suggest that we add `HasCallStack` constraint for (and only for) partial functions, and IMHO this could be a good balance for better debugging experience and less runtime overhead.
Proposal
--------
1. add `HasCallStack` constraint for all partial functions in base package
2. suggest all package maintainers to add `HasCallStack` constraint for their exported partial functions
3. provide a compiler option like `-fignore-hascallstack` to toggle off the effect of `HasCallStack` constraint in case somebody need best performance
Other Considerations
--------------------
### Why not just use `-xc` to get a stacktrace?
There is indeed some differences between the two stack tracing solutions:
1. The stack trace generated by `-xc` contains no line number and column number of the call site.
2. When we run a long running program, such as a web service, it is not easy to reproduce the issue, most of the time, you have no chance to recompile or restart your program to debug, all you can rely on is the printed logs, this makes `-xc` not as useful as `HasCallStack`.
3. The `HasCallStack` solution is much more friendly for learners, you don't need to know any tricks to get a stack trace printed, this reason seems ridiculous but IMHO it indeed affects the learning curve of Haskell.
### Is it a consistent design?
Some people may feel it weird if we just add `HasCallStack` for some functions but not the others, but I think it is consistent since we have a concrete rule to decide whether we need to add `HasCallStack` for a function -- by it's totality.
### What about the performance issue?
I think we need a benchmark test before we weigh up the advantages and the disadvantages. It would be good news if there are some available testsuites for this purpose.
Related Works
-------------
- [The callstack is already added for Data.Maybe.fromJust before this proposal](https://gitlab.haskell.org/ghc/ghc/commit/614028e3b02a5b71a9fbf9c7028f270760ccdab2)
- [An immature post about the same topic](https://gitlab.haskell.org/ghc/ghc/issues/16760)
- [A post on the mail list about the same topic](https://mail.haskell.org/pipermail/libraries/2019-June/thread.html#29652)https://gitlab.haskell.org/ghc/ghc/-/issues/17026Remove IntRep and WordRep (and maybe AddrRep?)2020-01-23T19:40:40ZÖmer Sinan AğacanRemove IntRep and WordRep (and maybe AddrRep?)(Forked from #16964)
The `PrimRep`s `IntRep` and `WordRep` are currently 32-bit on 32-bit systems and
64-bit on 64-bit systems. The problem is `IntRep` is still different than
`Int32Rep` on a 32-bit system (and `Int64Rep` on 64-bit), ev...(Forked from #16964)
The `PrimRep`s `IntRep` and `WordRep` are currently 32-bit on 32-bit systems and
64-bit on 64-bit systems. The problem is `IntRep` is still different than
`Int32Rep` on a 32-bit system (and `Int64Rep` on 64-bit), even though they're
represented the same.
The idea is to remove `IntRep` and `WordRep` so that on a 64-bit system types
like `Int#` and `Word#` would have `Int64Rep` (and `Int32Rep` on 32-bit).
This simplifies the `PrimRep` comparison logic -- e.g. we currently have bugs
when checking coercion safety when coercing a `Int#` (which has `IntRep`) to a
`Int64#` (which has `Int64Rep` on 64-bit) -- see #16952. Overall having less
`PrimRep`s should make dealing with them easier.
Similarly, I think we could remove `AddrRep` as well -- it'd be `Word32Rep` or
`Word64Rep` depending on the word size.
(Doing this is one way to fix #16952 and unblock the !1381 -- which fixes
release-blocking #16893)
---
Note that `PrimRep` is exposed to users via `GHC.Types.RuntimeRep`, so this is a
user-facing change (but perhaps not in a stable part of the GHC API). E.g. this
program
```
main = print (splitApps (typeRepKind (typeRep @Int#)))
```
will print differently if this proposal is implemented.
---
I've started working on this -- the main difficulty is we need to pass
`DynFlags` (or word size) to top-level constants like `intPrimTyCon` and
`wordPrimTyCon`, which transitively causes a lot of things to depend on
`DynFlags` (or word size).
cc @simonpj @bgamariÖmer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16955Improve parse error reporting.2023-12-31T16:14:48ZGuillaume BouchardImprove parse error reporting.## More accurate parse error
### Motivation
The current parser gives limited information in case of parse errors and immediately stops, disabling any additional error reporting from the type checker.
For example, the following:
```ha...## More accurate parse error
### Motivation
The current parser gives limited information in case of parse errors and immediately stops, disabling any additional error reporting from the type checker.
For example, the following:
```haskell
foo x y z = bar
(x, y, z)
(y, x, z)
(x, x, y
(y, y, y)
data Chicken = CotCotCot
bar a b c d = print ((a, b, c, d) + "hello")
```
Fails with the following error message:
```
Parse.hs:7:1: error:
parse error (possibly incorrect indentation or mismatched brackets)
|
7 | data Chicken = CotCotCot
| ^
```
In this example, the error is 3 lines above, so that's difficult to fix.
### Proposal
I'd like more hints about the reasons for the parse error. An error message like:
```
- parse error (possible incorrect indentation or mismatched brackets)
- Expected ')'. Opening context was:
3 | (x, x, y
| ^
```
## Error recovery
### Motivation
Moreover, the last line contains a type error (i.e. `+` between a tuple and a `String`) that I'd like to see at the same time.
When I'm developing, that's really common that in the middle of a function definition, I decide to introduce another type / function. To get repl / type checking / editor integration during that sub task, I need to ensure that the function I was currently writing does not generate a syntax error. Most of the time I have to comment my work in progress.
If the parser was able to do some recovery and continue the type checking on my file, I may be able to stop right in the middle of an expression and start something else in the file. This can dramatically improve the workflow in an editor which implements check as you type using ghci.
For example, the following code:
```
bar = 1 * "hello"
data Point = Point Float Float Float
```
Triggers the following change of the editor status when I type the last line:
```
d*ata P|oint =* P|oint F#oat| F#oat| F#oat
```
With each chars, `*`, `|` and `#` representing a change in the error reporting:
- `*` is a syntax error, meaning the type error of the first line is not reported
- `|` syntax is ok, GHC happily report the type error of the first line
- `#` syntax is OK, but ghc only reports the not in scope constructor F(oat)
## Proposal
I'd like the parser to be able to recover from parsing error and pass an incomplete AST to the type checker so that parsing error and type error can cohabit.
For the comparaison, I wrote a simple c++ program:
```c++
class Foo
{}
int main()
{
int v[][3] = {
{1,2,3},
{4,5,6,
{7,8,9},
};
Foo() * 2;
}
```
This program contains a few syntax error and type errors. This is the `gcc` output:
```
Parse.cpp:2:3: error: expected ‘;’ after class definition
{}
^
;
Parse.cpp: In function ‘int main()’:
Parse.cpp:10:8: error: expected ‘}’ before ‘;’ token
};
^
Parse.cpp:10:8: error: too many initializers for ‘int [3]’
Parse.cpp:11:11: error: no match for ‘operator*’ (operand types are ‘Foo’ and ‘int’)
Foo() * 2;
~~~~~~^~~
```
Here `gcc` is able to find the two syntax error and gives precise position information. But `gcc` also show the type error (i.e. `Foo() * 2`) alongside.
# Conclusion
I think theses changes may improve the development experience by giving more interesting feedbacks to the developer and help him focus on the important task. Sometime fixing a syntax error is less important that writing an utility function and I'd like GHC to help me even if another part of my file contains a syntax error.https://gitlab.haskell.org/ghc/ghc/-/issues/16720Make it easier to see why tests have failed in CI2019-05-31T09:51:37ZMatthew PickeringMake it easier to see why tests have failed in CIAt the moment you can't really see why a test fails unless you download the log.
I can see two ways to make this better.
1. Run the failing tests again at the end of the testsuite run.
2. Pretty print the `junit.xml` file using `xq` o...At the moment you can't really see why a test fails unless you download the log.
I can see two ways to make this better.
1. Run the failing tests again at the end of the testsuite run.
2. Pretty print the `junit.xml` file using `xq` or something similar.https://gitlab.haskell.org/ghc/ghc/-/issues/16625Add unit tests to Core Lint2023-05-16T20:10:31ZKrzysztof GogolewskiAdd unit tests to Core LintAs far as I am aware, there are no unit tests for Lint.
This means that when refactoring the code, it's possible to accidentally disable or weaken a test, without getting any feedback.
For every error message in Lint, we should have a ...As far as I am aware, there are no unit tests for Lint.
This means that when refactoring the code, it's possible to accidentally disable or weaken a test, without getting any feedback.
For every error message in Lint, we should have a test that creates an invalid Core program (without going through desugarer) and checks that the error message is present.
---
Additionally, we should have similar tests for STG Lint and Cmm Lint. (This can be moved to a separate ticket.)https://gitlab.haskell.org/ghc/ghc/-/issues/16578Use dataToTag# to derive Ord instances for enumerations2021-12-09T15:11:37ZBen GamariUse dataToTag# to derive Ord instances for enumerationsWhen looking into #16577 I rediscovered that GHC-derived `Ord` instances grow quite quickly. However, it does seem like there is some low-hanging fruit in the case of pure enumerations: Compare on the basis of tag via `dataToTag#`.
The ...When looking into #16577 I rediscovered that GHC-derived `Ord` instances grow quite quickly. However, it does seem like there is some low-hanging fruit in the case of pure enumerations: Compare on the basis of tag via `dataToTag#`.
The same can be done for `Eq` and `Enum`.https://gitlab.haskell.org/ghc/ghc/-/issues/16463Compiling HsInstances with optimisations is slow2021-03-11T00:48:27ZSebastian GrafCompiling HsInstances with optimisations is slow`DynFlags` and `HsInstances` compile egregiously slowly. This has come to my attention repeatedly, but https://neilmitchell.blogspot.com/2019/03/ghc-rebuild-times-shake-profiling.html convinced me that we should really do something about...`DynFlags` and `HsInstances` compile egregiously slowly. This has come to my attention repeatedly, but https://neilmitchell.blogspot.com/2019/03/ghc-rebuild-times-shake-profiling.html convinced me that we should really do something about this: Compare stage0 (`-O2`) and stage1 (`-O0`) builds by filtering for DynFlags and HsInstances [here](https://shakebuild.com/profile/hadrian-2019-03-18.html).
- Compiling DynFlags and HsInstances with `-O2` slows down a parallel build by 3 minutes
- Compiling DynFlags with `-O2` slows down by a factor of 6 (0:12 vs 1:17)
- Compiling HsInstances with `-O2` slows down by a factor of 8 (0:31 vs 4:20)
HsInstances is the worse of the two, but also more critical to GHC's performance. Profiling DynFlags for offending optimisations might be more viable.https://gitlab.haskell.org/ghc/ghc/-/issues/16126Make -threaded the default2023-12-21T14:16:36ZMatthew PickeringMake -threaded the defaultSimon M writes back in 2016
> Related to this, I think it's about time we made -threaded the default. We could add a -single-threaded option to get back the old behaviour.
>
> There is a small overhead to using -threaded, but -threaded ...Simon M writes back in 2016
> Related to this, I think it's about time we made -threaded the default. We could add a -single-threaded option to get back the old behaviour.
>
> There is a small overhead to using -threaded, but -threaded is also required to make a lot of things work (e.g. waitForProcess in a multithreaded program, not to mention parallelism).
All that needs doing is to add a flag `-single-threaded` to enable the old behaviour and a deprecation warning alerting uses that `-threaded` is the new default.
https://mail.haskell.org/pipermail/ghc-devs/2016-October/013101.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make -threaded the default","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":["newcomer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Simon M writes back in 2016\r\n\r\n> Related to this, I think it's about time we made -threaded the default. We could add a -single-threaded option to get back the old behaviour.\r\n>\r\n> There is a small overhead to using -threaded, but -threaded is also required to make a lot of things work (e.g. waitForProcess in a multithreaded program, not to mention parallelism).\r\n\r\nAll that needs doing is to add a flag `-single-threaded` to enable the old behaviour and a deprecation warning alerting uses that `-threaded` is the new default.\r\n\r\nhttps://mail.haskell.org/pipermail/ghc-devs/2016-October/013101.html","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16064Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code2024-02-27T13:56:52ZAra AdkinsImproving Placement of Heap Checks - Avoiding Slowdowns in Hot CodeWhen generating both heap and stack checks in Cmm, GHC can sometimes be fairly obtuse about their placement. As a result, they can be generated for paths in hot code that actually do not perform any allocation. Examples can be found in t...When generating both heap and stack checks in Cmm, GHC can sometimes be fairly obtuse about their placement. As a result, they can be generated for paths in hot code that actually do not perform any allocation. Examples can be found in the related tickets, particularly #14791 and #16040.
This ticket exists to track the work [proposed](https://ghc.haskell.org/trac/ghc/ticket/16040#comment:5) by Simon to detect such code patterns. They are described as follows:
1. A primitive case with no allocation upstream from it.
1. One alternative that performs no allocation.
Under such circumstances the stack/heap checks can be moved from being performed on every iteration to being performed just prior to the allocation itself.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.9","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":["CodeGen,","Performance"],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Task","description":"When generating both heap and stack checks in Cmm, GHC can sometimes be fairly obtuse about their placement. As a result, they can be generated for paths in hot code that actually do not perform any allocation. Examples can be found in the related tickets, particularly #14791 and #16040.\r\n\r\nThis ticket exists to track the work [https://ghc.haskell.org/trac/ghc/ticket/16040#comment:5 proposed] by Simon to detect such code patterns. They are described as follows:\r\n\r\n1. A primitive case with no allocation upstream from it.\r\n2. One alternative that performs no allocation.\r\n\r\nUnder such circumstances the stack/heap checks can be moved from being performed on every iteration to being performed just prior to the allocation itself. ","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15683coerce fails for Coercible type families2021-10-14T08:39:12ZIcelandjackcoerce fails for Coercible type familiesI want to bring attention to this [reddit post](https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_when_type_instances_are/) that boils down to
```hs
type family X a
type instance X Int = String
type instance X B...I want to bring attention to this [reddit post](https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_when_type_instances_are/) that boils down to
```hs
type family X a
type instance X Int = String
type instance X Bool = String
data T a = T (X a)
```
but not being able to coerce
```hs
coerce :: T Int -> T Bool
```
This gives the error “Couldn't match type ‘`Int`’ with ‘`Bool`’ arising from a use of ‘`coerce`’”.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"coerce fails for Coercible type families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I want to bring attention to this [https://www.reddit.com/r/haskell/comments/9io4xw/coercing_type_families_when_type_instances_are/ reddit post] that boils down to \r\n\r\n{{{#!hs\r\ntype family X a\r\ntype instance X Int = String\r\ntype instance X Bool = String\r\n\r\ndata T a = T (X a)\r\n}}}\r\n\r\nbut not being able to coerce\r\n\r\n{{{#!hs\r\ncoerce :: T Int -> T Bool\r\n}}}\r\n\r\nThis gives the error “Couldn't match type ‘`Int`’ with ‘`Bool`’ arising from a use of ‘`coerce`’”.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15678Provide the provenance of unification variables in error messages when possible2023-12-14T10:21:25ZRyan ScottProvide the provenance of unification variables in error messages when possibleConsider the following code:
```hs
module Foo where
x :: Int
x = const 42 _
```
When compiles, this gives the following suggestion:
```
$ /opt/ghc/8.6.1/bin/ghc Bug.hs
[1 of 1] Compiling Foo ( Bug.hs, Bug.o )
Bug.hs:4:1...Consider the following code:
```hs
module Foo where
x :: Int
x = const 42 _
```
When compiles, this gives the following suggestion:
```
$ /opt/ghc/8.6.1/bin/ghc Bug.hs
[1 of 1] Compiling Foo ( Bug.hs, Bug.o )
Bug.hs:4:14: error:
• Found hole: _ :: b0
Where: ‘b0’ is an ambiguous type variable
• In the second argument of ‘const’, namely ‘_’
In the expression: const 42 _
In an equation for ‘x’: x = const 42 _
• Relevant bindings include x :: Int (bound at Bug.hs:4:1)
Valid hole fits include
x :: Int (bound at Bug.hs:4:1)
otherwise :: Bool
(imported from ‘Prelude’ at Bug.hs:1:8-10
(and originally defined in ‘GHC.Base’))
False :: Bool
(imported from ‘Prelude’ at Bug.hs:1:8-10
(and originally defined in ‘GHC.Types’))
True :: Bool
(imported from ‘Prelude’ at Bug.hs:1:8-10
(and originally defined in ‘GHC.Types’))
lines :: String -> [String]
(imported from ‘Prelude’ at Bug.hs:1:8-10
(and originally defined in ‘base-4.12.0.0:Data.OldList’))
unlines :: [String] -> String
(imported from ‘Prelude’ at Bug.hs:1:8-10
(and originally defined in ‘base-4.12.0.0:Data.OldList’))
(Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)
|
4 | x = const 42 _
| ^
```
One thing that's rather ugly about this is the use of the type `b0`. What exactly //is// `b0` anyway? The only hint that the error message gives is that it's an ambiguous type variable. But that's not terribly helpful to figure out where `b0` arises from. Ambiguous type variables like this one arise quite frequently when writing Haskell code, and it can often take some sleuthing to figure out why they pop up.
simonpj had one suggestion for making ambiguous type variables less confusing: report their provenance whenever possible. There is one notable example of a situation where it's simple to explain from where exactly in the source code a unification variable originates: function applications. In particular, the program above applies the function `const 42` to `_`, which means that the type of `const 42` is instantiated to be `b0 -> Int`. Let's report this! Something like:
```
• Found hole: _ :: b0
Where: ‘b0’ is an ambiguous type variable
Arising from an application of
(const 42 :: b0 -> Int)
In the expression: const 42 _
```
This would go a long way to clearing up what GHC is thinking when it reports these ambiguous type variable errors. While we can't easily report the provenance of //every// ambiguous type variables, those arising from function applications are quite doable. We might be able to reuse the `CtOrigin` machinery (or take heavy inspiration from it) to accomplish this feat.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Tritlo |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Provide the provenance of unification variables in error messages when possible","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":["TypeErrors"],"differentials":[],"test_case":"","architecture":"","cc":["Tritlo"],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{#!hs\r\nmodule Foo where\r\n\r\nx :: Int\r\nx = const 42 _\r\n}}}\r\n\r\nWhen compiles, this gives the following suggestion:\r\n\r\n{{{\r\n$ /opt/ghc/8.6.1/bin/ghc Bug.hs\r\n[1 of 1] Compiling Foo ( Bug.hs, Bug.o )\r\n\r\nBug.hs:4:14: error:\r\n • Found hole: _ :: b0\r\n Where: ‘b0’ is an ambiguous type variable\r\n • In the second argument of ‘const’, namely ‘_’\r\n In the expression: const 42 _\r\n In an equation for ‘x’: x = const 42 _\r\n • Relevant bindings include x :: Int (bound at Bug.hs:4:1)\r\n Valid hole fits include\r\n x :: Int (bound at Bug.hs:4:1)\r\n otherwise :: Bool\r\n (imported from ‘Prelude’ at Bug.hs:1:8-10\r\n (and originally defined in ‘GHC.Base’))\r\n False :: Bool\r\n (imported from ‘Prelude’ at Bug.hs:1:8-10\r\n (and originally defined in ‘GHC.Types’))\r\n True :: Bool\r\n (imported from ‘Prelude’ at Bug.hs:1:8-10\r\n (and originally defined in ‘GHC.Types’))\r\n lines :: String -> [String]\r\n (imported from ‘Prelude’ at Bug.hs:1:8-10\r\n (and originally defined in ‘base-4.12.0.0:Data.OldList’))\r\n unlines :: [String] -> String\r\n (imported from ‘Prelude’ at Bug.hs:1:8-10\r\n (and originally defined in ‘base-4.12.0.0:Data.OldList’))\r\n (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)\r\n |\r\n4 | x = const 42 _\r\n | ^\r\n}}}\r\n\r\nOne thing that's rather ugly about this is the use of the type `b0`. What exactly //is// `b0` anyway? The only hint that the error message gives is that it's an ambiguous type variable. But that's not terribly helpful to figure out where `b0` arises from. Ambiguous type variables like this one arise quite frequently when writing Haskell code, and it can often take some sleuthing to figure out why they pop up.\r\n\r\nsimonpj had one suggestion for making ambiguous type variables less confusing: report their provenance whenever possible. There is one notable example of a situation where it's simple to explain from where exactly in the source code a unification variable originates: function applications. In particular, the program above applies the function `const 42` to `_`, which means that the type of `const 42` is instantiated to be `b0 -> Int`. Let's report this! Something like:\r\n\r\n{{{\r\n • Found hole: _ :: b0\r\n Where: ‘b0’ is an ambiguous type variable\r\n Arising from an application of\r\n (const 42 :: b0 -> Int)\r\n In the expression: const 42 _\r\n}}}\r\n\r\nThis would go a long way to clearing up what GHC is thinking when it reports these ambiguous type variable errors. While we can't easily report the provenance of //every// ambiguous type variables, those arising from function applications are quite doable. We might be able to reuse the `CtOrigin` machinery (or take heavy inspiration from it) to accomplish this feat.","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15461Machine accessible interface to GHCi2024-03-22T13:04:43ZBen GamariMachine accessible interface to GHCiFor a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) ...For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [haskell-mode](https://github.com/haskell/haskell-mode/issues/1553#issuecomment-409267399]]).
Ultimately the general shape of the solution seems fairly clear:
1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session)
2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output
(1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs:
* what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?)
* how does one open a new channel?
* are the `std{in,out,err}` handles redirected? For instance, if multiple channels request execution of `putStrLn "hello world"` who gets the output? There are three options,
a. neither requester gets any output
b. both channels get two "hello world" messages
c. each channel gets precisely the output from its evaluation
(c) would be quite hard to do although an approximation could potentially be accomplished by hacking `GHC.IO.Handle.FD`.
(2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner).
== Possible users ==
Users of this facility might include,
* [[https://github.com/haskell/haskell-mode/)
- [IHaskell](https://github.com/gibiansky/IHaskell)
- Intero?https://gitlab.haskell.org/ghc/ghc/-/issues/15432Referring to current module (or aliasing current module)2020-10-02T21:46:39ZAndri MReferring to current module (or aliasing current module)Hey,
Suppose I got a record type `Game` in a module `Lib.Game` that has a field `player`. I'd occasionally like to use the variable `player` in a closure, but still refer to the `player` field accessor once to assign the variable. Is it...Hey,
Suppose I got a record type `Game` in a module `Lib.Game` that has a field `player`. I'd occasionally like to use the variable `player` in a closure, but still refer to the `player` field accessor once to assign the variable. Is it me or right now there's no way to refer to the current module by anything other than its full name? That is, to disambiguate the variable and function, I have to type `let player = Lib.Game.player`.
In other words, I'd like the invocation of `Lib.Game.player` below to be shortened somehow, either by assigning an alias to the current module via `import qualified` (can't now as it results in a self-cycle) or by some other means of referring to the closing module.
```hs
module Lib.Game where
data Game = Game {player :: Player}
play game = foo player where player = Lib.Game.player game
```
This is vaguely similar to #10336, but the `SOURCE` pragma seems to be about actually cyclical imports.
Thanks!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| 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":"Referring to current module (or aliasing current module)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"⊥","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Hey,\r\n\r\nSuppose I got a record type `Game` in a module `Lib.Game` that has a field `player`. I'd occasionally like to use the variable `player` in a closure, but still refer to the `player` field accessor once to assign the variable. Is it me or right now there's no way to refer to the current module by anything other than its full name? That is, to disambiguate the variable and function, I have to type `let player = Lib.Game.player`.\r\n\r\nIn other words, I'd like the invocation of `Lib.Game.player` below to be shortened somehow, either by assigning an alias to the current module via `import qualified` (can't now as it results in a self-cycle) or by some other means of referring to the closing module. \r\n \r\n{{{#!hs\r\nmodule Lib.Game where\r\ndata Game = Game {player :: Player}\r\n\r\nplay game = foo player where player = Lib.Game.player game\r\n}}}\r\n\r\nThis is vaguely similar to https://ghc.haskell.org/trac/ghc/ticket/10336, but the `SOURCE` pragma seems to be about actually cyclical imports.\r\n\r\nThanks!","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/15397Linking Issue with libffi on Ubuntu and Fedora with Provided Bindists2024-01-19T11:48:16ZAra AdkinsLinking Issue with libffi on Ubuntu and Fedora with Provided BindistsIt appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. ...It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against.
This does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency.
You can reproduce the issue quickly by cloning [Luna Core](https://github.com/luna/luna-core) and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros.
```
stack build luna-shell --fast
stack exec luna
```
You should see something along the lines of the following.
```
error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
```
In essence, the reproduction steps are as follows:
1. Create a project depending on libffi using ghc-8.4.2
1. Build the project
1. Execute it
The *expected* result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution.
I can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists.
The actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2 |
| 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":"Linking Issue on Ubuntu and Fedora with Provided Bindists (GHC-8.4.2)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against.\r\n\r\nThis does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency.\r\n\r\nYou can reproduce the issue quickly by cloning [https://github.com/luna/luna-core Luna Core] and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros.\r\n\r\n{{{\r\nstack build luna-shell --fast\r\nstack exec luna\r\n}}}\r\n\r\nYou should see something along the lines of the following. \r\n\r\n{{{\r\nerror while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory\r\n}}}\r\n\r\nIn essence, the reproduction steps are as follows:\r\n\r\n1. Create a project depending on libffi using ghc-8.4.2\r\n2. Build the project\r\n3. Execute it\r\n\r\n\r\nThe ''expected'' result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution. \r\n\r\nI can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists. \r\n\r\nThe actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory. ","type_of_failure":"OtherFailure","blocking":[]} -->8.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/14812Dot-Notation for Flipped Function Application2019-07-07T18:15:29ZtepanDot-Notation for Flipped Function ApplicationPlease allow to put a dot `.` (without whitespaces) between two things for *flipped* function application. This could make for code in pseudo-OOP style:
```hs
encrypt(str) = do {
str.map(succ);
}
```
Currently, as a workaround, this ...Please allow to put a dot `.` (without whitespaces) between two things for *flipped* function application. This could make for code in pseudo-OOP style:
```hs
encrypt(str) = do {
str.map(succ);
}
```
Currently, as a workaround, this can be achieved by defining `(.) = flip ($)` (making `.` for function composition unavailable, though):
```hs
encrypt(str) = do {
str.map(succ);
} where (.) = flip ($)
```
(For a remotely similar look-and-feel, one could use `Data.Function.((&))` instead of `(.)`.)
Side note: `.` without whitespaces is already an OOP-like notational convenience in order to denote Modules and their elements in Haskell.
OOP:
- `Prelude.length("Hello")` (static function `length` of class `Prelude` applied to `"Hello"`)
Haskell:
- `Prelude.length("Hello")` (function `length` of module `Prelude` applied to `"Hello"`)
This means, that a distinction between ` . ` (with whitespaces) and `.` (without whitespaces) is already been made, which is why `Just . Just $ 42` compiles, whereas `Just.Just $ 42` doesn't. Analogously, with this Feature Request implemented, `"Hello".map(succ)` would compile whereas `"Hello" . map(succ)"` wouldn't.
Current dot-notation for modules (not to be changed):
- `Foo.bar` (`bar` of module `Foo`)
Proposed dot-noation for function application:
- `foo.bar` (function `bar` applied to `foo`)