1. 28 Nov, 2019 6 commits
  2. 27 Nov, 2019 2 commits
    • Vladislav Zavialov's avatar
      Whitespace-sensitive bang patterns (#1087, #17162) · 8168b42a
      Vladislav Zavialov authored
      This patch implements a part of GHC Proposal #229 that covers five
      operators:
      
      * the bang operator (!)
      * the tilde operator (~)
      * the at operator (@)
      * the dollar operator ($)
      * the double dollar operator ($$)
      
      Based on surrounding whitespace, these operators are disambiguated into
      bang patterns, lazy patterns, strictness annotations, type
      applications, splices, and typed splices.
      
      This patch doesn't cover the (-) operator or the -Woperator-whitespace
      warning, which are left as future work.
      8168b42a
    • Sebastian Graf's avatar
      Make warnings for TH splices opt-in · 5a08f7d4
      Sebastian Graf authored
      In #17270 we have the pattern-match checker emit incorrect warnings. The
      reason for that behavior is ultimately an inconsistency in whether we
      treat TH splices as written by the user (`FromSource :: Origin`) or as
      generated code (`Generated`). This was first reported in #14838.
      
      The current solution is to TH splices as `Generated` by default and only
      treat them as `FromSource` when the user requests so
      (-fenable-th-splice-warnings). There are multiple reasons for opt-in
      rather than opt-out:
      
        * It's not clear that the user that compiles a splice is the author of the code
          that produces the warning. Think of the situation where she just splices in
          code from a third-party library that produces incomplete pattern matches.
          In this scenario, the user isn't even able to fix that warning.
        * Gathering information for producing the warnings (pattern-match check
          warnings in particular) is costly. There's no point in doing so if the user
          is not interested in those warnings.
      
      Fixes #17270, but not #14838, because the proper solution needs a GHC
      proposal extending the TH AST syntax.
      5a08f7d4
  3. 25 Nov, 2019 1 commit
  4. 24 Nov, 2019 3 commits
    • Ben Gamari's avatar
      configure: Fix HAVE_C11_ATOMICS macro · b694b566
      Ben Gamari authored
      Previously we were using AC_DEFINE instead of
      AC_DEFINE_UNQUOTED, resulted in the variable not being
      interpolated.
      
      Fixes #17505.
      b694b566
    • vdukhovni's avatar
      On FreeBSD 12 sys/sysctl.h requires sys/types.h · 6008206a
      vdukhovni authored
      Else build fails with:
      
          In file included from ExecutablePath.hsc:42:
          /usr/include/sys/sysctl.h:1062:25: error: unknown type name 'u_int'; did you mean 'int'?
           int sysctl(const int *, u_int, void *, size_t *, const void *, size_t);
      			     ^~~~~
      			     int
          compiling libraries/base/dist-install/build/System/Environment/ExecutablePath_hsc_make.c failed (exit code 1)
      
      Perhaps also also other FreeBSD releases, but additional include
      will no harm even if not needed.
      6008206a
    • Brian Wignall's avatar
      Fix typos · 7b4c7b75
      Brian Wignall authored
      7b4c7b75
  5. 23 Nov, 2019 12 commits
  6. 21 Nov, 2019 1 commit
  7. 20 Nov, 2019 4 commits
  8. 19 Nov, 2019 11 commits
    • Ben Gamari's avatar
      nonmoving: Drop redundant write barrier on stack underflow · 098d5017
      Ben Gamari authored
      Previously we would push stack-carried return values to the new stack on
      a stack overflow. While the precise reasoning for this barrier is
      unfortunately lost to history, in hindsight I suspect it was prompted by
      a missing barrier elsewhere (that has been since fixed).
      
      Moreover, there the redundant barrier is actively harmful: the stack may
      contain non-pointer values; blindly pushing these to the mark queue will
      result in a crash. This is precisely what happened in the `stack003`
      test. However, because of a (now fixed) deficiency in the test this
      crash did not trigger on amd64.
      098d5017
    • Ben Gamari's avatar
      testsuite: Increase width of stack003 test · a7571a74
      Ben Gamari authored
      Previously the returned tuple seemed to fit in registers on amd64. This
      meant that non-moving collector bug would cause the test to fail on i386
      yet not amd64.
      a7571a74
    • Ben Gamari's avatar
      nonmoving: Fix handling on large object marking on 32-bit · eb7b233a
      Ben Gamari authored
      Previously we would reset the pointer pointing to the object to be
      marked to the beginning of the block when marking a large object. This
      did no harm on 64-bit but on 32-bit it broke, e.g. `arr020`, since we
      align pinned ByteArray allocations such that the payload is 8
      byte-aligned. This means that the object might not begin at the
      beginning of the block.,
      eb7b233a
    • Ben Gamari's avatar
      nonmoving: Rework mark queue representation · 097f8072
      Ben Gamari authored
      The previous representation needlessly limited the array length to
      16-bits on 32-bit platforms.
      097f8072
    • Ben Gamari's avatar
      nonmoving: Fix incorrect masking in mark queue type test · deed8e31
      Ben Gamari authored
      We were using TAG_BITS instead of TAG_MASK. This happened to work on
      64-bit platforms where TAG_BITS==3 since we only use tag values 0 and
      3. However, this broken on 32-bit platforms where TAG_BITS==2.
      deed8e31
    • Ben Gamari's avatar
      nonmoving: Use correct info table pointer accessor · c819c0e4
      Ben Gamari authored
      Previously we used INFO_PTR_TO_STRUCT instead of
      THUNK_INFO_PTR_TO_STRUCT when looking at a thunk. These two happen to be
      equivalent on 64-bit architectures due to alignment considerations
      however they are different on 32-bit platforms. This lead to #17487.
      
      To fix this we also employ a small optimization: there is only one thunk
      of type WHITEHOLE (namely stg_WHITEHOLE_info). Consequently, we can just
      use a plain pointer comparison instead of testing against info->type.
      c819c0e4
    • Ben Gamari's avatar
      rts: Add missing include of SymbolExtras.h · 0418c38d
      Ben Gamari authored
      This broke the Windows build.
      0418c38d
    • Ben Gamari's avatar
      Properly account for libdw paths in make build system · 2b27cc16
      Ben Gamari authored
      Should finally fix #17255.
      2b27cc16
    • Ömer Sinan Ağacan's avatar
      Packages.hs: use O(n*log(n)) ordNub instead of O(n*n) nub · cd40e12a
      Ömer Sinan Ağacan authored
      As reported in #8173 in some environments package lists can get quite
      long, so we use more efficient ordNub instead of nub on package lists.
      cd40e12a
    • vdukhovni's avatar
      Enable USE_PTHREAD_FOR_ITIMER also on FreeBSD · ec8a463d
      vdukhovni authored
      If using a pthread instead of a timer signal is more reliable, and
      has no known drawbacks, then FreeBSD is also capable of supporting
      this mode of operation (tested on FreeBSD 12 with GHC 8.8.1, but
      no reason why it would not also work on FreeBSD 11 or GHC 8.6).
      
      Proposed by Kevin Zhang in:
      
          https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241849
      ec8a463d
    • Ben Gamari's avatar
      Give seq a more precise type and remove magic · 08d595c0
      Ben Gamari authored
      `GHC.Prim.seq` previously had the rather plain type:
      
          seq :: forall a b. a -> b -> b
      
      However, it also had a special typing rule to applications
      where `b` is not of kind `Type`.
      
      Issue #17440 noted that levity polymorphism allows us to rather give
      it the more precise type:
      
          seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b
      
      This allows us to remove the special typing rule that we previously
      required to allow applications on unlifted arguments. T9404 contains a
      non-Type application of `seq` which should verify that this works as
      expected.
      
      Closes #17440.
      08d595c0