GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:30:19Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/11462Use of typechecker plugin erroneously triggers "unbound implicit parameter" e...2019-07-07T18:30:19ZkwfUse of typechecker plugin erroneously triggers "unbound implicit parameter" errorTo document this bug, we're going to need a typechecker plugin to test it with. I've built a dummy plugin for this purpose, so we can be sure it is not interference from a particular plugin.
`dummy-plugin/dummy-plugin.cabal`
```
name: ...To document this bug, we're going to need a typechecker plugin to test it with. I've built a dummy plugin for this purpose, so we can be sure it is not interference from a particular plugin.
`dummy-plugin/dummy-plugin.cabal`
```
name: dummy-plugin
version: 0.1.0.0
category: Development
build-type: Simple
cabal-version: >=1.10
library
hs-source-dirs: .
exposed-modules: DummyPlugin
build-depends: base, ghc
default-language: Haskell2010
GHC-options: -Wall -O2
```
`dummy-plugin/DummyPlugin.hs`
```hs
module DummyPlugin(plugin) where
import TcRnMonad ( TcPlugin(..), TcPluginResult(..) )
import Plugins ( defaultPlugin, Plugin(..), CommandLineOption )
plugin :: Plugin
plugin = defaultPlugin { tcPlugin = Just . thePlugin }
thePlugin :: [CommandLineOption] -> TcPlugin
thePlugin opts = TcPlugin
{ tcPluginInit = return ()
, tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] []
, tcPluginStop = \_ -> return ()
}
```
`Bug.hs`
```hs
{-# OPTIONS_GHC -fplugin=DummyPlugin #-}
module Bug where
impossible :: a
impossible = undefined
```
First, compile the dummy plugin. From its directory, run `cabal install` to install the plugin.
Then, from the main directory, run `ghc Bug.hs`.
Expected result: the file compiles.
Actual result:
```
Bug.hs:6:14: error:
• Unbound implicit parameter ?callStack::GHC.Stack.Types.CallStack
arising from a use of implicit parameter ‘?callStack’
• In the expression: undefined
In an equation for ‘impossible’: impossible = undefined
```
Further, observe that commenting out the line which invokes the type-checker plugin (the pragma on line 1) causes the file to compile correctly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use of typechecker plugin erroneously triggers \"unbound implicit parameter\" error","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"To document this bug, we're going to need a typechecker plugin to test it with. I've built a dummy plugin for this purpose, so we can be sure it is not interference from a particular plugin.\r\n\r\n{{{dummy-plugin/dummy-plugin.cabal}}}\r\n{{{\r\nname: dummy-plugin\r\nversion: 0.1.0.0\r\ncategory: Development\r\nbuild-type: Simple\r\ncabal-version: >=1.10\r\n\r\nlibrary\r\n hs-source-dirs: .\r\n exposed-modules: DummyPlugin\r\n build-depends: base, ghc\r\n default-language: Haskell2010\r\n GHC-options: -Wall -O2\r\n}}}\r\n\r\n{{{dummy-plugin/DummyPlugin.hs}}}\r\n{{{#!hs\r\nmodule DummyPlugin(plugin) where\r\n\r\nimport TcRnMonad ( TcPlugin(..), TcPluginResult(..) )\r\nimport Plugins ( defaultPlugin, Plugin(..), CommandLineOption )\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin { tcPlugin = Just . thePlugin }\r\n\r\nthePlugin :: [CommandLineOption] -> TcPlugin\r\nthePlugin opts = TcPlugin\r\n { tcPluginInit = return ()\r\n , tcPluginSolve = \\_ _ _ _ -> return $ TcPluginOk [] []\r\n , tcPluginStop = \\_ -> return ()\r\n }\r\n}}}\r\n\r\n{{{Bug.hs}}}\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin=DummyPlugin #-}\r\n\r\nmodule Bug where\r\n\r\nimpossible :: a\r\nimpossible = undefined\r\n}}}\r\n\r\nFirst, compile the dummy plugin. From its directory, run {{{cabal install}}} to install the plugin.\r\n\r\nThen, from the main directory, run {{{ghc Bug.hs}}}.\r\n\r\nExpected result: the file compiles.\r\nActual result:\r\n{{{\r\nBug.hs:6:14: error:\r\n • Unbound implicit parameter ?callStack::GHC.Stack.Types.CallStack\r\n arising from a use of implicit parameter ‘?callStack’\r\n • In the expression: undefined\r\n In an equation for ‘impossible’: impossible = undefined\r\n}}}\r\n\r\nFurther, observe that commenting out the line which invokes the type-checker plugin (the pragma on line 1) causes the file to compile correctly.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Eric SeidelEric Seidelhttps://gitlab.haskell.org/ghc/ghc/-/issues/9840Permit empty closed type families2020-06-17T11:38:04ZAdam GundryPermit empty closed type familiesAt the moment, closed type families without any equations fail with a parse error. In addition, they cannot be created by TH (see #8028). Would it be possible to permit these instead?
My use case is in my typechecker plugin for units of...At the moment, closed type families without any equations fail with a parse error. In addition, they cannot be created by TH (see #8028). Would it be possible to permit these instead?
My use case is in my typechecker plugin for units of measure, where I want to add new type-level operators without any equational theory (because it will be supplied by the plugin) and without users having the ability to introduce their own type family instances.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Permit empty closed type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"FeatureRequest","description":"At the moment, closed type families without any equations fail with a parse error. In addition, they cannot be created by TH (see #8028). Would it be possible to permit these instead?\r\n\r\nMy use case is in my typechecker plugin for units of measure, where I want to add new type-level operators without any equational theory (because it will be supplied by the plugin) and without users having the ability to introduce their own type family instances.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1