- ghc-devs - Haskell.org

Separating typechecking and type error reporting in two passes?
by Joachim Breitner 30 Nov '16

30 Nov '16

Hi, the following is a rough idea that I came up with while pondering #12864, which is about better (and fewer!) error messages when the user forgot an argument to a function, or swapped their order. The current scheme of type checking and error reporting is the following (please correct me if I am wrong, I have actually done little in this area so far): The typechecker traverses the syntax tree from top to bottom. Along the way, it keeps track of the current context in terms of SDoc fragments of the form “In the second argument of…”. It generates constraints (e.g. the argument type of a function is the type of the actual argument), which it either solves, or propagate outwards as “wanted constraints”, which refer to their context, and refer to a “hole” in the program where, if this constraint gets solved later, some form of evidence gets filled in. At the end, if there are any wanted constraints left, they are reported as type errors, together with the context they are mentioned. But with -fdefer-type-errors, they are not reported, but the evidence holes are filled in with essentially calls to `error` that print the error message at runtime. The problem I see with this approach is that the type checker has to remember interesting bits about context that might possibly eventually be relevant when reporting the error. In particular, it makes it harder to report multiple related error messages at once. So I am wondering if this approach would be better: The type checker does *not* bother keeping track of context: It traverses the syntax tree, creates constraints, and unsolvable constraints get filled with “error evidence”. Basically as if -fdefer-type-errors is one. Then a second pass is done over the syntax tree. This pass does keep track of the context. Whenever it finds some error evidence, it reports it. I see the following advantages: * The type checker code gets a bit simpler and tidier. * As most compiled programs are type correct [citation needed], the type checker, but not the error reporting, is compiler-performance- critical. This might make type checking a (possibly insignificant) tad faster. * The error reporting pass can “look around” more. For example, before recursing into a pair `(e1,e2)`, it could check for the special case of `(e1 ▷ TyError Int Bool, e1 ▷ TyError Bool Int)` and report this as one error “Tuple with swapped arguments” instead of two errors. The #12864 is a more elaborate application of this. * There could even be an intermediate pass over the syntax tree between typechecking and error reporting that “transform” or “optimizes” the AST by moving type errors around, by coalescing error or other things, all with the aim of giving easier to understand error messages. * (This is getting into the area of wild dreams:) Library authors could somehow express custom error messages for certain patterns of the form If the AST now contains an application of `Library.foo` where the first argument is a type error `TyError Int Bool`, then give this particular domain-specific error message. I don’t see any disadvantages now, but there probably are some, and I would be grateful about feedback from those who actually have worked with this part of GHC before. Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 7

Testsuite and Python 3
by Ben Gamari 30 Nov '16

30 Nov '16

Hello everyone, Note that yesterday I flipped the switch in the build system to use the Python 3 interpreter by default when invoking the testsuite driver. The motivation for this is the fact that Python 2.7 is quite buggy on Windows, which resulted in spurious testsuite failures (see #12554). The question remains, however, of how much we care to preserve compatibility with Python 2. From what little I've seen so far I think it would be easier for everyone involved if we just let Python 2 pass into the sunset. Afterall, Python 3 is no less available than 2 at this point. Thoughts? Cheers, - Ben

2 1

Windows toolchain update
by lonetiger＠gmail.com 30 Nov '16

30 Nov '16

Hi Windows devs, The Windows GCC has been updated to 6.2.0 and binutils to 2.27. At some point please rebuild using these binaries. Do throw away your old toolchain cache before getting the new one: rm -rf ghc-tarballs && ./configure --enable-tarballs-autodownload The plan is to ship these versions with GHC 8.2, though binutils will likely Get another minor bump. Thanks, Tamar

1 0

Status of "Improved LLVM backend"
by Michal Terepeta 30 Nov '16

30 Nov '16

Hi all, I was wondering what’s the current status of the “Improved LLVM backend” project ( https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend ). The page mentions a few main problems, but some seem to be already fixed: 1) Using/supporting only one version of LLVM. This has been done AFAIK. 2) Prebuilt binaries to be shipped together with GHC. I can't find anything about this. Is there a ticket? Has there been any progress on this? 3) Adding support for split-objs I found a ticket about it: https://ghc.haskell.org/trac/ghc/ticket/8300 which was closed as WONTFIX in favor of split-sections. So I guess this can also be considered as done. 4) Figuring out what LLVM optimizations are useful. Again, I can seem to find anything here. Has anyone looked at this? I only found an issue about this: https://ghc.haskell.org/trac/ghc/ticket/11295 The page also mentions that the generated IR could be improved in many cases, but it doesn't link to any tickets or discussions. Is there something I could read to better understand what are the main problems? The only thing I can recall is that proc point splitting is likely to cause issues for LLVM's ability to optimize the code. (but I only found a couple of email threads about this but couldn't find any follow-ups) Thanks, Michal

