1. 07 Aug, 2019 3 commits
  2. 29 Jul, 2019 1 commit
    • Richard Eisenberg's avatar
      Add Note [RuntimeRep and PrimRep] in RepType · 9f8cdb35
      Richard Eisenberg authored
      Also adds Note [Getting from RuntimeRep to PrimRep], which
      deocuments a related thorny process.
      This Note addresses #16964, which correctly observes that
      documentation for this thorny design is lacking.
      Documentation only.
  3. 28 Jul, 2019 1 commit
  4. 26 Jul, 2019 2 commits
  5. 24 Jul, 2019 1 commit
  6. 21 Jul, 2019 1 commit
    • Ivan Kasatenko's avatar
      Do not ignore events deletion when events to be added are provided (#16916) · 67ee741b
      Ivan Kasatenko authored
      Kqueue/kevent implementation used to ignore events to be unsubscribed
      from when events to be subscribed to were provided. This resulted in a
      lost notification subscription, when GHC runtime didn't listen for any
      events, yet the kernel considered otherwise and kept waking up the IO
      manager thread.
      This commit fixes this issue by always adding and removing all of the
      provided subscriptions.
  7. 20 Jul, 2019 1 commit
  8. 19 Jul, 2019 3 commits
  9. 17 Jul, 2019 1 commit
    • John Ericson's avatar
      Create {Int,Word}32Rep · 0a9b77b8
      John Ericson authored
      This prepares the way for making Int32# and Word32# the actual size they
      claim to be.
      Updates binary submodule for (de)serializing the new runtime reps.
  10. 14 Jul, 2019 4 commits
  11. 13 Jul, 2019 1 commit
  12. 10 Jul, 2019 1 commit
  13. 05 Jul, 2019 1 commit
  14. 04 Jul, 2019 1 commit
  15. 03 Jul, 2019 1 commit
  16. 02 Jul, 2019 2 commits
  17. 27 Jun, 2019 1 commit
  18. 26 Jun, 2019 2 commits
  19. 22 Jun, 2019 1 commit
    • Ben Gamari's avatar
      ghci: Don't rely on resolution of System.IO to base module · 655c6e26
      Ben Gamari authored
      Previously we would hackily evaluate a textual code snippet to compute
      actions to disable I/O buffering and flush the stdout/stderr handles.
      This broke in a number of ways (#15336, #16563).
      Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
      the needed actions. We can then easily refer to these via `Orig` names.
  20. 21 Jun, 2019 1 commit
    • Ben Gamari's avatar
      testsuite: Mark T3372 as fragile on Windows · aa516431
      Ben Gamari authored
      On Windows we must lock package databases even when opening for
      read-only access. This means that concurrent GHC sessions are very
      likely to fail with file lock contention.
      See #16773.
  21. 20 Jun, 2019 3 commits
  22. 18 Jun, 2019 2 commits
  23. 16 Jun, 2019 3 commits
  24. 15 Jun, 2019 1 commit
  25. 14 Jun, 2019 1 commit
    • Andrew Martin's avatar
      Implement the -XUnliftedNewtypes extension. · effdd948
      Andrew Martin authored
      GHC Proposal: 0013-unlifted-newtypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
      Issues: #15219, #1311, #13595, #15883
      Implementation Details:
        Note [Implementation of UnliftedNewtypes]
        Note [Unifying data family kinds]
        Note [Compulsory newtype unfolding]
      This patch introduces the -XUnliftedNewtypes extension. When this
      extension is enabled, GHC drops the restriction that the field in
      a newtype must be of kind (TYPE 'LiftedRep). This allows types
      like Int# and ByteArray# to be used in a newtype. Additionally,
      coerce is made levity-polymorphic so that it can be used with
      newtypes over unlifted types.
      The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
      getInitialKind is more liberal, introducing a unification variable to
      return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
      When kind-checking a data constructor with kcConDecl, we attempt to
      unify the kind of a newtype with the kind of its field's type. When
      typechecking a data declaration with tcTyClDecl, we again perform a
      unification. See the implementation note for more on this.
      Co-authored-by: Richard Eisenberg's avatarRichard Eisenberg <rae@richarde.dev>