summaryrefslogtreecommitdiff
path: root/testsuite/tests
Commit message (Collapse)AuthorAgeFilesLines
* A collection of type-inference refactorings.Simon Peyton Jones2016-10-2155-225/+264
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a raft of useful tidy-ups in the type checker. I've been meaning to do this for some time, and finally made time to do it en route to ICFP. 1. Modify TcType.ExpType to make a distinct data type, InferResult for the Infer case, and consequential refactoring. 2. Define a new function TcUnify.fillInferResult, to fill in an InferResult. It uses TcMType.promoteTcType to promote the type to the level of the InferResult. See TcMType Note [Promoting a type] This refactoring is in preparation for an improvement to typechecking pattern bindings, coming next. I flirted with an elaborate scheme to give better higher rank inference, but it was just too complicated. See TcMType Note [Promotion and higher rank types] 3. Add to InferResult a new field ir_inst :: Bool to say whether or not the type used to fill in the InferResult should be deeply instantiated. See TcUnify Note [Deep instantiation of InferResult]. 4. Add a TcLevel to SkolemTvs. This will be useful generally - it's a fast way to see if the type variable escapes when floating (not used yet) - it provides a good consistency check when updating a unification variable (TcMType.writeMetaTyVarRef, the level_check_ok check) I originally had another reason (related to the flirting in (2), but I left it in because it seems like a step in the right direction. 5. Reduce and simplify the plethora of uExpType, tcSubType and related functions in TcUnify. It was such an opaque mess and it's still not great, but it's better. 6. Simplify the uo_expected field of TypeEqOrigin. Richard had generatlised it to a ExpType, but it was almost always a Check type. Now it's back to being a plain TcType which is much, much easier. 7. Improve error messages by refraining from skolemisation when it's clear that there's an error: see TcUnify Note [Don't skolemise unnecessarily] 8. Type.isPiTy and isForAllTy seem to be missing a coreView check, so I added it 9. Kill off tcs_used_tcvs. Its purpose is to track the givens used by wanted constraints. For dictionaries etc we do that via the free vars of the /bindings/ in the implication constraint ic_binds. But for coercions we just do update-in-place in the type, rather than generating a binding. So we need something analogous to bindings, to track what coercions we have added. That was the purpose of tcs_used_tcvs. But it only worked for a /single/ iteration, whereas we may have multiple iterations of solving an implication. Look at (the old) 'setImplicationStatus'. If the constraint is unsolved, it just drops the used_tvs on the floor. If it becomes solved next time round, we'll pick up coercions used in that round, but ignore ones used in the first round. There was an outright bug. Result = (potentialy) bogus unused-constraint errors. Constructing a case where this actually happens seems quite trick so I did not do so. Solution: expand EvBindsVar to include the (free vars of the) coercions, so that the coercions are tracked in essentially the same way as the bindings. This turned out to be much simpler. Less code, more correct. 10. Make the ic_binds field in an implication have type ic_binds :: EvBindsVar instead of (as previously) ic_binds :: Maybe EvBindsVar This is notably simpler, and faster to use -- less testing of the Maybe. But in the occaional situation where we don't have anywhere to put the bindings, the belt-and-braces error check is lost. So I put it back as an ASSERT in 'setImplicationStatus' (see the use of 'termEvidenceAllowed') All these changes led to quite bit of error message wibbling
* Test Trac #12507Simon Peyton Jones2016-10-212-0/+17
| | | | | | This is now working apparently. It relates to when a polymorphic function gets instantiated, under some implicit paramter bindings.
* Refactor typechecking of pattern bindingsSimon Peyton Jones2016-10-213-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a regression introduced, post 8.0.1, by this major commit: commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:49:27 2016 +0100 Improve typechecking of let-bindings This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. I didn't get the typechecking of pattern bindings right, leading to Trac #12427. In fixing this I found that this program doesn't work: data T where T :: a -> ((forall b. [b]->[b]) -> Int) -> T h1 y = case y of T _ v -> v Works in 7.10, but not in 8.0.1. There's a happy ending. I found a way to fix this, and improve pattern bindings too. Not only does this fix #12427, but it also allows In particular,we now can accept data T where MkT :: a -> Int -> T ... let { MkT _ q = t } in ... Previously this elicited "my head exploded" but it's really fine since q::Int. The approach is described in detail in TcBinds Note [Typechecking pattern bindings] Super cool. And not even a big patch!
* Mark previously failing backpack tests as passing, with correct output.Edward Z. Yang2016-10-2011-35/+119
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Support constraint synonym implementations of abstract classes.Edward Z. Yang2016-10-205-0/+91
| | | | | | | | | | | | | | Summary: Test Plan: validate Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2595 GHC Trac Issues: #12679
* New story for abstract data types in hsig files.Edward Z. Yang2016-10-2017-1/+261
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In the old implementation of hsig files, we directly reused the implementation of abstract data types from hs-boot files. However, this was WRONG. Consider the following program (an abridged version of bkpfail24): {-# LANGUAGE GADTs #-} unit p where signature H1 where data T signature H2 where data T module M where import qualified H1 import qualified H2 f :: H1.T ~ H2.T => a -> b f x = x Prior to this patch, M was accepted, because the type inference engine concluded that H1.T ~ H2.T does not hold (indeed, *presently*, it does not). However, if we subsequently instantiate p with the same module for H1 and H2, H1.T ~ H2.T does hold! Unsound. The key is that abstract types from signatures need to be treated like *skolem variables*, since you can interpret a Backpack unit as a record which is universally quantified over all of its abstract types, as such (with some fake syntax for structural records): p :: forall t1 t2. { f :: t1 ~ t2 => a -> b } p = { f = \x -> x } -- ill-typed Clearly t1 ~ t2 is not solvable inside p, and also clearly it could be true at some point in the future, so we better not treat the lambda expression after f as inaccessible. The fix seems to be simple: do NOT eagerly fail when trying to simplify the given constraints. Instead, treat H1.T ~ H2.T as an irreducible constraint (rather than an insoluble one); this causes GHC to treat f as accessible--now we will typecheck the rest of the function (and correctly fail). Per the OutsideIn(X) paper, it's always sound to fail less when simplifying givens. We do NOT apply this fix to hs-boot files, where abstract data is also guaranteed to be nominally distinct (since it can't be implemented via a reexport or a type synonym.) This is a somewhat unnatural state of affairs (there's no way to really interpret this in Haskell land) but no reason to change behavior. I deleted "representationally distinct abstract data", which is never used anywhere in GHC. In the process of constructing this fix, I also realized our implementation of type synonym matching against abstract data was not sufficiently restrictive. In order for a type synonym T to be well-formed type, it must be a nullary synonym (i.e., type T :: * -> *, not type T a = ...). Furthermore, since we use abstract data when defining instances, they must not have any type family applications. More details in #12680. This probably deserves some sort of short paper report. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: goldfire, simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2594
* Test for newtype with unboxed argumentSimon Peyton Jones2016-10-194-6/+26
| | | | | | | | | Newtypes cannot (currently) have an unboxed argument type. But Trac #12729 showed that this was only being checked for newtypes in H98 syntax; in GADT snytax they were let through. This patch moves the test to checkValidDataCon, where it properly belongs.
* Compute export hash based on ALL transitive orphan modules.Edward Z. Yang2016-10-1813-0/+88
| | | | | | | | | | | | | | | | | | | Previously we pruned out orphan modules from external packages but this was wrong. Fixes #12733 (which has more discussion.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2610 GHC Trac Issues: #12733
* fixup! Add option to not retain CAFs to the linker APISimon Marlow2016-10-181-1/+1
|
* Track dep_finsts in exports hash, as it affects downstream deps.Edward Z. Yang2016-10-178-0/+53
| | | | | | | | | | | | | | | | | | | | Summary: I also added some more comments about the orphan and family instance hashing business. Fixes #12723. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2607 GHC Trac Issues: #12723
* testsuite: Mark T7037 as broken on WindowsBen Gamari2016-10-171-1/+2
| | | | Due to #12725.
* testsuite: Eliminate unnecessary compile_timeout_multiplierBen Gamari2016-10-171-1/+1
| | | | | | | | | | | | | | | | tc266 was failing intermittently on Windows due to a very small compile_timeout_multiplier. This test was added in e907e1f12f4dedc0ec13c7a501c8810bcfc03583 which doesn't appear to have any timng dependence, so I see no reason to retain the multiplier at all. Test Plan: Validate Reviewers: ezyang, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2601
* testsuite: Mark T9405 as broken on WindowsBen Gamari2016-10-172-2/+4
| | | | There seems to be a runtime system bug here, as described in #12714.
* testsuite: Mark T10858 as broken on WindowsBen Gamari2016-10-171-1/+2
| | | | | | | | Strangely the allocation numbers on Windows differ significantly from those on Linux. Usually I would just update the number, but I would really like to understand why this is the case. This is a rather large deviation in the compilation of a program which really shouldn't have any appreciable platform dependence.
* testsuite: Mark break011 as brokenBen Gamari2016-10-171-1/+4
| | | | See #12712.
* Comments onlySimon Peyton Jones2016-10-171-0/+13
|
* Add more variants of T3064 (in comments)Simon Peyton Jones2016-10-171-10/+13
|
* Test Trac #12681Simon Peyton Jones2016-10-174-0/+11
|
* Fix wrapping order in matchExpectedConTySimon Peyton Jones2016-10-172-0/+10
| | | | | | | | The wrappers in matchExpectedConTy were being composed back to front, resulting in a Core Lint error. Yikes! This has been here a long time. Fixes Trac #12676.
* Correct order of existentials in pattern synonymsSimon Peyton Jones2016-10-172-0/+63
| | | | | | | | | Trac #12698 exposed a nasty bug in the typechecking for pattern synonmys: the existential type variables weren't being put in properly-scoped order. For some reason TcPatSyn.tcCollectEx was colleting them as a set, not as a list! Easily fixed.
* Fix Show derivation in the presence of RebindableSyntax/OverloadedStringsRyan Scott2016-10-152-0/+16
| | | | | | | | | | | | | | | | | | | | Summary: To fix this issue, we simply disable `RebindableSyntax` whenever we rename the code generated from a deriving clause. Fixes #12688. Test Plan: make test TEST=T12688 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2591 GHC Trac Issues: #12688
* Disable T-signals-child test on single-threaded runtimeMichael Snoyman2016-10-142-3/+10
| | | | | | | | | | | | | | | | | As identified by Joachim, this test broke the Travis build. It appears that this is due to the usage of the single-threaded runtime there. I've confirmed that this fix causes the Travis build to pass: https://travis-ci.org/snoyberg/ghc/builds/167368988. Test Plan: Confirm tests now pass Reviewers: austin, nomeata, bgamari Reviewed By: nomeata, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2593
* Check for empty entity string in "prim" foreign importsSylvain HENRY2016-10-142-2/+2
| | | | | | | | | | | | | | | | | | | Foreign imports with "prim" convention require a valid symbol identifier (see linked issue). We check this. Fix line too long Test Plan: Validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2563 GHC Trac Issues: #12355
* Make error when deriving an instance for a typeclass less misleadingRyan Scott2016-10-146-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, when you attempted to derive an instance for a typeclass, e.g., ``` class C1 (a :: Constraint) where class C2 where deriving instance C1 C2 ``` GHC would complain that `C2`'s data constructors aren't in scope. But that makes no sense, since typeclasses don't have constructors! By refining the checks that GHC performs when deriving, we can make the error message a little more sensible. This also cleans up a related `DeriveAnyClass` infelicity. Before, you wouldn't have been able to compile code like this: ``` import System.IO (Handle) class C a deriving instance C Handle ``` Since GHC was requiring that all data constructors of `Handle` be in scope. But `DeriveAnyClass` doesn't even generate code that mentions any data constructors, so this requirement is silly! Fixes #11509. Test Plan: make test TEST=T11509 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2558 GHC Trac Issues: #11509
* Clean up handling of known-key Names in interface filesBen Gamari2016-10-133-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415
* Cabal submodule update.Edward Z. Yang2016-10-131-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Further improve error handling in TcRn monadSimon Peyton Jones2016-10-133-0/+15
| | | | | | | | | | | This patch builds on the one for Trac #12124, by dealing properly with out-of-scope "hole" errors. This fixes Trac #12529. The hard error coming from visible type application is still there, but the out-of-scope error is no longer suppressed. (Arguably the VTA message should be suppressed somehow, but that's a battle for another day.)
* Add test for #12456Ryan Scott2016-10-122-0/+4
| | | | | Commit f352e5cd7bb629fe0ca3b913bfbe7bee43d62f3a fixed #12456. Let's add a test to make sure it stays fixed.
* Add test for #12589Ryan Scott2016-10-123-0/+16
| | | | | Commit af21e38855f7d517774542b360178b05045ecb08 fixed #12598. Let's add a test to make sure it stays fixed.
* Add test for #12411Ryan Scott2016-10-123-0/+9
| | | | | The fix for #12584 also fixed the problem in #12411. Let's add a test to ensure that it stays fixed.
* testsuite: Bump T1969 allocationsBen Gamari2016-10-121-1/+2
|
* RnExpr: Actually fail if patterns found in expressionBen Gamari2016-10-125-4/+9
| | | | | | | | | | | | | | | | | | | | | This fixes #12584, where wildcard patterns were snuck into an expression, which then crashed the typechecker in TcExpr since EWildPats aren't supposed to appear in the AST after renaming. The problem was that `rnTopSpliceDecl` failed to check for errors from `rnSplice` (as done by other callers to `rnSplice`). Thanks to Shayan for reporting this! Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2539 GHC Trac Issues: #12584
* Add a broken test case for #12689Joachim Breitner2016-10-113-0/+11
| | | | | | | | A rule with a phase specification trying to match on a constructor with a wrapper will fail to match, as the wrapper will be inlined by then. The fact that it works in the other case is also mostly by accident. (Split into two test cases so that regressions with regard what works so far are caught.)
* Add test case for #12689Joachim Breitner2016-10-115-0/+64
| | | | | | | | | which test a few variants of rules involving constructors, including nullary constructors, constructors with wrappers, and unsaturated of constructors. At the moment, all the rules work as expected, despite GHC’s compile time warnings when called with -Wall.
* More tests for Trac #12522Simon Peyton Jones2016-10-105-0/+61
| | | | These ones test the variations in coment:15 of the ticket
* Improved stats for Trac #1969Simon Peyton Jones2016-10-101-1/+1
| | | | | | | | | | | | | | With my latest commits 76a5477 Move zonking out of tcFamTyPats b255ae7 Orient improvement constraints better perf has improved slightly for T1969: allocs: 733M -> 26M residency: 43M -> 41M I don't know exactly why, but hey, it's good
* Orient improvement constraints betterSimon Peyton Jones2016-10-102-0/+51
| | | | | | | | | | | | | | This patch fixes an infinite loop in the constraint solver, shown up by Trac #12522. The solution is /very/ simple: just reverse the orientation of the derived constraints arising from improvement using type-family injectivity. I'm not very proud of the fix --- it seems fragile --- but it has the very great merit of simplicity, and it works fine. See Note [Improvement orientation] in TcInteract, and some discussion on the Trac ticket.
* Rework renaming of children in export lists.Matthew Pickering2016-10-0818-12/+98
| | | | | | | | | | | | | | | | | | | | | | | | | The target of this patch is exports such as: ``` module Foo ( T(A, B, C) ) where ``` Essentially this patch makes sure that we use the correct lookup functions in order to lookup the names in parent-children export lists. This change highlighted the complexity of this small part of GHC which accounts for the scale. This change was motivated by wanting to remove the `PatternSynonym` constructor from `Parent`. As with all these things, it quickly spiraled out of control into a much larger refactor. Reviewers: simonpj, goldfire, bgamari, austin Subscribers: adamgundry, thomie Differential Revision: https://phabricator.haskell.org/D2179 GHC Trac Issues: #11970
* Update haddock.Cabal perf for Cabal update.Edward Z. Yang2016-10-081-1/+2
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Distinguish between UnitId and InstalledUnitId.Edward Z. Yang2016-10-0817-44/+52
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* The Backpack patch.Edward Z. Yang2016-10-08229-591/+2775
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements Backpack for GHC. It's a big patch but I've tried quite hard to keep things, by-in-large, self-contained. The user facing specification for Backpack can be found at: https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst A guide to the implementation can be found at: https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst Has a submodule update for Cabal, as well as a submodule update for filepath to handle more strict checking of cabal-version. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, simonmar, bgamari, goldfire Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1482
* Tc267, tests what happens if you forgot to knot-tie.Edward Z. Yang2016-10-086-0/+29
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Don't suggest deprecated flags in error messagesMartin Ceresa2016-10-075-2/+12
| | | | | | | | | | | | | | | When looking up flags, we make sure to lookup the non-deprecated flags first by ordering the list of flags. Reviewers: bgamari, austin, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2541 GHC Trac Issues: #12574
* Remove unused T12124.srderrRyan Scott2016-10-061-1/+0
| | | | This was (accidentally?) introduced in 465c6c5d15f8fb54afb78408f3a79e75e74d2cd4
* Improve error handling in TcRnMonadSimon Peyton Jones2016-10-056-15/+19
| | | | | See Note [Constraints and errors] in TcRnMonad. This patch fixes Trac #12124 in quite a neat way.
* Update Cabal submodule to latest version.Edward Z. Yang2016-10-022-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: Note that Cabal needs one more bugfix which is in PR to fix GHC bootstrapping. But the rest of the patch is ready for review. Needs a filepath submodule update because cabal check became more strict. This patch handles the abstract-ification of Version and PackageName. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2555
* testsuite: Mark test for #12355 as unbroken on Darwin.Ben Gamari2016-10-021-1/+1
| | | | | Somehow this testcase works on Darwin but not on Linux. This deserves further investigation.
* Ignore output from derefnull and divbyzero on DarwinBen Gamari2016-10-021-2/+8
| | | | | | The output contains the pid and executable path of the bash process which spawned the failing process. It doesn't seem worth the effort to cleanse this output; just ignore it.
* Mark #6132 as broken on OS XBen Gamari2016-10-021-1/+1
| | | | | | | | | | | | | | | It currently fails with, =====> T6132(normal) 1 of 1 [0, 0, 0] cd "./runghc/T6132.run" && "/Users/bgamari/ghc/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output Compile failed (exit code 1) errors were: T6132.hs:1:2: error: parse error on input ‘#!/’ *** unexpected failure for T6132(normal)
* runghc: use executeFile to run ghc process on POSIXMichael Snoyman2016-10-024-1/+122
| | | | | | | | | | | | | | | | | | | | | | | | | This means that, on POSIX systems, there will be only one ghc process used for running scripts, as opposed to the current situation of a runghc process and a ghc process. Beyond minor performance benefits of not having an extra fork and resident process, the more important impact of this is automatically getting proper signal handling. I noticed this problem myself when running runghc as PID1 inside a Docker container. I attempted to create a shim library for executeFile that would work for both POSIX and Windows, but unfortunately I ran into issues with exit codes being propagated correctly (see https://github.com/fpco/replace-process/issues/2). Therefore, this patch leaves the Windows behavior unchanged. Given that signals are a POSIX issue, this isn't too bad a trade-off. If someone has suggestions for better Windows _exec support, please let me know. Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2538
View Lorry Controller Status