2 5

[ANNOUNCE] GHC 8.0.2 release candidate 1
by Ben Gamari 29 Nov '16

29 Nov '16

Hello everyone, The GHC team is happy to (finally!) announce the first candiate of the 8.0.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at http://downloads.haskell.org/~ghc/8.0.2-rc1/ This is the first of what will hopefully be only two release candidates leading up the final 8.0.2 release. This release will fix a number bugs found in 8.0.1 including, * Interface file build determinism (#4012). * Compatibility with macOS Sierra and GCC compilers which compile position-independent executables by default * Runtime linker fixes on Windows (see #12797) * A compiler bug which resulted in undefined reference errors while compiling some packages (see #12076) * Compatability with systems which use the gold linker * A number of memory consistency bugs in the runtime system * A number of efficiency issues in the threaded runtime which manifest on larger core counts and large numbers of bound threads. * A typechecker bug which caused some programs using -XDefaultSignatures to be incorrectly accepted. * More than two-hundred other bugs. See Trac [1] for a complete listing. Unfortunately there is one known bug (#12757) which can result in runtime crashes which is still lurking in -rc1. This will be fixed in -rc2, which will be released in about a week. As always, let us know if you encounter trouble. Thanks to everyone who has contributed so far! Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id…

6 11

Levity polymorphism
by Simon Peyton Jones 29 Nov '16

29 Nov '16

Richard. I’ve made a status page for levity polymorphism. Everyone: tag levity-polymorphic tickets with “LevityPolymorphism” keyword. We really need a GHC proposal too… Simon https://ghc.haskell.org/trac/ghc/wiki/LevityPolymorphism

1 0

Making (useful subsets of) bytecode portable between targets
by Shea Levy 25 Nov '16

25 Nov '16

Hi all, I'm interested in implementing a general solution for TH during cross-compilation, which if my naive lack-of-understanding is correct will broadly involve the following three tasks: 1. Make the generation of byte code, or at least the subset needed for useful TH use, target-independent 2. Teach the external-interpreter to launch a build-native iserv when cross-compiling 3. Teach cabal to compile dependencies and modules for the build and target when cross-compiling and TH is used Of course, due to the generality of TH there will be code you can write that would be different in this approach from what you would get with a fully native compilation (e.g. due to GHC conditional compilation in the TH functions or FFI that does runtime host introspection), but since requiring a target device at build time is in many cases impractical (do you want to hook up an iPhone to your build farm?) and in some cases probably impossible (for targets without the resources to run a full GHC even if they can run GHC-compiled code) I think this is a reasonable restriction to require. My questions to the list are: * Is 1 above a pipe dream, keeping in mind that we are assuming the availability of build-native versions of all dependencies and already-compiled modules? * Any pointers for getting started with 1? * Anything I'm missing? Thanks, Shea

7 17

IRC: Logging #ghc with ircbrowse.net?
by Ben Gamari 25 Nov '16

25 Nov '16

