February 2019 - ghc-tickets

[GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer
by GHC 09 Feb '19

09 Feb '19

#16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.4.4 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our local environment allows running Haskell programs under ThreadSanitizer. Even though the GHC runtime and compiled Haskell code are not instrumented, ThreadSanitizer still found a bug through interceptor instrumentation. I'll try to minimize the case and create a reproducer, but in case somebody wants to look at this with just the report, here it is (mildly massaged to remove irrelevant addresses): {{{ ================== WARNING: ThreadSanitizer: data race (pid=2367) Write of size 1 at 0x55986a3e4f10 by thread T1: #0 pthread_mutex_destroy llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1245:3 #1 itimer_thread_func vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:152:5 Previous atomic read of size 1 at 0x55986a3e4f10 by main thread: #0 pthread_mutex_lock llvm/compiler- rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:4097:3 #1 startTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:184:5 #2 exitTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:206 #3 __libc_start_main <null> (libc.so.6+0x38bbc) Location is global 'mutex' of size 40 at 0x55986a3e4f10 Thread T1 'ghc_ticker' (tid=2369, running) created by main thread at: #0 pthread_create llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:980:3 #1 initTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:171:11 #2 __libc_start_main <null> (libc.so.6+0x38bbc) SUMMARY: ThreadSanitizer: data race vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:152:5 in itimer_thread_func ================== ================== WARNING: ThreadSanitizer: data race (pid=2367) Write of size 8 at 0x55986a3e4ee0 by thread T1: #0 pthread_cond_destroy llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1216:3 #1 itimer_thread_func vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:153:5 Previous read of size 8 at 0x55986a3e4ee0 by main thread (mutexes: write M146179626018688784): #0 pthread_cond_signal llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:1202:3 #1 signalCondition vendor_src/v8_4_4/rts/posix/OSThreads.c:111:11 #2 __libc_start_main <null> (libc.so.6+0x38bbc) Location is global 'start_cond' of size 48 at 0x55986a3e4ee0 Mutex M146179626018688784 is already destroyed. Thread T1 'ghc_ticker' (tid=2369, running) created by main thread at: #0 pthread_create llvm/compiler- rt/lib/tsan/rtl/tsan_interceptors.cc:980:3 #1 initTicker vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:171:11 #2 __libc_start_main <null> (libc.so.6+0x38bbc) SUMMARY: ThreadSanitizer: data race vendor_src/v8_4_4/rts/posix/itimer/Pthread.c:153:5 in itimer_thread_func ================== ThreadSanitizer: reported 2 warnings }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64]
by GHC 09 Feb '19

09 Feb '19

#16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- On current HEAD ghc fails build on powerpc32: {{{ $ ./configure --target=powerpc-unknown-linux-gnu $ make ... "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181223 for powerpc-unknown-linux): getRegister(ppc) I64[I32[BaseReg + 812] + 64] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/nativeGen/PPC/CodeGen.hs:693:24 in ghc:PPC.CodeGen }}} {{{ $ inplace/bin/ghc-stage1 --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","powerpc-unknown-linux-gnu-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","powerpc-unknown-linux-gnu-gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","powerpc-unknown-linux-gnu-ld.gold") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","powerpc-unknown-linux-gnu-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","powerpc-unknown-linux-gnu-ranlib") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","YES") ,("target os","OSLinux") ,("target arch","ArchPPC") ,("target word size","4") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.7.20181223") ,("Project Git commit id","bd8a6bde2ee73e599800137b9428a401bc105985") ,("Booter version","8.4.4") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","powerpc-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p debug_p") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/slyfox/dev/git/ghc-ppc/inplace/lib") ,("Global Package DB","/home/slyfox/dev/git/ghc- ppc/inplace/lib/package.conf.d") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15336: ./System/IO.hs accidentally overridden when running ghci
by GHC 08 Feb '19

08 Feb '19

#15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior. {{{ % mkdir System % touch System/IO.hs % ghci GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:19: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:43: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. <interactive>:1:60: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:99: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:123: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. <interactive>:1:140: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:179: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. <interactive>:1:203: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. <interactive>:1:220: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9370: large blowup in memory usage and time when doing parallel build of xmlhtml package
by GHC 08 Feb '19

08 Feb '19

#9370: large blowup in memory usage and time when doing parallel build of xmlhtml package -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've observed a blowup in ghc memory usage when invoked with parallel build flags. to reproduce {{{ cabal get xmlhtml-0.2.3.2 cabal install xmlhtml-0.2.3.2 --only-dependencies cd xmlhtml-0.2.3.2 }}} then {{{ cabal clean ; cabal configure --ghc-options="-j4" ; time cabal build -j4 -v3 }}} will take quite a while and use > 1gb of ram whereas {{{ cabal clean ; cabal configure --ghc-options="-j1 ; time cabal build -j1 -v3 }}} will use < 150mb of ram. Based upon the output of cabal build -j4 -v3, it looks like the parallel build is spending a lottt more time in the simplifier passes. I'm not sure what changes between the parallel and sequential builds to change this. I'll try to dig into this more in a few days, but recording this problem now before i forget. (though of course any insights would be appreciated) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes
by GHC 08 Feb '19

08 Feb '19

#8635: GHC optimisation flag ignored when importing a local module with derived type classes ------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Given Foo.hs and Bar.hs: {{{ module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16259: Hadrian does not work with a cabal v2-installed "happy"
by GHC 08 Feb '19

08 Feb '19

#16259: Hadrian does not work with a cabal v2-installed "happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I installed happy with: {{{ cabal new-install --symlink-bindir=~/Software/ghc-8.6.3/bin happy }}} where `~/Software/ghc-8.6.3/bin` is in my PATH. When I run `hadrian/build.sh -c --flavour=devel2` I get the following error: {{{ happy: /home/roland/.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9 /HappyTemplate-arrays-coerce: openFile: does not exist (No such file or directory) }}} It's correct, I don't have a file `.cabal/share/x86_64-linux- ghc-8.6.3/happy-1.19.9/HappyTemplate-arrays-coerce`. However I have a file `.cabal/store/ghc-8.6.3/happy-1.19.9-84db80555b9a8f54be2ca475bccbc751401ffbff30194c8c26d08a002a665431/share /HappyTemplate-arrays-coerce`. If I do an old-fashioned `cabal v1-install happy`, it creates the missing file `.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9/HappyTemplate- arrays-coerce` and Hadrian is now able to build! Hadrian should not depend on old-style cabal installs! Program versions: {{{ roland@goms:~/Projekte/ghc$ cat /etc/issue Debian GNU/Linux 9 \n \l roland@goms:~/Projekte/ghc$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 roland@goms:~/Projekte/ghc$ hadrian/build.sh --version Up to date Shake build system, version 0.17.4 roland@goms:~/Projekte/ghc$ happy --version Happy Version 1.19.9 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. This program is free software; you can redistribute it and/or modify it under the terms given in the file 'LICENSE' distributed with the Happy sources. roland@goms:~/Projekte/ghc$ cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11822: Pattern match checker exceeded (2000000) iterations
by GHC 07 Feb '19

07 Feb '19

#11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- graphviz seems a nice benchmark (not too large, few dependencies) that highlights compiler performance problems on "trivial" source code (cf. https://hackage.haskell.org/package/graphviz-2999.18.0.2/docs/src /Data-GraphViz-Attributes-Complete.html#sameAttribute) Compilation of Compiling Data.GraphViz.Attributes.Colors.X11 and Data.GraphViz.Attributes.Values takes >= 1 second each, and the following happens: {{{ cabal install graphviz-2999.18.0.2 --allow-newer ... [17 of 31] Compiling Data.GraphViz.Attributes.Complete ( Data/GraphViz/Attributes/Complete.hs, dist/dist-sandbox- e6f2c124/build/Data/GraphViz/Attributes/Complete.o ) Data/GraphViz/Attributes/Complete.hs:1013:1: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘sameAttribute’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I do welcome that ghc emits this warning - I expect you want its occurence to be reported as a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #16285: Hadrian fails to run the testsuite.
by GHC 07 Feb '19

07 Feb '19

#16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- This is on windows with a tree based on the commit below. {{{ commit a5373c1f (master) Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Jan 16 16:34:24 2019 +0000 Fix bogus worker for newtypes }}} Output as follows. {{{ $ hadrian/build.bat -c -j8 --flavour=quick test Up to date Up to date hadrian: Encountered missing dependencies: libiserv ==8.7 shakeArgsWith 0.001s 0% Function shake 0.010s 0% Database read 0.516s 13% === Database compression 0.074s 1% With database 0.018s 0% Running rules 3.280s 84% ========================= Total 3.900s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Rules/Test.hs:90:5-17: * Depends on: _build/stage1/lib/bin/ghc-iserv.exe at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _build/stage1/utils/iserv/setup-config * Raised the exception: ExitFailure 1 }}} Regular build with hadrian works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0
by GHC 07 Feb '19

07 Feb '19

#15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all- packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package- id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64 -linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc- std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc- Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion- file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe Exit code: 1 Stderr: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180617 for x86_64-unknown-linux): Can't use Natural in base }}} We noticed this in hadrian land (in [https://github.com/snowleopard/hadrian/issues/499 this PR] and [https://github.com/snowleopard/hadrian/issues/629] and noticed that this happens: - with 8.4.2 as the boot compiler but not 8.2.2 - with integer-simple as the integer library - only with the quickest flavour (or more generally when we build GHC.Natural with -O0) Some optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef. The full build log is available [https://travis- ci.org/snowleopard/hadrian/jobs/393259151#L4209 here], anchored to where the error appears. An example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer- simple -j4`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16082: Sort out treatment of underscores in types
by GHC 07 Feb '19

07 Feb '19

#16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- I can count 4 different meanings for underscores in Haskell programs: 1. A pattern for which we don't care to write a name. (This dates back to antiquity.) Example: {{{#!hs const x _ = x }}} 2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.) Example: {{{#!hs plus x y = x + _ }}} 3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.) Example: {{{#!hs plus :: forall a. Num a => a -> a -> _ plus x y = x + y }}} 4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.) Example: {{{#!hs x = const @_ @Bool 'x' -- the _ is inferred to mean Char }}} Problems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types). This is a mess, for at least three reasons: A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this. B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy. C. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad. This ticket is to track resolutions to these problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5