1. 12 Oct, 2019 6 commits
    • Ryan Scott's avatar
      Use newDFunName for both manual and derived instances (#17339) · 0a338264
      Ryan Scott authored
      Issue #17339 was caused by using a slightly different version of
      `newDFunName` for derived instances that, confusingly enough, did not
      take all arguments to the class into account when generating the
      `DFun` name. I cannot think of any good reason for doing this, so
      this patch uses `newDFunName` uniformly for both derived instances
      and manually written instances alike.
      
      Fixes #17339.
      0a338264
    • Vladislav Zavialov's avatar
      Skip T13767 on Darwin · cd1a8808
      Vladislav Zavialov authored
      The CI job fails with:
      
      	+++ rts/T13676.run/T13676.run.stderr.normalised	2019-10-09 12:27:56.000000000 -0700
      	@@ -0,0 +1,4 @@
      	+dyld: Library not loaded: @rpath/libHShaskeline-0.7.5.0-ghc8.9.0.20191009.dylib
      	+  Referenced from: /Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib/bin/ghc
      	+  Reason: image not found
      	+*** Exception: readCreateProcess: '/Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib/bin/ghc' '-B/Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib' '-e' ''/''$'/'' == '/''/x0024'/''' +RTS '-tT13676.t'  (exit -6): failed
      
      Unable to reproduce locally.
      cd1a8808
    • Vladislav Zavialov's avatar
      Escape stats file command (#13676) · f1ce3535
      Vladislav Zavialov authored
      f1ce3535
    • John Ericson's avatar
      Simplify Configure in a few ways · c2290596
      John Ericson authored
       - No need to distinguish between gcc-llvm and clang. First of all,
         gcc-llvm is quite old and surely unmaintained by now. Second of all,
         none of the code actually care about that distinction!
      
         Now, it does make sense to consider C multiple frontends for LLVMs in
         the form of clang vs clang-cl (same clang, yes, but tweaked
         interface). But this is better handled in terms of "gccish vs
         mvscish" and "is LLVM", yielding 4 combinations. Therefore, I don't
         think it is useful saving the existing code for that.
      
       - Get the remaining CC_LLVM_BACKEND, and also TABLES_NEXT_TO_CODE in
         mk/config.h the normal way, rather than hacking it post-hoc. No point
         keeping these special cases around for now reason.
      
       - Get rid of hand-rolled `die` function and just use `AC_MSG_ERROR`.
      
       - Abstract check + flag override for unregisterised and tables next to
         code.
      
      Oh, and as part of the above I also renamed/combined some variables
      where it felt appropriate.
      
       - GccIsClang -> CcLlvmBackend. This is for `AC_SUBST`, like the other
       Camal case ones. It was never about gcc-llvm, or Apple's renamed clang,
       to be clear.
      
       - llvm_CC_FLAVOR -> CC_LLVM_BACKEND. This is for `AC_DEFINE`, like the
       other all-caps snake case ones. llvm_CC_FLAVOR was just silly
       indirection *and* an odd name to boot.
      c2290596
    • Stefan Schulze Frielinghaus's avatar
      Hadrian: Take care of assembler source files · 166e1c2a
      Stefan Schulze Frielinghaus authored
      Fixes #17286.
      166e1c2a
    • Sebastian Graf's avatar
      Much simpler language for PmCheck · 30f5ac07
      Sebastian Graf authored
      Simon realised that the simple language composed of let bindings, bang
      patterns and flat constructor patterns is enough to capture the
      semantics of the source pattern language that are important for
      pattern-match checking. Well, given that the Oracle is smart enough to
      connect the dots in this less informationally dense form, which it is
      now.
      
      So we transform `translatePat` to return a list of `PmGrd`s relative to
      an incoming match variable. `pmCheck` then trivially translates each of
      the `PmGrd`s into constraints that the oracle understands.
      
      Since we pass in the match variable, we incidentally fix #15884
      (coverage checks for view patterns) through an interaction with !1746.
      30f5ac07
  2. 09 Oct, 2019 6 commits
    • Ryan Scott's avatar
      Use addUsedDataCons more judiciously in TcDeriv (#17324) · d584e3f0
      Ryan Scott authored
      If you derive an instance like this:
      
      ```hs
      deriving <...> instance Foo C
      ```
      
      And the data constructors for `C` aren't in scope, then
      `doDerivInstErrorChecks1` throws an error. Moreover, it will
      _only_ throw an error if `<...>` is either `stock` or `newtype`.
      This is because the code that the `anyclass` or `via` strategies
      would generate would not require the use of the data constructors
      for `C`.
      
      However, `doDerivInstErrorChecks1` has another purpose. If you
      write this:
      
      ```hs
      import M (C(MkC1, ..., MkCn))
      
      deriving <...> instance Foo C
      ```
      
      Then `doDerivInstErrorChecks1` will call `addUsedDataCons` on
      `MkC1` through `MkCn` to ensure that `-Wunused-imports` does not
      complain about them. However, `doDerivInstErrorChecks1` was doing
      this for _every_ deriving strategy, which mean that if `<...>` were
      `anyclass` or `via`, then the warning about `MkC1` through `MkCn`
      being unused would be suppressed!
      
      The fix is simple enough: only call `addUsedDataCons` when the
      strategy is `stock` or `newtype`, just like the other code paths
      in `doDerivInstErrorChecks1`.
      
      Fixes #17324.
      d584e3f0
    • Ben Gamari's avatar
      Test · 35cc5eff
      Ben Gamari authored
      35cc5eff
    • Ben Gamari's avatar
      Remove GHC_STAGE guards from MachDeps · 5f2c49d8
      Ben Gamari authored
      This allows the stage1 compiler (which needs to run on the build
      platform and produce code for the host) to depend upon properties of the
      target. This is wrong. However, it's no more wrong than it was
      previously and @Erichson2314 is working on fixing this so I'm going to
      remove the guard so we can finally bootstrap HEAD with ghc-8.8 (see
      issue #17146).
      5f2c49d8
    • Ben Gamari's avatar
      817c1a94
    • Ben Gamari's avatar
      Relayout generated header body · 63a5371d
      Ben Gamari authored
      63a5371d
    • Ben Gamari's avatar
      Rename STAGE macro to GHC_STAGE · 0c0a15a8
      Ben Gamari authored
      To avoid polluting the macro namespace
      0c0a15a8
  3. 08 Oct, 2019 26 commits
  4. 07 Oct, 2019 2 commits