1. 12 Nov, 2019 1 commit
  2. 08 Nov, 2019 2 commits
  3. 07 Nov, 2019 3 commits
    • Ben Gamari's avatar
      FlagChecker: Add ticky flags to hashed flags · 55bc3787
      Ben Gamari authored
      These affect output and therefore should be part of the flag hash.
    • Stefan Schulze Frielinghaus's avatar
      For s390x issue a warning if LLVM 9 or older is used · a424229d
      Stefan Schulze Frielinghaus authored
      For s390x the GHC calling convention is only supported since LLVM
      version 10.  Issue a warning in case an older version of LLVM is used.
    • Ryan Scott's avatar
      Clean up TH's treatment of unary tuples (or, #16881 part two) · 708c60aa
      Ryan Scott authored
      !1906 left some loose ends in regards to Template Haskell's treatment
      of unary tuples. This patch ends to tie up those loose ends:
      * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]`
        and `TupP [pat]` also now produce unary tuples.
      * I have added various special cases in GHC's pretty-printers to
        ensure that explicit 1-tuples are printed using the `Unit` type.
        See `testsuite/tests/th/T17380`.
      * The GHC 8.10.1 release notes entry has been tidied up a little.
      Fixes #16881. Fixes #17371. Fixes #17380.
  4. 05 Nov, 2019 3 commits
    • Ömer Sinan Ağacan's avatar
      CoreTidy: hide tidyRule · b7460492
      Ömer Sinan Ağacan authored
    • Ömer Sinan Ağacan's avatar
    • Sebastian Graf's avatar
      Check EmptyCase by simply adding a non-void constraint · 1593debf
      Sebastian Graf authored
      We can handle non-void constraints since !1733, so we can now express
      the strictness of `-XEmptyCase` just by adding a non-void constraint
      to the initial Uncovered set.
      For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }`
      is non-empty. This is conceptually simpler than the plan outlined in
       #17376, because it talks to the oracle directly.
      In order for this patch to pass the testsuite, I had to fix handling of
      newtypes in the pattern-match checker (#17248).
      Since we use a different code path (well, the main code path) for
      `-XEmptyCase` now, we apparently also handle #13717 correctly.
      There's also some dead code that we can get rid off now.
      `provideEvidence` has been updated to provide output more in line with
      the old logic, which used `inhabitationCandidates` under the hood.
      A consequence of the shift away from the `UncoveredPatterns` type is
      that we don't report reduced type families for empty case matches,
      because the pretty printer is pure and only knows the match variable's
      Fixes #13717, #17248, #17386
  5. 04 Nov, 2019 1 commit
    • Ben Gamari's avatar
      SysTools: Only apply Windows-specific workaround on Windows · 3b65655c
      Ben Gamari authored
      Issue #1110 was apparently due to a bug in Vista which prevented GCC
      from finding its binaries unless we explicitly added it to PATH.
      However, this workaround was incorrectly applied on non-Windows
      platforms as well, resulting in ill-formed PATHs (#17266).
      Fixes #17266.
  6. 03 Nov, 2019 2 commits
    • Richard Eisenberg's avatar
      Update Note references -- comments only · 3c916162
      Richard Eisenberg authored
      Follow-on from !2041.
    • Sebastian Graf's avatar
      Separate `LPat` from `Pat` on the type-level · 182b1199
      Sebastian Graf authored
      Since the Trees That Grow effort started, we had `type LPat = Pat`.
      This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
      the reason why all GHC passes use the extension constructor `XPat` to
      attach source locations. See #15495 for the design discussion behind
      But now suddenly there are `XPat`s everywhere!
      There are several functions which dont't cope with `XPat`s by either
      crashing (`hsPatType`) or simply returning incorrect results
      This issue was raised in #17330. I also came up with a rather clean and
      type-safe solution to the problem: We define
      type family XRec p (f :: * -> *) = r | r -> p f
      type instance XRec (GhcPass p) f = Located (f (GhcPass p))
      type instance XRec TH          f =          f p
      type LPat p = XRec p Pat
      This is a rather modular embedding of the old "ping-pong" style, while
      we only pay for the `Located` wrapper within GHC. No ping-ponging in
      a potential Template Haskell AST, for example. Yet, we miss no case
      where we should've handled a `SrcLoc`: `hsPatType` and
      `collectEvVarsPat` are not callable at an `LPat`.
      Also, this gets rid of one indirection in `Located` variants:
      Previously, we'd have to go through `XPat` and `Located` to get from
      `LPat` to the wrapped `Pat`. Now it's just `Located` again.
      Thus we fix #17330.
  7. 02 Nov, 2019 1 commit
    • Simon Peyton Jones's avatar
      Make CSE delay inlining less · 4a6d3d68
      Simon Peyton Jones authored
      CSE delays inlining a little bit, to avoid losing vital
      specialisations; see Note [Delay inlining after CSE] in CSE.
      But it was being over-enthusiastic.  This patch makes the
      delay only apply to Ids with specialisation rules, which
      avoids unnecessary delay (#17409).
  8. 01 Nov, 2019 4 commits
    • Adam Sandberg Eriksson's avatar
    • Ben Gamari's avatar
      Describe optimisation of demand analysis of noinline · dab12c87
      Ben Gamari authored
      As described in #16588.
    • Simon Peyton Jones's avatar
      Fix a bad error in tcMatchTy · 1e2e82aa
      Simon Peyton Jones authored
      This patch fixes #17395, a very subtle and hard-to-trigger
      bug in tcMatchTy.  It's all explained in
        Note [Matching in the presence of casts (2)]
      I have not added a regression test because it is very hard
      to trigger it, until we have the upcoming mkAppTyM patch,
      after which lacking this patch means you can't even compile
      the libraries.
    • Simon Peyton Jones's avatar
      Makes Lint less chatty: · 35c99e72
      Simon Peyton Jones authored
      I found in #17415 that Lint was printing out truly gigantic
      warnings, unmanageably huge, with repeated copies of the
      same thing.
      This patch makes Lint less chatty, especially for warnings:
      * For **warnings**, I don't print details of the location,
        unless you add `-dppr-debug`.
      * For **errors**, I still print all the info. They are fatal
        and stop exection, whereas warnings appear repeatedly.
      * I've made much less use of `AnExpr` in `LintLocInfo`;
        the expression can be gigantic.
  9. 30 Oct, 2019 1 commit
    • Vladislav Zavialov's avatar
      Whitespace forward compatibility for proposal #229 · 3e7569bc
      Vladislav Zavialov authored
      GHC Proposal #229 changes the lexical rules of Haskell, which may
      require slight whitespace adjustments in certain cases.
      This patch changes formatting in a few places in GHC and its testsuite
      in a way that enables it to compile under the proposed rules.
  10. 29 Oct, 2019 5 commits
  11. 28 Oct, 2019 5 commits
    • Simon Peyton Jones's avatar
      Better arity for join points · ad1fe274
      Simon Peyton Jones authored
      A join point was getting too large an arity, leading to #17294.
      I've tightened up the invariant: see
        CoreSyn, Note [Invariants on join points], invariant 2b
    • Sebastian Graf's avatar
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances... · e951f219
      Sebastian Graf authored
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints
      In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
      for `Outputable` instances of AST data types means users can provide orphan
      `Outputable` instances for passes other than `GhcPass`.
      Type inference doesn't currently to suffer, and Richard gave an example
      in #17304 that shows how rare a case would be where the slightly worse
      type inference would matter.
      So I went ahead with the refactoring, attempting to fix #17304.
    • Alan Zimmerman's avatar
      Attach API Annotations for {-# SOURCE #-} import pragma · e0e04856
      Alan Zimmerman authored
      Attach the API annotations for the start and end locations of the
      {-# SOURCE #-} pragma in an ImportDecl.
      Closes #17388
    • Ryan Scott's avatar
      Refactor TcDeriv to validity-check less in anyclass/via deriving (#13154) · cd9b9459
      Ryan Scott authored
      Due to the way `DerivEnv` is currently structured, there is an
      invariant that every derived instance must consist of a class applied
      to a non-empty list of argument types, where the last argument *must*
      be an application of a type constructor to some arguments. This works
      for many cases, but there are also some design patterns in standalone
      `anyclass`/`via` deriving that are made impossible due to enforcing
      this invariant, as documented in #13154.
      This fixes #13154 by refactoring `TcDeriv` and friends to perform
      fewer validity checks when using the `anyclass` or `via` strategies.
      The highlights are as followed:
      * Five fields of `DerivEnv` have been factored out into a new
        `DerivInstTys` data type. These fields only make sense for
        instances that satisfy the invariant mentioned above, so
        `DerivInstTys` is now only used in `stock` and `newtype` deriving,
        but not in other deriving strategies.
      * There is now a `Note [DerivEnv and DerivSpecMechanism]` describing
        the bullet point above in more detail, as well as explaining the
        exact requirements that each deriving strategy imposes.
      * I've refactored `mkEqnHelp`'s call graph to be slightly less
        complicated. Instead of the previous `mkDataTypeEqn`/`mkNewTypeEqn`
        dichotomy, there is now a single entrypoint `mk_eqn`.
      * Various bits of code were tweaked so as not to use fields that are
        specific to `DerivInstTys` so that they may be used by all deriving
        strategies, since not all deriving strategies use `DerivInstTys`.
    • Josef Svenningsson's avatar
      Fix #15344: use fail when desugaring applicative-do · 6635a3f6
      Josef Svenningsson authored
      Applicative-do has a bug where it fails to use the monadic fail method
      when desugaring patternmatches which can fail. See #15344.
      This patch fixes that problem. It required more rewiring than I had expected.
      Applicative-do happens mostly in the renamer; that's where decisions about
      scheduling are made. This schedule is then carried through the typechecker and
      into the desugarer which performs the actual translation. Fixing this bug
      required sending information about the fail method from the renamer, through
      the type checker and into the desugarer. Previously, the desugarer didn't
      have enough information to actually desugar pattern matches correctly.
      As a side effect, we also fix #16628, where GHC wouldn't catch missing
      MonadFail instances with -XApplicativeDo.
  12. 27 Oct, 2019 1 commit
    • Ryan Scott's avatar
      Parenthesize nullary constraint tuples using sigPrec (#17403) · fa0d4809
      Ryan Scott authored
      We were using `appPrec`, not `sigPrec`, as the precedence when
      determining whether or not to parenthesize `() :: Constraint`,
      which lead to the parentheses being omitted in function contexts
      like `(() :: Constraint) => String`. Easily fixed.
      Fixes #17403.
  13. 26 Oct, 2019 2 commits
  14. 24 Oct, 2019 3 commits
    • Ryan Scott's avatar
      Mark promoted InfixT names as IsPromoted (#17394) · 243c72eb
      Ryan Scott authored
      We applied a similar fix for `ConT` in #15572 but forgot to apply the
      fix to `InfixT` as well. This patch fixes #17394 by doing just that.
    • Ryan Scott's avatar
      Make isTcLevPoly more conservative with newtypes (#17360) · 9de3f8b1
      Ryan Scott authored
      `isTcLevPoly` gives an approximate answer for when a type constructor
      is levity polymorphic when fully applied, where `True` means
      "possibly levity polymorphic" and `False` means "definitely not
      levity polymorphic". `isTcLevPoly` returned `False` for newtypes,
      which is incorrect in the presence of `UnliftedNewtypes`, leading
      to #17360. This patch tweaks `isTcLevPoly` to return `True` for
      newtypes instead.
      Fixes #17360.
    • Ryan Scott's avatar
      Parenthesize GADT return types in pprIfaceConDecl (#17384) · 6824f29a
      Ryan Scott authored
      We were using `pprIfaceAppArgs` instead of `pprParendIfaceAppArgs`
      in `pprIfaceConDecl`. Oops.
      Fixes #17384.
  15. 23 Oct, 2019 6 commits
    • Ömer Sinan Ağacan's avatar
      Add new flag for unarised STG dumps · 266435a7
      Ömer Sinan Ağacan authored
      Previously -ddump-stg would dump pre and post-unarise STGs. Now we have
      a new flag for post-unarise STG and -ddump-stg only dumps coreToStg
      STG dump flags after this commit:
      - -ddump-stg: Dumps CoreToStg output
      - -ddump-stg-unarised: Unarise output
      - -ddump-stg-final: STG right before code gen (includes CSE and lambda
    • Andreas Klebinger's avatar
      Make dynflag argument for withTiming pure. · 6beea836
      Andreas Klebinger authored
      19 times out of 20 we already have dynflags in scope.
      We could just always use `return dflags`. But this is in fact not free.
      When looking at some STG code I noticed that we always allocate a
      closure for this expression in the heap. Clearly a waste in these cases.
      For the other cases we can either just modify the callsite to
      get dynflags or use the _D variants of withTiming I added which
      will use getDynFlags under the hood.
    • Andreas Klebinger's avatar
      Fix bug in the x86 backend involving the CFG. · aa778152
      Andreas Klebinger authored
      This is part two of fixing #17334.
      There are two parts to this commit:
      - A bugfix for computing loop levels
      - A bugfix of basic block invariants in the NCG.
      In the first bug we ended up with a CFG of the sort: [A -> B -> C]
      This was represented via maps as fromList [(A,B),(B,C)] and later
      transformed into a adjacency array. However the transformation did
      not include block C in the array (since we only looked at the keys of
      the map).
      This was still fine until we tried to look up successors for C and tried
      to read outside of the array bounds when accessing C.
      In order to prevent this in the future I refactored to code to include
      all nodes as keys in the map representation. And make this a invariant
      which is checked in a few places.
      Overall I expect this to make the code more robust as now any failed
      lookup will represent an error, versus failed lookups sometimes being
      expected and sometimes not.
      In terms of performance this makes some things cheaper (getting a list
      of all nodes) and others more expensive (adding a new edge). Overall
      this adds up to no noteable performance difference.
      Part 2: When the NCG generated a new basic block, it did
      not always insert a NEWBLOCK meta instruction in the stream which
      caused a quite subtle bug.
          During instruction selection a statement `s`
          in a block B with control of the sort: B -> C
          will sometimes result in control
          flow of the sort:
                  ┌ < ┐
                  v   ^
            B ->  B1  ┴ -> C
          as is the case for some atomic operations.
          Now to keep the CFG in sync when introducing B1 we clearly
          want to insert it between B and C. However there is
          a catch when we have to deal with self loops.
          We might start with code and a CFG of these forms:
              stmt1               ┌ < ┐
              ....                v   ^
              stmtX              loop ┘
              goto loop:
          Now we introduce B1:
                                  ┌ ─ ─ ─ ─ ─┐
              loop:               │   ┌ <  ┐ │
              instrs              v   │    │ ^
              ....               loop ┴ B1 ┴ ┘
              goto loop:
          This is simple, all outgoing edges from loop now simply
          start from B1 instead and the code generator knows which
          new edges it introduced for the self loop of B1.
          Disaster strikes if the statement Y follows the same pattern.
          If we apply the same rule that all outgoing edges change then
          we end up with:
              loop ─> B1 ─> B2 ┬─┐
                │      │    └─<┤ │
                │      └───<───┘ │
          This is problematic. The edge B1->B1 is modified as expected.
          However the modification is wrong!
          The assembly in this case looked like this:
              cmpxchgq ...
              jne _B1
              <end _B1>
              cmpxchgq ...
              jne _B2
              jmp loop
          There is no edge _B2 -> _B1 here. It's still a self loop onto _B1.
          The problem here is that really B1 should be two basic blocks.
          Otherwise we have control flow in the *middle* of a basic block.
          A contradiction!
          So to account for this we add yet another basic block marker:
              cmpxchgq ...
              jne _B1
              jmp _B1'
              <end _B1>
          Now when inserting B2 we will only look at the outgoing edges of B1' and
          everything will work out nicely.
          You might also wonder why we don't insert jumps at the end of _B1'. There is
          no way another block ends up jumping to the labels _B1 or _B2 since they are
          essentially invisible to other blocks. View them as control flow labels local
          to the basic block if you'd like.
          Not doing this ultimately caused (part 2 of) #17334.
    • Ryan Scott's avatar
      Reify oversaturated data family instances correctly (#17296) · a19c7d17
      Ryan Scott authored
      `TcSplice` was not properly handling oversaturated data family
      instances, such as the example in #17296, as it dropped arguments due
      to carelessly zipping data family instance arguments with
      `tyConTyVars`. For data families, the number of `tyConTyVars` can
      sometimes be less than the number of arguments it can accept in a
      data family instance due to the fact that data family instances can
      be oversaturated.
      To account for this, `TcSplice.mkIsPolyTvs` has now been renamed to
      `tyConArgsPolyKinded` and now factors in `tyConResKind` in addition
      to `tyConTyVars`. I've also added
      `Note [Reified instances and explicit kind signatures]` which
      explains the various subtleties in play here.
      Fixes #17296.
    • Alp Mestanogullari's avatar
      compiler: introduce DynFlags plugins · 900cf195
      Alp Mestanogullari authored
      They have type '[CommandLineOpts] -> Maybe (DynFlags -> IO DynFlags)'.
      All plugins that supply a non-Nothing 'dynflagsPlugin' will see their
      updates applied to the current DynFlags right after the plugins are
      One use case for this is to superseede !1580 for registering hooks
      from a plugin. Frontend/parser plugins were considered to achieve this
      but they respectively conflict with how this plugin is going to be used
      and don't allow overriding/modifying the DynFlags, which is how hooks have
      to be registered.
      This commit comes with a test, 'test-hook-plugin', that registers a "fake"
      meta hook that replaces TH expressions with the 0 integer literal.
    • Richard Eisenberg's avatar
      Implement a coverage checker for injectivity · 1cd3fa29
      Richard Eisenberg authored
      This fixes #16512.
      There are lots of parts of this patch:
      * The main payload is in FamInst. See
      Note [Coverage condition for injective type families] there
      for the overview. But it doesn't fix the bug.
      * We now bump the reduction depth every time we discharge
      a CFunEqCan. See Note [Flatten when discharging CFunEqCan]
      in TcInteract.
      * Exploration of this revealed a new, easy to maintain invariant
      for CTyEqCans. See Note [Almost function-free] in TcRnTypes.
      * We also realized that type inference for injectivity was a
      bit incomplete. This means we exchanged lookupFlattenTyVar for
      rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new
      function is monadic while the previous one was pure, necessitating
      some faff in TcInteract. Nothing too bad.
      * zonkCt did not maintain invariants on CTyEqCan. It's not worth
      the bother doing so, so we just transmute CTyEqCans to
      * The pure unifier was finding the fixpoint of the returned
      substitution, even when doing one-way matching (in tcUnifyTysWithTFs).
      Fixed now.
      Test cases: typecheck/should_fail/T16512{a,b}