September 2018 - ghc-tickets

[GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory
by GHC 22 Nov '18

22 Nov '18

#15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: None | Version: Keywords: | Operating System: MacOS X Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path. See the offending `LC_LOAD_DYLIB` command here: {{{ $ jtool -l libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal) Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs) Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal) Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals) Mem: 0x0004df760-0x0004e0f40 __TEXT.__const Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info LC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs) Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs) Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs) Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs) Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill) LC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT LC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 04: LC_DYLD_INFO LC 05: LC_SYMTAB Symbol table is at offset 0x6a5348 (6968136), 118090 entries String table is at offset 0x873d78 (8863096), 3241616 bytes LC 06: LC_DYSYMTAB 81438 local symbols at index 0 35948 external symbols at index 81438 704 undefined symbols at index 117386 No TOC No modtab 1380 Indirect symbols at offset 0x8727e8 LC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA LC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0 LC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0 LC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib LC 11: LC_LOAD_DYLIB @rpath/libHSinteger- gmp-1.0.2.0-ghc8.6.0.20180714.dylib LC 12: LC_LOAD_DYLIB @rpath/libHSghc- prim-0.5.3-ghc8.6.0.20180714.dylib LC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib LC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib LC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0 LC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3 LC 17: LC_RPATH @loader_path/../rts LC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions LC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348) }}} The other offenders are `libHSbinary` and `libHSinteger-gmp`. Without changing these load commands, you'll get the following error: {{{ $ ./configure --prefix=... $ make install <snip> dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: ./libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} I tried passing the `--with-gmp-libraries` option to `configure`, but that did not help. I guess this is just a packaging problem, but figured you should be aware before the official release... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15633: Type-checker plugins aren't loaded in 8.6.1
by GHC 22 Nov '18

22 Nov '18

#15633: Type-checker plugins aren't loaded in 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Type-Checker plugins seem to work in GHCi-8.4.3 https://gist.github.com/phadej/f2040eba327a88d3652cda021403f97f However with GHC-8.6.1 The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180907 76a233143f1ec940f342ce3ce3afaf306923b392 (which seems to be the last commit in 8.6 branch atm) the plugins aren't loaded. {{{ % ghci-8.6.1 -fplugin=ThereIsNoPlugin GHCi, version 8.6.0.20180907: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ogre/.ghci λ> }}} starts a session without a warning. 8.4.3 however fails: {{{ % ghci-8.4.3 -fplugin=ThereIsNoPlugin GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help <command line>: Could not find module ‘ThereIsNoPlugin’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15633> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14784: RTS header files can't be used with a C++ compiler
by GHC 22 Nov '18

22 Nov '18

#14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile `m1.cpp`: {{{ #include "Rts.h" int main(int argc, char** argv) { } }}} with: {{{ g++ -g m1.cpp -std=c++11 -I includes/ -c }}} you get: {{{ In file included from includes/Rts.h:29:0, from m1.cpp:1: includes/Stg.h:29:3: error: #error __STDC_VERSION__ does not advertise C99 or later # error __STDC_VERSION__ does not advertise C99 or later ^ }}} It's not advertised anywhere that it should work, but it used to work. https://phabricator.haskell.org/D2045 is what introduced this check. Judging by https://stackoverflow.com/questions/48045243/ghc-gcc-compiler- issue-stdc-version-w-c99-from-stg-h-fails-for-every-packa, it affects GHC 8.2 and later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15669: T7040_ghci has a suspicious testcase failure
by GHC 22 Nov '18

22 Nov '18

#15669: T7040_ghci has a suspicious testcase failure ----------------------------------------+--------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: T7040_ghci | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- T7040_ghci has a weird failure. This looks like BSS initialization issue in the linker maybe? {{{ +++ rts/T7040_ghci.run/T7040_ghci.run.stdout.normalised 2018-09-23 17:26:01.197146900 +0100 @@ -1,2 +1,2 @@ -x: 0 +x: 493156 x: 1 }}} Luckily the value seems to mutate correctly. So it may just be a simple missing `memset`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15216: plugins10 broken
by GHC 22 Nov '18

22 Nov '18

#15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `plugins10` from Phab:D4342 is broken, but I am merging regardless and will sort it out later. {{{ =====> plugins10(normal) 7 of 22 [0, 1, 0] cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple- plugin package.plugins10 TOP=/mnt/work/ghc/ghc/testsuite cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 Wrong exit code for plugins10()(expected 0 , actual 2 ) Stdout ( plugins10 ): parsePlugin() interfacePlugin: Prelude interfacePlugin: Language.Haskell.TH interfacePlugin: Language.Haskell.TH.Quote interfacePlugin: GHC.Float interfacePlugin: GHC.Base interfacePlugin: Language.Haskell.TH.Syntax interfacePlugin: GHC.Types typeCheckPlugin (rn) typeCheckPlugin (tc) interfacePlugin: GHC.Integer.Type parsePlugin(a) interfacePlugin: Language.Haskell.TH.Lib.Internal metaPlugin: return [] metaPlugin: quoteExp stringify "x" interfacePlugin: GHC.CString Stderr ( plugins10 ): plugins10.hs:9:5: fatal: cannot find object file for module ‘Simple.SourcePlugin’ while linking an interpreted expression make[2]: *** [Makefile:30: plugins10] Error 1 *** unexpected failure for plugins10(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15671: Link errors due to forcibly exporting findPtr
by GHC 22 Nov '18

22 Nov '18

#15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: T10955dyn | Blocked By: T10955 | Blocking: | Related Tickets: Differential Rev(s): Phab:D5138 | Wiki Page: -------------------------------------+------------------------------------- The change in https://phabricator.haskell.org/rGHC900c47f88784b91517c00be3e1087322e62f698e is causing link errors due to the combination of `-Wl,-u` and `-Wl ,--export-all-symbols` {{{ Wrong exit code for T10955dyn()(expected 0 , actual 2 ) Stderr ( T10955dyn ): E:/ghc- dev/msys64/home/Tamar/ghc/rts/dist/build/libHSrts_thr.a(Printer.thr_o): In function `findPtr': E:\ghc-dev\msys64\home\Tamar\ghc/rts/Printer.c:880: multiple definition of `findPtr' ./bin_dyn/libA.dll.a(d020776.o):(.text+0x0): first defined here }}} I believe the correct solution is to just use a cabal flag to emulate the setup we had with make, instead of forcing this symbol always. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition)
by GHC 22 Nov '18

22 Nov '18

#8634: Code valid in GHC 7.6 is impossible to move over GHC 7.7 (because of liberal coverage condition) ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- == Abstract == Hi! I'm writing a compiler, which produces Haskell code. I've discovered it is impossible to keep currently used features / logic using GHC 7.7 instead of 7.6 Below is more detailed description of the problem: == The idea == I'm writing a [DSL][1], which compiles to Haskell. Users of this language can define own immutable data structures and associated functions. By associated function I mean a function, which belongs to a data structure. For example, user can write (in "pythonic" pseudocode): {{{#!python data Vector a: x,y,z :: a def method1(self, x): return x }}} (which is equivalent to the following code, but shows also, that associated functions beheva like type classes with open world assumption): {{{#!python data Vector a: x,y,z :: a def Vector.method1(self, x): return x }}} In this example, `method1` is a function associated with `Vector` data type, and can be used like `v.testid(5)` (where `v` is instance of `Vector` data type). I'm translating such code to Haskell code, but I'm facing a problem, which I'm trying to solve for a long time. == The problem == I'm trying to move the code from GHC 7.6 over GHC 7.7. The code works perfectly under GHC 7.6, but does not under GHC 7.7. I want to ask you how can I fix it to make it working in the new version of the compiler? == Example code == Lets see a simplified version of generated (by my compiler) Haskell code: {{{#!haskell {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FunctionalDependencies #-} import Data.Tuple.OneTuple ------------------------------ -- data types ------------------------------ data Vector a = Vector {x :: a, y :: a, z :: a} deriving (Show) -- the Vector_testid is used as wrapper over a function "testid". newtype Vector_testid a = Vector_testid a ------------------------------ -- sample function, which is associated to data type Vector ------------------------------ testid (v :: Vector a) x = x ------------------------------ -- problematic function (described later) ------------------------------ testx x = call (method1 x) $ OneTuple "test" ------------------------------ -- type classes ------------------------------ -- type class used to access "method1" associated function class Method1 cls m func | cls -> m, cls -> func where method1 :: cls -> m func -- simplified version of type class used to "evaluate" functions based on -- their input. For example: passing empty tuple as first argument of `call` -- indicates evaluating function with default arguments (in this example -- the mechanism of getting default arguments is not available) class Call a b where call :: a -> b ------------------------------ -- type classes instances ------------------------------ instance (out ~ (t1->t1)) => Method1 (Vector a) Vector_testid out where method1 = (Vector_testid . testid) instance (base ~ (OneTuple t1 -> t2)) => Call (Vector_testid base) (OneTuple t1 -> t2) where call (Vector_testid val) = val ------------------------------ -- example usage ------------------------------ main = do let v = Vector (1::Int) (2::Int) (3::Int) -- following lines equals to a pseudocode of ` v.method1 "test" ` -- OneTuple is used to indicate, that we are passing single element. -- In case of more or less elements, ordinary tuples would be used. print $ call (method1 v) $ OneTuple "test" print $ testx v }}} The code compiles and works fine with GHC 7.6. When I'm trying to compile it with GHC 7.7, I'm getting following error: {{{ debug.hs:61:10: Illegal instance declaration for ‛Method1 (Vector a) Vector_testid out’ The liberal coverage condition fails in class ‛Method1’ for functional dependency: ‛cls -> func’ Reason: lhs type ‛Vector a’ does not determine rhs type ‛out’ In the instance declaration for ‛Method1 (Vector a) Vector_testid out’ }}} The error is caused by new rules of checking what functional dependencies can do, namely `liberal coverage condition` (as far as I know, this is `coverage condition` relaxed by using `-XUndecidableInstances`) == Some attemps to fix the problem == I was trying to overcome this problem by changing the definition of `Method1` to: {{{#!haskell class Method1 cls m func | cls -> m where method1 :: cls -> m func }}} Which resolves the problem with functional dependencies, but then the line: {{{#!haskell testx x = call (method1 x) $ OneTuple "test" }}} is not allowed anymore, causing a compile error (in both 7.6 and 7.7 versions): {{{ Could not deduce (Method1 cls m func0) arising from the ambiguity check for ‛testx’ from the context (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) bound by the inferred type for ‛testx’: (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s at debug.hs:50:1-44 The type variable ‛func0’ is ambiguous When checking that ‛testx’ has the inferred type ‛forall cls (m :: * -> *) func s. (Method1 cls m func, Call (m func) (OneTuple [Char] -> s)) => cls -> s’ Probable cause: the inferred type is ambiguous }}} It is also impossible to solve this issue using type families (as far as I know). If we replace `Method1` type class and instances with following code (or simmilar): {{{#!haskell class Method1 cls m | cls -> m where type Func cls method1 :: cls -> m (Func cls) instance Method1 (Vector a) Vector_testid where type Func (Vector a) = (t1->t1) method1 = (Vector_testid . testid) }}} We would get obvious error `Not in scope: type variable ‛t1’`, because type families does not allow to use types, which does not appear on LHS of type expression. == The final question == How can I make this idea work under GHC 7.7? I know the new `liberal coverage condition` allows GHC devs make some progress with type checking, but it should somehow be doable to port idea working in GHC 7.6 over never compiler version. (without forcing user of my DSL to introduce any further types - everything so far, like type class instances, I'm genarating using Template Haskell) Maybe is there a way to indroduce an extension, which will disable liberal coverage condition in such situations? There is also a StackOverflow discussion available, here: http://stackoverflow.com/questions/20778588/liberal-coverage-condition- introduced-in-ghc-7-7-breaks-code-valid-in-ghc-7-6 [1]: http://en.wikipedia.org/wiki/Domain-specific_language -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 71

[GHC] #15519: Minor code refactoring leads to drastic performance degradation
by GHC 21 Nov '18

21 Nov '18

#15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi! I've just observed an important performance problem. This code: {{{ test0 :: Text -> Result test0 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test0 #-} }}} runs over 10 times faster than this one: {{{ testGrammar1 :: Grammar Char testGrammar1 = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' in many $! s1 <> s2 <> s3 <> s4 {-# INLINE testGrammar1 #-} test1 :: Text -> Result test1 = runTokenParser testGrammar1 {-# NOINLINE test1 #-} }}} I've also observed another thing here, namely the former code runs also over 10 times faster than this code: {{{ test2 :: Text -> Result test2 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = X $! many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test2 #-} }}} The only difference here is the `X` wrapper, while the `runTokenParser` is defined as `runTokenParser (X !a) = runTokenParser a`. I've created sample project for it here: https://github.com/wdanilo/ghc- bug-peg-optimization/blob/master/src/Main.hs In order to run it execute `stack build --exec test`. The results are: {{{ benchmarking test0 time 420.0 μs (417.6 μs .. 422.9 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 421.0 μs (419.2 μs .. 425.3 μs) std dev 9.286 μs (4.239 μs .. 15.30 μs) variance introduced by outliers: 14% (moderately inflated) benchmarking test1 time 6.069 ms (6.022 ms .. 6.123 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.065 ms (6.037 ms .. 6.117 ms) std dev 114.5 μs (74.30 μs .. 183.4 μs) benchmarking test2 time 6.070 ms (6.007 ms .. 6.137 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.067 ms (6.039 ms .. 6.129 ms) std dev 123.0 μs (63.88 μs .. 220.1 μs) benchmarking native time 428.0 μs (421.5 μs .. 437.4 μs) 0.998 R² (0.995 R² .. 1.000 R²) mean 427.1 μs (424.1 μs .. 434.7 μs) std dev 15.18 μs (5.678 μs .. 26.26 μs) variance introduced by outliers: 29% (moderately inflated) }}} Where "native" is just standard `Text.takeWhile ...`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15519> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15687: Type synonym unused binds no warning?
by GHC 20 Nov '18

20 Nov '18

#15687: Type synonym unused binds no warning? -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Parser) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was taken aback this was accepted {{{#!hs type Silly a b = Maybe b x :: Silly Int Bool x = Just True y :: Silly Char Bool y = Just False z = x == y -- returns False }}} What's with the `a` in `Silly`'s decl? That's not a phantom type. It's ignored and thrown away. So `x` and `y` are the same type, and can be compare for equality. I expected a rule: all tyvars in the `type`'s head must appear on rhs. Or at least a warning there was something silly. I tried `-Wall, -fwarn- unused-binds`, `-Wunused-type-patterns`. I was just checking up on [https://github.com/ghc-proposals/ghc- proposals/pull/173#issuecomment-424980779 a remark] that type synonyms are at the type level like implicit bidirectional pattern synonyms. For those, all vars must appear on both sides. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15674: GADT's displayed type is misleading
by GHC 20 Nov '18

20 Nov '18

#15674: GADT's displayed type is misleading -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi's `:t` alleges these three data constructors have the same type `:: Int -> T Int` (modulo name of the type constructor): {{{#!hs data DG a where MkDG :: Int -> DG Int MkDG2 :: (a ~ Int) => a -> DG a data family DF a data instance DF Int where MkDF :: Int -> DF Int }}} I tried switching on verbosity flags, but to no avail: `-fprint-explicit- foralls, -fprint-equality-relations`, and a few others. The `DG` constructors are GADTs, the `DF` constructor is not. So it's not hard to see different type-level behaviour: {{{#!hs f (MkDF x) = x -- accepted without a signature -- f :: DF Int -> Int -- inferred signature, or you can spec it -- f :: DF a -> a -- rejected: signature is too general/ -- a is a rigid type variable g (MkDG x) = x -- } without a signature, rejected g (MkDG2 x) = x -- } "untouchable" type (Note) -- g :: DG Int -> Int -- } g accepted with either sig -- g :: DG a -> a -- } ?but MkDG doesn't return DG a, allegedly }}} '''Note:''' at least the error message re `MkDG2` does show its type as `:: (forall a). (a ~ Int) => DG a -> a`. But doggedly `MkDG :: Int -> DG Int`. "Untouchable" error messages are a fertile source of questions on StackOverflow. The message does say `Possible fix: add a type signature for 'g'`, but gives no clue what the signature might be. If you've imported these data constructors from a library, such that you can't (easily) see they're GADTs, couldn't `:t` give you better help to show what's going on? Or should one of the verbosity flags already do this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8