1. 04 Mar, 2019 1 commit
  2. 02 Mar, 2019 1 commit
  3. 01 Mar, 2019 10 commits
  4. 28 Feb, 2019 1 commit
    • Moritz Angermann's avatar
      Cleanup iserv/iserv-proxy · f838809f
      Moritz Angermann authored
      This adds trace messages that include the processes name and as such
      make debugging and following the communication easier.
      It also adds a note regarding the fwd*Call proxy-communication logic
      between the proxy and the slave.
      The proxy will now also poll for 60s to wait for the remote iserv
      to come up. (Alternatively you can start the remote process
      beforehand; and just have iserv-proxy connect to it)
  5. 27 Feb, 2019 3 commits
    • Vladislav Zavialov's avatar
      Fix intermittent hie002 failure · 2e8f6649
      Vladislav Zavialov authored
      hie002 is a performance test that used to fail unpredictably:
      	max_bytes_used Decrease from x86_64-linux-deb9-debug baseline @ HEAD~2:
      	    Expected    hie002 (normal) max_bytes_used: 1190923992.0 +/-20%
      	    Lower bound hie002 (normal) max_bytes_used:    952739193
      	    Upper bound hie002 (normal) max_bytes_used:   1429108791
      	    Actual      hie002 (normal) max_bytes_used:    726270784
      	    Deviation   hie002 (normal) max_bytes_used:        -39.0 %
      	peak_megabytes_allocated Decrease from x86_64-linux-deb9-debug baseline @ HEAD~2:
      	    Expected    hie002 (normal) peak_megabytes_allocated: 2538.0 +/-20%
      	    Lower bound hie002 (normal) peak_megabytes_allocated:   2030
      	    Upper bound hie002 (normal) peak_megabytes_allocated:   3046
      	    Actual      hie002 (normal) peak_megabytes_allocated:   1587
      	    Deviation   hie002 (normal) peak_megabytes_allocated:  -37.5 %
      	*** unexpected stat test failure for hie002(normal)
      'max_bytes_used' and 'peak_megabytes_allocated' are too unstable without careful
      control of the runtime configuration. We fix this by using a more predictable
      metric, 'bytes allocated'.
    • Peter Trommler's avatar
      RTS: Add missing memory barrier · 5c084e04
      Peter Trommler authored
      In the work stealing queue a load-load-barrier is required to ensure
      that a read of queue data cannot be reordered before a read of the
      bottom pointer into the queue.
      The added load-load-barrier ensures that the ordering of writes enforced
      at the end of `pushWSDeque` is also respected in the order of reads in
      `stealWSDeque_`. In other words, when reading `q->bottom` we want to make
      sure that we see the updates to `q->elements`.
      Fixes #13633
    • Vladislav Zavialov's avatar
      Treat kind/type variables identically, demolish FKTV · 5bc195b1
      Vladislav Zavialov authored
      Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
      Fixes Trac #16334, Trac #16315
      With this patch, scoping rules for type and kind variables have been
      unified: kind variables no longer receieve special treatment. This
      simplifies both the language and the implementation.
      User-facing changes
      * Kind variables are no longer implicitly quantified when an explicit
        forall is used:
          p ::             Proxy (a :: k)    -- still accepted
          p :: forall k a. Proxy (a :: k)    -- still accepted
          p :: forall   a. Proxy (a :: k)    -- no longer accepted
        In other words, now we adhere to the "forall-or-nothing" rule more
        Related function: RnTypes.rnImplicitBndrs
      * The -Wimplicit-kind-vars warning has been deprecated.
      * Kind variables are no longer implicitly quantified in constructor
          data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
          data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted
        Related function: RnTypes.extractRdrKindSigVars
      * Implicitly quantified kind variables are no longer put in front of
        other variables:
          f :: Proxy (a :: k) -> Proxy (b :: j)
          f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
          f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order
        This is a breaking change for users of TypeApplications. Note that
        we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
        See "Ordering of specified variables" in the User's Guide.
        Related function: RnTypes.rnImplicitBndrs
      * In type synonyms and type family equations, free variables on the RHS
        are no longer implicitly quantified unless used in an outermost kind
          type T = Just (Nothing :: Maybe a)         -- no longer accepted
          type T = Just Nothing :: Maybe (Maybe a)   -- still accepted
        The latter form is a workaround due to temporary lack of an explicit
        quantification method. Ideally, we would write something along these
          type T @a = Just (Nothing :: Maybe a)
        Related function: RnTypes.extractHsTyRdrTyVarsKindVars
      * Named wildcards in kinds are fixed (Trac #16334):
          x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)
        Related function: RnTypes.partition_nwcs
      Implementation notes
      * One of the key changes is the removal of FKTV in RnTypes:
        - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
        -                          , fktv_tys    :: [Located RdrName] }
        + type FreeKiTyVars = [Located RdrName]
        We used to keep track of type and kind variables separately, but
        now that they are on equal footing when it comes to scoping, we
        can put them in the same list.
      * extract_lty and family are no longer parametrized by TypeOrKind,
        as we now do not distinguish kind variables from type variables.
      * PatSynExPE and the related Note [Pattern synonym existentials do not scope]
        have been removed (Trac #16315). With no implicit kind quantification,
        we can no longer trigger the error.
      * reportFloatingKvs and the related Note [Free-floating kind vars]
        have been removed. With no implicit kind quantification,
        we can no longer trigger the error.
  6. 26 Feb, 2019 1 commit
  7. 25 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Fix the ghci063 test on Darwin (Trac #16201) · f320f3b2
      Vladislav Zavialov authored
      We use "touch -r" to set modification timestamps, which leads to precision loss
      on Darwin. For example,
         before: 2019-02-25 01:11:23.807627350 +0300
         after:  2019-02-25 01:11:23.807627000 +0300
      This means we can't trick GHCi into thinking the file hasn't been changed by
      restoring its old timestamp, as we cannot faithfully restore all digits.
      The solution is to nullify the insignificant digits before the first :load
  8. 24 Feb, 2019 13 commits
    • Vladislav Zavialov's avatar
      Disable fragile test cases: T14697 T5559 T3424 · 14586f5d
      Vladislav Zavialov authored
      See Trac #15072, Trac #16349, Trac #16350
    • Alexandre R. Baldé's avatar
      base: Allow fusion for zip7 and related · 9059343e
      Alexandre R. Baldé authored
      Fixes #14037.
      Metric Decrease:
      Reviewers: bgamari, simonpj, hvr
      Reviewed By: simonpj
      Subscribers: AndreasK, simonpj, osa1, dfeuer, rwbarton, carter
      GHC Trac Issues: #14037
      Differential Revision: https://phabricator.haskell.org/D5249
    • Ben Gamari's avatar
    • Vladislav Zavialov's avatar
    • Vladislav Zavialov's avatar
      User's Guide: update info on kind inference · 88970187
      Vladislav Zavialov authored
      We no longer put class variables in front,
      see "Taming the Kind Inference Monster"
      (also fix some markup issues)
    • Sebastian Graf's avatar
      Include closure header size in StgLamLift's estimations · b85068f6
      Sebastian Graf authored
      While playing around with late lambda lifting, I realised that
      StgLamLift.Analysis doesn't consider the removed closure header in its
      allocation estimations.
      That's because contrary to what I thought, the total word count returned
      by `mkVirtHeapOffsets` doesn't include the size of the closure header.
      We just add the header size manually now.
    • Ben Gamari's avatar
      gitlab-ci: Only build x86_64-deb8 and fedora27 for releases · 1059e234
      Ben Gamari authored
      These are largely redundant as they are covered by x86_64-deb9.
    • Matthew Pickering's avatar
      Exit with exit code 1 when tests unexpectedly pass · a990312e
      Matthew Pickering authored
      This was causing gitlab to not report from builds as failing. It also
      highlighted a problem with the LLVM tests where some of the external
      interpreter tests are failing.
    • Herbert Valerio Riedel's avatar
      Fix regression incorrectly advertising TH support · ee284b85
      Herbert Valerio Riedel authored
      `--supported-languages` must only advertise language extensions
      which are supported by the compiler in order for tooling such
      as Cabal relying on this signalling not to behave incorrectly.
      Fixes #16331
    • Vladislav Zavialov's avatar
      Expression/command ambiguity resolution · e61f6e35
      Vladislav Zavialov authored
      This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
      introducing a new ambiguity resolution system in the parser.
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a command:
      	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
      	proc x -> do { (stuff) }        -- 'stuff' is a command
      Until we encounter arrow syntax (-<) we don't know whether to parse
      'stuff' as an expression or a command.
      The old solution was to parse as HsExpr always, and rejig later:
      	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
      This meant polluting 'HsExpr' with command-related constructors. In
      other words, limitations of the parser were affecting the AST, and
      all other code (the renamer, the typechecker) had to deal with these
      extra constructors by panicking.
      We fix this abstraction leak by parsing into an intermediate
      representation, 'ExpCmd':
      	data ExpCmdG b where
      	  ExpG :: ExpCmdG HsExpr
      	  CmdG :: ExpCmdG HsCmd
      	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
      	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
      	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
      	checkExp f = f ExpG  -- interpret as an expression
      	checkCmd f = f CmdG  -- interpret as a command
      See Note [Ambiguous syntactic categories] for details.
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/command ambiguity.
      Future work: apply the same principles to the expression/pattern
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      See Note [Function types] in TyCoRep.
      There are lots of consequences
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      Other minor stuff
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
    • Simon Peyton Jones's avatar
      Remove bogus assertion · ac34e784
      Simon Peyton Jones authored
      Remove a bogus assertion in FamInst.newFamInst
      (There is a comment to explain.)
      This fixes Trac #16112.
    • syd@cs-syd.eu's avatar
      hWaitForInput-accurate-socket test · 2e9426df
      syd@cs-syd.eu authored
  9. 23 Feb, 2019 4 commits
  10. 22 Feb, 2019 5 commits
    • Matthew Pickering's avatar
      Use validate flavour rather than devel2 for DEBUG CI job · 44ad7215
      Matthew Pickering authored
      This also builds stage2 with optimisations and -dcore-lint
    • Simon Peyton Jones's avatar
      Fix exprIsConApp_maybe · c25b135f
      Simon Peyton Jones authored
      In this commit
         commit 7833cf40
         Date:   Thu Jan 24 17:58:50 2019 +0100
            Look through newtype wrappers (Trac #16254)
      we made exprIsConApp_maybe quite a bit cleverer.  But I had not paid
      enough attention to keeping exactly the correct substitution and
      in-scope set, which led to Trac #16348.
      There were several buglets (like applying the substitution twice in
      exprIsConApp_maybe, but the proximate source of the bug was that we were
      calling addNewInScopeIds, which deleted things from the substitution as
      well as adding them to the in-scope set.  That's usually right, but not
      This was quite tricky to track down.  But it is nicer now.
    • Simon Peyton Jones's avatar
      Don't do binder-swap for GlobalIds · 0eb7cf03
      Simon Peyton Jones authored
      This patch disables the binder-swap transformation in the
      (relatively rare) case when the scrutinee is a GlobalId.
      Reason: we are getting Lint errors so that GHC doesn't
      even validate.  Trac #16346.
      This is NOT the final solution -- it's just a stop-gap
      to get us running again.
      The final solution is in Trac #16296
    • Simon Peyton Jones's avatar
      Remove tcTyConUserTyVars · a07f46ea
      Simon Peyton Jones authored
      The tcTyConUserTyVars field of TcTyCon was entirely unused.
      This patch kills it off entirely.
    • Andreas Klebinger's avatar
      Bump nofib submodule. · 473632d7
      Andreas Klebinger authored