1. 19 Jun, 2019 2 commits
  2. 18 Jun, 2019 8 commits
  3. 17 Jun, 2019 3 commits
  4. 16 Jun, 2019 18 commits
  5. 15 Jun, 2019 5 commits
  6. 14 Jun, 2019 4 commits
    • Ben Gamari's avatar
      PrelRules: Don't break let/app invariant in shiftRule · 5279dda8
      Ben Gamari authored
      Previously shiftRule would rewrite as invalid shift like
      let x = I# (uncheckedIShiftL# n 80)
      in ...
      let x = I# (error "invalid shift")
      in ...
      However, this breaks the let/app invariant as `error` is not
      okay-for-speculation. There isn't an easy way to avoid this so let's not
      try. Instead we just take advantage of the undefined nature of invalid
      shifts and return zero.
      Fixes #16742.
    • 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>
    • Andreas Klebinger's avatar
    • Alp Mestanogullari's avatar
      Hadrian: remove superfluous dependencies in Rules.Compile · ec25fe59
      Alp Mestanogullari authored
      Each package's object files were 'need'ing the library files of all transitive
      dependencies of the current package, whichi is pointless since the said
      libraries are not needed until we link those object files together.
      This fixes #16759.