Hello GHC developers, In the past we have relied upon Phabricator's Chatlog application to log the #ghc freenode channel. While Chatlog did its job admirably, it seems that Phacility has deprecated it with no proposed replacement. Thankfully, there appears to be no shortage of alternatives. In particular, Chris Done's ircbrowse.net seems to offer a great deal of functionality and already mirrors a number of other Haskell-related channels. Would anyone be opposed to adding #ghc to the list of channels monitored by ircbrowse.net? Cheers, - Ben

3 3

Constraint solver again
by Simon Peyton Jones 24 Nov '16

24 Nov '16

Richard, I’ve taken another run at the constraint solver. It’s on wip/spj-tc-branch3 (you’ll need a forced update). I think I can safely commit it to HEAD in the light of your earlier comments, so I’ll do that soon, but I thought I’d just give you (and other ghc-devs) a heads-up. The two main commits are below. The former is small; the latter is the main event. Simon commit 570c3181342386b5cee1862f85a8ebed7d98d712 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Nov 23 16:00:00 2016 +0000 Allow TyVars in TcTypes Up to now we've had a rule that a TyVar can't apppear in a type seen by the type checker; they should all be TcTyVars. But: a) With -XTypeInType it becomes much harder to exclude them; see Note [TcTyVars in the typechecker] in TcType. b) It's unnecessary to exculde them; instead we can just treat a TyVar just like vanillaSkolemTv. This is what was causing an ASSERT error in indexed-types/should_fail/T12041, reported in Trac #12826. That patch allows a TyVar in a TcType. The most significant change is to make Var.tcTyVarDetails return vanillaSkolemTv. In fact it already did, but (a) it was not documented, and (b) we never exploited it. Now we rely on it. commit 6e6d93b8b713339dc5f74e8f93e35d0d94014d63 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Oct 25 17:41:45 2016 +0100 Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments.

1 0

DWARF patches for 8.2
by Ben Gamari 23 Nov '16

23 Nov '16

Hello fellow DWARF enthusiasts, Tonight I finally made something of a breakthrough on the DWARF front; after finding a small logic error in one of my patches I was able to get a full stack trace into and out of Haskell using the runtime system's native stack unwinder. This is quite exciting! Recall that up until now there have been a few issues which can lead to problems with unwinding, * #11353: Unsafe foreign calls can require the NCG to make stack pointer adjustments to accomodate native calling conventions. These adjustments need to be taken into account when we generate unwinding information. * #11337: Stack fixups produced by CmmStackLayout aren't reflected in unwinding information. Essentially this was a result of the fact that our current unwinding implementation assumes that stack layout is fixed over the course of a block. * #11338: The region surrounding safe foreign calls doesn't get proper unwinding information. I've solved all three of these in my branch, which I've rebased, split up, and posted to Phabricator. The result is quite a stack of differentials, * D2740: OrdList: Add Foldable, Traversable instances Some throat-clearing. * D2735: Use newBlockId instead of newLabelC Just some refactoring. * D2737: NCGMonad: Add MonadUnique NatM instance This will come in handy later. * D2736: AsmCodeGen: Refactor worker in cmmNativeGens More refactoring I did while trying to understand the dataflow in the NCG. * D2739: CmmCommonBlockElim: Ignore CmmUnwind nodes This is a fix to what I believe is a bug which I noticed while reading through the implementation. * D2741: Generalize CmmUnwind and pass unwind information through NCG This is the bulk of the change. Here we refactor the treatment of unwinding information to provide the flexibility we will need to address the issues described above and fix #11353. Review is badly needed here. * D2742: CmmLayoutStack: Add unwind information on stack fixups Here we use the infrastructure provided in D2741 to fix #11337. * D2743: StgCmmForeign: Emit debug information for safe foreign calls Here we fix #11338 by adding unwind information to the safe foreign call prologue/epilogue code. * D2738: Cmm: Add support for undefined unwinding statements Fix unwinding information for stg_stack_underflow_frames, which we have no means of unwinding out of. For this we need to add support for unwinding declarations which tell the underwinder to "forget" about the value of a register. Reviews would be greatly appreciated. Cheers, - Ben

2 1