1. 17 Dec, 2019 1 commit
    • Krzysztof Gogolewski's avatar
      Use "OrCoVar" functions less · 75355fde
      Krzysztof Gogolewski authored
      As described in #17291, we'd like to separate coercions and expressions
      in a more robust fashion.
      This is a small step in this direction.
      
      - `mkLocalId` now panicks on a covar.
        Calls where this was not the case were changed to `mkLocalIdOrCoVar`.
      - Don't use "OrCoVar" functions in places where we know the type is
        not a coercion.
      75355fde
  2. 30 Nov, 2019 1 commit
  3. 28 Nov, 2019 1 commit
  4. 24 Nov, 2019 1 commit
  5. 05 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Check EmptyCase by simply adding a non-void constraint · 1593debf
      Sebastian Graf authored
      We can handle non-void constraints since !1733, so we can now express
      the strictness of `-XEmptyCase` just by adding a non-void constraint
      to the initial Uncovered set.
      
      For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }`
      is non-empty. This is conceptually simpler than the plan outlined in
       #17376, because it talks to the oracle directly.
      
      In order for this patch to pass the testsuite, I had to fix handling of
      newtypes in the pattern-match checker (#17248).
      
      Since we use a different code path (well, the main code path) for
      `-XEmptyCase` now, we apparently also handle #13717 correctly.
      There's also some dead code that we can get rid off now.
      
      `provideEvidence` has been updated to provide output more in line with
      the old logic, which used `inhabitationCandidates` under the hood.
      
      A consequence of the shift away from the `UncoveredPatterns` type is
      that we don't report reduced type families for empty case matches,
      because the pretty printer is pure and only knows the match variable's
      type.
      
      Fixes #13717, #17248, #17386
      1593debf
  6. 28 Oct, 2019 1 commit
    • Sebastian Graf's avatar
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances... · e951f219
      Sebastian Graf authored
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints
      
      In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
      for `Outputable` instances of AST data types means users can provide orphan
      `Outputable` instances for passes other than `GhcPass`.
      
      Type inference doesn't currently to suffer, and Richard gave an example
      in #17304 that shows how rare a case would be where the slightly worse
      type inference would matter.
      
      So I went ahead with the refactoring, attempting to fix #17304.
      e951f219
  7. 16 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
      
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
      
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
      
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      
      No work other than module splitting is in this patch.
      
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
      51fad9e6
  8. 03 Oct, 2019 1 commit
  9. 20 Sep, 2019 1 commit
  10. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  11. 05 Jul, 2019 1 commit
  12. 20 Jun, 2019 1 commit
    • Simon Peyton Jones's avatar
      Fix typechecking of partial type signatures · 48fb3482
      Simon Peyton Jones authored
      Partial type sigs had grown hair.  tcHsParialSigType was
      doing lots of unnecessary work, and tcInstSig was cloning it
      unnecessarily -- and the result didn't even work: #16728.
      
      This patch cleans it all up, described by TcHsType
        Note [Checking parital type signatures]
      
      I basically just deleted code... but very carefully!
      
      Some refactoring along the way
      
      * Distinguish more explicintly between "anonymous" wildcards "_"
        and "named" wildcards "_a".  I changed the names of a number
        of functions to make this distinction much more apparent.
      
      The patch also revealed that the code in `TcExpr`
      that implements the special typing rule for `($)` was wrong.
      It called `getRuntimeRep` in a situation where where was no
      particular reason to suppose that the thing had kind `TYPE r`.
      
      This caused a crash in typecheck/should_run/T10846.
      
      The fix was easy, and actually simplifies the code in `TcExpr`
      quite a bit.  Hooray.
      48fb3482
  13. 20 Mar, 2019 1 commit
  14. 16 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Improve error recovery in the typechecker · 4927117c
      Simon Peyton Jones authored
      Issue #16418 showed that we were carrying on too eagerly after a bogus
      type signature was identified (a bad telescope in fact), leading to a
      subsequent crash.
      
      This led me in to a maze of twisty little passages in the typechecker's
      error recovery, and I ended up doing some refactoring in TcRnMonad.
      Some specfifics
      
      * TcRnMonad.try_m is now called attemptM.
      
      * I switched the order of the result pair in tryTc,
        to make it consistent with other similar functions.
      
      * The actual exception used in the Tc monad is irrelevant so,
        to avoid polluting type signatures, I made tcTryM, a simple
        wrapper around tryM, and used it.
      
      The more important changes are in
      
      * TcSimplify.captureTopConstraints, where we should have been calling
        simplifyTop rather than reportUnsolved, so that levity defaulting
        takes place properly.
      
      * TcUnify.emitResidualTvConstraint, where we need to set the correct
        status for a new implication constraint.  (Previously we ended up
        with an Insoluble constraint wrapped in an Unsolved implication,
        which meant that insolubleWC gave the wrong answer.
      4927117c
  15. 15 Mar, 2019 1 commit
  16. 08 Feb, 2019 1 commit
  17. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  18. 24 Nov, 2018 1 commit
  19. 04 Oct, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fail fast on pattern synonyms · 9ebfa03d
      Simon Peyton Jones authored
      We were recovering too eagerly from errors in pattern-synonym
      type inference, leading to a cascade of confusing follow up errors
      (Trac #15685, #15692).
      
      The underlying issue is that a pattern synonym should have a closed,
      fixed type, with no unification variables in it.  But it wasn't!
      
      Fixing this made me change the interface to simplifyInfer slightly.
      Instead of /emitting/ a residual implication constraint, it
      now /returns/ it, so that the caller can decide what to do.
      9ebfa03d
  20. 17 Aug, 2018 1 commit
    • Joachim Breitner's avatar
      Rename SigTv to TyVarTv (#15480) · a50244c6
      Joachim Breitner authored
      because since #15050, these are no longer used in pattern SIGnatures,
      but still in other places where meta-variables should only be unified
      with TYpe VARiables.
      
      I also found mentions of `SigTv` in parts of the renamer and desugarer
      that do not seem to directly relate to `SigTv` as used in the type
      checker, but rather to uses of `forall a.` in type signatures. I renamed
      these to `ScopedTv`.
      
      Differential Revision: https://phabricator.haskell.org/D5074
      a50244c6
  21. 25 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix error recovery for pattern synonyms · 2896082e
      Simon Peyton Jones authored
      As Trac #15289 showed, we were carrying on after a type error
      in a pattern synonym, and then crashing.  This patch improves
      error handling for pattern synonyms.
      
      I also moved a bit of code from TcBinds into TcPatSyn, which
      helpfully narrows the API.
      2896082e
  22. 22 Jun, 2018 1 commit
  23. 15 Jun, 2018 2 commits
    • Simon Peyton Jones's avatar
      Make better "fake tycons" in error recovery · 2f6069cc
      Simon Peyton Jones authored
      Consider (Trac #15215)
        data T a = MkT ...
        data S a = ...T...MkT....
      
      If there is an error in the definition of 'T' we add a
      "fake type constructor" to the type environment, so that we
      can continue to typecheck 'S'.  But we /were not/ adding
      a fake anything for 'MkT' and so there was an internal
      error when we met 'MkT' in the body of 'S'.
      
      The fix is to add fake tycons for all the 'implicits' of 'T'.
      This is done by mk_fake_tc in TcTyClsDecls.checkValidTyCl,
      which now returns a /list/ of TyCons rather than just one.
      
      On the way I did some refactoring:
      
      * Rename TcTyDecls.tcAddImplicits to tcAddTyConsToGblEnv
        and make it /include/ the TyCons themeselves as well
        as their implicits
      
      * Some incidental refactoring about tcRecSelBinds. The main
        thing is that I've avoided creating a HsValBinds that we
        immediately decompose.  That meant moving some deck chairs
        around.
      
      NB: The new error message for the regression test T15215
      has the opaque error "Illegal constraint in a type:", flagged
      in Trac #14845.  But that's the fault of the latter ticket.
      The fix here not to blame.
      2f6069cc
    • Simon Peyton Jones's avatar
      Fix the bind-recovery type · 807ab222
      Simon Peyton Jones authored
      This patch uses (forall (a::*). a) for the type to
      use when recovering from an error in a binding.
      
      Previously (Trac #15276) we had (forall r (a :: TYPE r). a),
      which is ill-kinded.
      
      It's quite hard to provoke an error arising from this, because
      it only happens in programs that have a type error anyway,
      but in a subequent patch I make typeKind fall over if it returns
      an ill-scoped kind, and that makes ghci/scripts/T13202 crash
      without this fix.
      807ab222
  24. 03 Jun, 2018 1 commit
  25. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  26. 27 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG : complete for balance of hsSyn AST · c3823cba
      Alan Zimmerman authored
      Summary:
      - remove PostRn/PostTc fields
      - remove the HsVect In/Out distinction for Type, Class and Instance
      - remove PlaceHolder in favour of NoExt
      - Simplify OutputableX constraint
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4625
      c3823cba
  27. 13 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  28. 09 Apr, 2018 1 commit
  29. 07 Apr, 2018 1 commit
  30. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
      
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      TcErrors.
      
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
      
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
      
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  31. 02 Mar, 2018 1 commit
    • shlevy's avatar
      Make cost centre symbol names deterministic. · d8e47a2e
      shlevy authored
      Previously, non-CAF cost centre symbol names contained a unique,
      leading to non-deterministic object files which, among other issues,
      can lead to an inconsistency causing linking failure when using cached
      builds sourced from multiple machines, such as with nix. Now, each
      cost centre symbol is annotated with the type of cost centre it
      is (CAF, expression annotation, declaration annotation, or HPC) and,
      when a single module has multiple cost centres with the same name and
      type, a 0-based index.
      
      Reviewers: bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: niteria, simonmar, RyanGlScott, osa1, rwbarton, thomie, carter
      
      GHC Trac Issues: #4012, #12935
      
      Differential Revision: https://phabricator.haskell.org/D4388
      d8e47a2e
  32. 21 Dec, 2017 1 commit
  33. 19 Dec, 2017 1 commit
  34. 11 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix SigTvs at the kind level · 8361b2c5
      Simon Peyton Jones authored
      This patch fixes two bugs in the treatment of SigTvs at the
      kind level:
      
      - We should always generalise them, never default them
        (Trac #14555, #14563)
      
      - We should check if they get unified with each other
        (Trac #11203)
      
      Both are described in TcHsType
         Note [Kind generalisation and SigTvs]
      8361b2c5
  35. 27 Nov, 2017 1 commit
  36. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314
  37. 11 Nov, 2017 1 commit
  38. 08 Nov, 2017 1 commit
  39. 07 Nov, 2017 1 commit