1. 05 Aug, 2015 17 commits
  2. 04 Aug, 2015 2 commits
    • eir@cis.upenn.edu's avatar
      Test #9233 in perf/compiler/T9233 · b5f1c851
      eir@cis.upenn.edu authored
      Summary:
      Ideally, we could use Phab's numbers to set the perf
      test correctly. But even if that's not possible, then I need help
      writing my `all.T`. With the version you see here, I get the following
      
      ```
      Traceback (most recent call last):
        File "/Users/rae/Documents/ghc-valid/testsuite/driver/testlib.py", line 801, in do_test
          result = func(*[name,way] + args)
      TypeError: multimod_compile() takes exactly 4 arguments (6 given)
      ```
      
      I don't know how to fix this.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, thomie
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1129
      
      GHC Trac Issues: #9233
      b5f1c851
    • eir@cis.upenn.edu's avatar
      Fix #10713. · f063bd54
      eir@cis.upenn.edu authored
      When doing the apartness/flattening thing, we really only need to
      eliminate non-generative tycons, not *all* families. (Data families
      are indeed generative!)
      f063bd54
  3. 03 Aug, 2015 11 commits
    • skvadrik's avatar
      Removed deprecated syntax for GADT constuctors. · 30c981e1
      skvadrik authored
      Old syntax was deprecated 6 years ago in this commit
      432b9c93 by simonpj:"New syntax for
      GADT-style record declarations, and associated refactoring" discussed
      in Trac #3306.
      
      This patch removes 2 reduce/reduce conflicts in parser. Conflicting
      productions were:
      
      ```
          gadt_constr -> con_list '::' sigtype
          gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype
      ```
      
      Recursive inlining of `con_list` and `oqtycon` helped reveal the
      conflict:
      
      ```
          gadt_constr -> '(' CONSYM ')' '::' sigtype
          gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype
      ```
      
      between two types of GADT constructors (second form stands for
      deprecated syntax).
      
      Test Plan: `make fasttest`, one breakage TEST="records-fail" (parse
      error instead of typecheck error due to removal of deprecated syntax).
      Updated test.
      
      Reviewers: simonmar, bgamari, austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering, trofi
      
      Differential Revision: https://phabricator.haskell.org/D1118
      
      GHC Trac Issues: #3306
      30c981e1
    • Ben Gamari's avatar
      CmmParse: Don't force alignment in memcpy-ish operations · 64b6733e
      Ben Gamari authored
      This was initially made in 681973c3.
      Here I wanted to enforce that the alignment passed to %memcpy was a
      constant expression, as this is required by LLVM. However, this breaks
      the knot-tying done in `loopDecls`, causing T8131 to hang.
      
      Here I remove the `seq` and mark T8131 as `expect_broken` in the case
      of the NCG, which doesn't force the alignment in this case.
      
      Fixes #10664.
      64b6733e
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 7ec6ffc4
      Gabor Greif authored
      7ec6ffc4
    • thomasw's avatar
      Support wild cards in data/type family instances · d9d2102e
      thomasw authored
      Handle anonymous wild cards in type or data family instance
      declarations like
      unnamed type variables. For instance (pun intented):
      
          type family F (a :: *) (b :: *) :: *
          type instance F Int _ = Int
      
      Is now the same as:
      
          type family F (a :: *) (b :: *) :: *
          type instance F Int x = Int
      
      Note that unlike wild cards in partial type signatures, no errors (or
      warnings
      with -XPartialTypeSignatures) are generated for these wild cards, as
      there is
      nothing interesting to report to the user, i.e. the inferred kind.
      
      Only anonymous wild cards are supported here, named and
      extra-constraints wild
      card are not.
      
      Test Plan: pass new tests
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1092
      
      GHC Trac Issues: #3699, #10586
      d9d2102e
    • skvadrik's avatar
      4 reduce/reduce parser conflicts resolved · 697079f1
      skvadrik authored
      As GHC documentation (section 7.4.4, Type operators) says:
      > "There is now some potential ambiguity in import and export lists;
      for example if you write import M( (+) ) do you mean the function (+)
      or the type constructor (+)? The default is the former, but with
      -XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC
      allows you to specify the latter by preceding it with the keyword type"
      
      Turns out this ambiguity causes 4 of 6 reduce/reduce conflicts in GHC
      parser.  All 4 conflicts arise from a single production:
      
          qcname
              :  qvar
              |  oqtycon
      
      Recursive inlining of 'qvar' and 'oqtycon' helps reveal the faulty
      productions:
      
          qcname
              :
          ...
              | '(' QVARSYM ')'
              | '(' VARSYM ')'
              | '(' '*'    ')'
              | '(' '-'    ')'
      
      These productions can either be parsed as variable or type constructor,
      but variable constuctor is always preferred. My patch removes ambiguity
      while preserving the existing behaviour:
      
        - all unambigous productions are left as-is
        - ambigous productions for variable constuctors are left
        - ambigous productions for type constructors are removed (there's no
          way they could be triggered)
      
      Updated comment.
      
      Test Plan: Tested with 'make fasttest'
      
      Reviewers: austin, simonpj, trofi, bgamari, simonmar
      
      Reviewed By: trofi, bgamari, simonmar
      
      Subscribers: thomie, mpickering
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1111
      697079f1
    • Simon Peyton Jones's avatar
      Test Trac #10134 · 30b32f4c
      Simon Peyton Jones authored
      30b32f4c
    • Simon Peyton Jones's avatar
      Minor improvement to user guide · d7ced09a
      Simon Peyton Jones authored
      Specify that the type variables for a class/instance decl scope
      over the body even without a 'forall'.
      
      Provoked by Trac #10722.
      d7ced09a
    • Simon Peyton Jones's avatar
      Typos in comments · 4d8859cc
      Simon Peyton Jones authored
      4d8859cc
    • Ben Gamari's avatar
      Fix incorrect stack pointer usage in StgRun() on x86_64 · b38ee89c
      Ben Gamari authored
      The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants
      where the ABI doesn't impose a mandatory red zone for the stack, like on
      Windows or Xen/HaLVM. The current implementation restores the stack
      pointer first, which effectively marks the area with the saved registers
      as reusable. Later, the CPU registers are restored from this "free"
      area.
      
      This ordering happens to work by accident on operating systems that
      strictly adhere to the System V ABI, because any interrupt/signal
      delivery is guaranteed to leave the first 128 bytes past the stack
      pointer untouched (red zone). On other systems this might result in
      corrupted CPU registers if an interruption happens just after restoring
      the stack pointer.
      
      The red zone is usually only used by small leaf functions to avoid
      updates to the stack pointer and exploiting it doesn't give us any
      advantage in this case.
      
      Reviewers: austin, rwbarton
      
      Reviewed By: rwbarton
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D1120
      
      GHC Trac Issues: #10155
      b38ee89c
    • Simon Marlow's avatar
      Update parallel submodule, and re-enable warnings · 948e03e5
      Simon Marlow authored
      Test Plan: using remote validate
      
      Reviewers: austin, hvr, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1117
      948e03e5
    • Michal Terepeta's avatar
      Support MO_U_QuotRem2 in LLVM backend · 92f5385d
      Michal Terepeta authored
      This adds support for MO_U_QuotRem2 in LLVM backend.  Similarly to
      MO_U_Mul2 we use the standard LLVM instructions (in this case 'udiv'
      and 'urem') but do the computation on double the word width (e.g., for
      64-bit we will do them on 128 registers).
      
      Test Plan: validate
      
      Reviewers: rwbarton, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1100
      
      GHC Trac Issues: #9430
      92f5385d
  4. 02 Aug, 2015 3 commits
    • Gabor Greif's avatar
      Make BranchFlag a new kind · 37227d34
      Gabor Greif authored
      this is resolving an old TODO comment
      37227d34
    • Gabor Greif's avatar
      Typo in comment · d9b618ff
      Gabor Greif authored
      d9b618ff
    • Alan Zimmerman's avatar
      Replace (SourceText,FastString) with StringLiteral data type · 15dd7007
      Alan Zimmerman authored
      Summary:
      Phab:D907 introduced SourceText for a number of data types, by replacing
      FastString with (SourceText,FastString). Since this has an Outputable
      instance, no warnings are generated when ppr is called on it, but
      unexpected output is generated. See Phab:D1096 for an example of this.
      
      Replace the (SourceText,FastString) tuples with a new data type,
      ```lang=hs
      data StringLiteral = StringLiteral SourceText FastString
      ```
      
      Update haddock submodule accordingly
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, rwbarton, trofi, bgamari
      
      Reviewed By: trofi, bgamari
      
      Subscribers: thomie, trofi, rwbarton, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1101
      
      GHC Trac Issues: #10692
      15dd7007
  5. 01 Aug, 2015 1 commit
  6. 31 Jul, 2015 6 commits