1. 12 Oct, 2019 2 commits
    • Stefan Schulze Frielinghaus's avatar
      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 6 commits