1. 27 Nov, 2019 1 commit
    • 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
  2. 20 Nov, 2019 1 commit
  3. 13 Nov, 2019 1 commit
  4. 10 Nov, 2019 1 commit
    • Richard Eisenberg's avatar
      Fix #17405 by not checking imported equations · 55ca1085
      Richard Eisenberg authored
      Previously, we checked all imported type family equations
      for injectivity. This is very silly. Now, we check only
      for conflicts.
      
      Before I could even imagine doing the fix, I needed to untangle
      several functions that were (in my opinion) overly complicated.
      It's still not quite as perfect as I'd like, but it's good enough
      for now.
      
      Test case: typecheck/should_compile/T17405
      55ca1085
  5. 07 Nov, 2019 1 commit
    • 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.
      708c60aa
  6. 01 Nov, 2019 1 commit
  7. 25 Oct, 2019 1 commit
  8. 24 Oct, 2019 1 commit
  9. 23 Oct, 2019 2 commits
    • 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.
      a19c7d17
    • 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
      CNonCanonicals.
      
      * 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}
      1cd3fa29
  10. 13 Oct, 2019 1 commit
  11. 08 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Solve constraints from top-level groups sooner · 9612e91c
      Richard Eisenberg authored
      Previously, all constraints from all top-level groups (as
      separated by top-level splices) were lumped together and solved
      at the end. This could leak metavariables to TH, though, and
      that's bad. This patch solves each group's constraints before
      running the next group's splice.
      
      Naturally, we now report fewer errors in some cases.
      
      One nice benefit is that this also fixes #11680, but in a much
      simpler way than the original fix for that ticket. Admittedly,
      the error messages degrade just a bit from the fix from #11680
      (previously, we informed users about variables that will be
      brought into scope below a top-level splice, and now we just
      report an out-of-scope error), but the amount of complexity
      required throughout GHC to get that error was just not worth it.
      
      This patch thus reverts much of
      f93c9517.
      
      Fixes #16980
      
      Test cases: th/T16980{,a}
      9612e91c
  12. 03 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Improve documentation around empty tuples/lists · 6655ec73
      Richard Eisenberg authored
      This patch also changes the way we handle empty lists, simplifying
      them somewhat. See Note [Empty lists]. Previously, we had to
      special-case empty lists in the type-checker. Now no more!
      
      Finally, this patch improves some documentation around the ir_inst
      field used in the type-checker.
      
      This breaks a test case, but I really think the problem is #17251,
      not really related to this patch.
      
      Test case: typecheck/should_compile/T13680
      6655ec73
  13. 28 Sep, 2019 1 commit
  14. 17 Sep, 2019 1 commit
  15. 16 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      Encode shape information in `PmOracle` · 7915afc6
      Sebastian Graf authored
      Previously, we had an elaborate mechanism for selecting the warnings to
      generate in the presence of different `COMPLETE` matching groups that,
      albeit finely-tuned, produced wrong results from an end user's
      perspective in some cases (#13363).
      
      The underlying issue is that at the point where the `ConVar` case has to
      commit to a particular `COMPLETE` group, there's not enough information
      to do so and the status quo was to just enumerate all possible complete
      sets nondeterministically.  The `getResult` function would then pick the
      outcome according to metrics defined in accordance to the user's guide.
      But crucially, it lacked knowledge about the order in which affected
      clauses appear, leading to the surprising behavior in #13363.
      
      In !1010 we taught the term oracle to reason about literal values a
      variable can certainly not take on. This MR extends that idea to
      `ConLike`s and thereby fixes #13363: Instead of committing to a
      particular `COMPLETE` group in the `ConVar` case, we now split off the
      matching constructor incrementally and record the newly covered case as
      a refutable shape in the oracle. Whenever the set of refutable shapes
      covers any `COMPLETE` set, the oracle recognises vacuosity of the
      uncovered set.
      
      This patch goes a step further: Since at this point the information
      in value abstractions is merely a cut down representation of what the
      oracle knows, value abstractions degenerate to a single `Id`, the
      semantics of which is determined by the oracle state `Delta`.
      Value vectors become lists of `[Id]` given meaning to by a single
      `Delta`, value set abstractions (of which the uncovered set is an
      instance) correspond to a union of `Delta`s which instantiate the
      same `[Id]` (akin to models of formula).
      
      Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149
      
      -------------------------
      Metric Decrease:
          ManyAlternatives
          T11195
      -------------------------
      7915afc6
  16. 26 Jul, 2019 1 commit
  17. 05 Jul, 2019 1 commit
  18. 03 Jul, 2019 1 commit
  19. 02 Jul, 2019 1 commit
  20. 12 Jun, 2019 1 commit
  21. 10 Jun, 2019 1 commit
  22. 21 May, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16666 by parenthesizing contexts in Convert · 4a6c8436
      Ryan Scott authored
      Most places where we convert contexts in `Convert` are actually in
      positions that are to the left of some `=>`, such as in superclasses
      and instance contexts. Accordingly, these contexts need to be
      parenthesized at `funPrec`. To accomplish this, this patch changes
      `cvtContext` to require a precedence argument for the purposes of
      calling `parenthesizeHsContext` and adjusts all `cvtContext` call
      sites accordingly.
      4a6c8436
  23. 14 May, 2019 1 commit
  24. 08 Apr, 2019 1 commit
  25. 01 Apr, 2019 1 commit
  26. 22 Mar, 2019 1 commit
  27. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  28. 15 Mar, 2019 1 commit
  29. 08 Mar, 2019 1 commit
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      
      Ticket #14741 can be fixed if the original code uses this new TH feature.
      224a6b86
  30. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  31. 24 Feb, 2019 1 commit
  32. 12 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16293 by cleaning up Proxy# infelicities · 012257c1
      Ryan Scott authored
      This bug fixes three problems related to `Proxy#`/`proxy#`:
      
      1. Reifying it with TH claims that the `Proxy#` type constructor has
         two arguments, but that ought to be one for consistency with
         TH's treatment for other primitive type constructors like `(->)`.
         This was fixed by just returning the number of
         `tyConVisibleTyVars` instead of using `tyConArity` (which includes
         invisible arguments).
      2. The role of `Proxy#`'s visible argument was hard-coded as nominal.
         Easily fixed by changing it to phantom.
      3. The visibility of `proxy#`'s kind argument was specified, which
         is different from the `Proxy` constructor (which treats it as
         inferred). Some minor refactoring in `proxyHashId` fixed ths up.
      
         Along the way, I had to introduce a `mkSpecForAllTy` function, so
         I did some related Haddock cleanup in `Type`, where that function
         lives.
      012257c1
  33. 10 Feb, 2019 1 commit
    • Matthew Pickering's avatar
      Capture and simplify constraints arising from running typed splices · a48753bd
      Matthew Pickering authored
      This fixes a regression caused by #15471 where splicing in a trivial
      program such as `[|| return () ||]` would fail as the dictionary for
      `return` would never get bound in the module containing the splice.
      
      Arguably this is symptomatic of a major problem affecting TTH where we
      serialise renamed asts and then retype check them. The reference to the
      dictionary should be fully determined at the quote site so that splicing
      doesn't have to solve any implicits at all. It's a coincidence this
      works due to coherence but see #15863 and #15865 for examples where
      things do go very wrong.
      
      Fixes #16195
      a48753bd
  34. 08 Feb, 2019 1 commit
  35. 30 Jan, 2019 3 commits
  36. 28 Jan, 2019 1 commit
    • Ryan Scott's avatar
      Use sigPrec in more places in Convert and HsUtils · b1e569a5
      Ryan Scott authored
      Trac #16183 was caused by TH conversion (in `Convert`) not properly
      inserting parentheses around occurrences of explicit signatures where
      appropriate, such as in applications, function types, and type family
      equations. Solution: use `parenthesizeHsType sigPrec` in these
      places. While I was in town, I also updated `nlHsFunTy` to do the
      same thing.
      b1e569a5
  37. 23 Jan, 2019 1 commit