1. 04 Jan, 2020 1 commit
  2. 30 Nov, 2019 1 commit
  3. 28 Nov, 2019 1 commit
    • Vladislav Zavialov's avatar
      Factor out HsSCC/HsCoreAnn/HsTickPragma into HsPragE · 6985e0fc
      Vladislav Zavialov authored
      This is a refactoring with no user-visible changes (except for GHC API
      users). Consider the HsExpr constructors that correspond to user-written
      pragmas:
      
        HsSCC         representing  {-# SCC ... #-}
        HsCoreAnn     representing  {-# CORE ... #-}
        HsTickPragma  representing  {-# GENERATED ... #-}
      
      We can factor them out into a separate datatype, HsPragE. It makes the
      code a bit tidier, especially in the parser.
      
      Before this patch:
      
        hpc_annot :: { Located ( (([AddAnn],SourceText),(StringLiteral,(Int,Int),(Int,Int))),
                                 ((SourceText,SourceText),(SourceText,SourceText))
                               ) }
      
      After this patch:
      
        prag_hpc :: { Located ([AddAnn], HsPragE GhcPs) }
      6985e0fc
  4. 27 Nov, 2019 1 commit
    • Vladislav Zavialov's avatar
      Whitespace-sensitive bang patterns (#1087, #17162) · 8168b42a
      Vladislav Zavialov authored
      This patch implements a part of GHC Proposal #229 that covers five
      operators:
      
      * the bang operator (!)
      * the tilde operator (~)
      * the at operator (@)
      * the dollar operator ($)
      * the double dollar operator ($$)
      
      Based on surrounding whitespace, these operators are disambiguated into
      bang patterns, lazy patterns, strictness annotations, type
      applications, splices, and typed splices.
      
      This patch doesn't cover the (-) operator or the -Woperator-whitespace
      warning, which are left as future work.
      8168b42a
  5. 20 Nov, 2019 1 commit
  6. 17 Nov, 2019 1 commit
  7. 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
  8. 28 Oct, 2019 2 commits
    • 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.
      e951f219
    • 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.
      6635a3f6
  9. 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
  10. 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
  11. 20 Sep, 2019 1 commit
  12. 20 Jul, 2019 1 commit
  13. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  14. 03 May, 2019 1 commit
    • Vladislav Zavialov's avatar
      Pattern/expression ambiguity resolution · 52fc2719
      Vladislav Zavialov authored
      This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
      from 'HsExpr' by using the ambiguity resolution system introduced
      earlier for the command/expression ambiguity.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a pattern, for example:
      
      	do { Con a b <- x } -- 'Con a b' is a pattern
      	do { Con a b }      -- 'Con a b' is an expression
      
      Until we encounter binding syntax (<-) we don't know whether to parse
      'Con a b' as an expression or a pattern.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)
      
      This meant polluting 'HsExpr' with pattern-related constructors. In
      other words, limitations of the parser were affecting the AST, and all
      other code (the renamer, the typechecker) had to deal with these extra
      constructors.
      
      We fix this abstraction leak by parsing into an overloaded
      representation:
      
      	class DisambECP b where ...
      	newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/pattern ambiguity.
      52fc2719
  15. 21 Mar, 2019 1 commit
  16. 15 Mar, 2019 1 commit
  17. 24 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Expression/command ambiguity resolution · e61f6e35
      Vladislav Zavialov authored
      This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
      introducing a new ambiguity resolution system in the parser.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a command:
      
      	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
      	proc x -> do { (stuff) }        -- 'stuff' is a command
      
      Until we encounter arrow syntax (-<) we don't know whether to parse
      'stuff' as an expression or a command.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
      
      This meant polluting 'HsExpr' with command-related constructors. In
      other words, limitations of the parser were affecting the AST, and
      all other code (the renamer, the typechecker) had to deal with these
      extra constructors by panicking.
      
      We fix this abstraction leak by parsing into an intermediate
      representation, 'ExpCmd':
      
      	data ExpCmdG b where
      	  ExpG :: ExpCmdG HsExpr
      	  CmdG :: ExpCmdG HsCmd
      
      	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
      
      	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
      	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
      	checkExp f = f ExpG  -- interpret as an expression
      	checkCmd f = f CmdG  -- interpret as a command
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/command ambiguity.
      
      Future work: apply the same principles to the expression/pattern
      ambiguity.
      e61f6e35
  18. 03 Feb, 2019 1 commit
  19. 20 Jan, 2019 1 commit
    • Matthew Pickering's avatar
      Remove TODO in HsExpr · 6e7aa5e9
      Matthew Pickering authored
      It is correct to be `GhcTc` as the data type is for expressions which are inside splices 
      so they can be delayed until desugaring. 
      6e7aa5e9
  20. 11 Jan, 2019 1 commit
    • Matthew Pickering's avatar
      Run typed splices in the zonker · c2455e64
      Matthew Pickering authored
      Summary:
      This fixes #15471
      
      In the typechecker we check that the splice has the right type but we
      crucially don't zonk the generated expression. This is because we might
      end up unifying type variables from outer scopes later on.
      
      Reviewers: simonpj, goldfire, bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15471
      
      Differential Revision: https://phabricator.haskell.org/D5286
      c2455e64
  21. 11 Dec, 2018 1 commit
  22. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  23. 14 Oct, 2018 1 commit
  24. 04 Oct, 2018 1 commit
    • Alec Theriault's avatar
      Allow (unparenthesized) kind signatures · bace26aa
      Alec Theriault authored
      Summary: This allows for things like `[t :: MyKind]`, `(a :: k, b)`, and so on.
      
      Test Plan: make TEST=T11622 && make TEST=T8708
      
      Reviewers: RyanGlScott, bgamari, simonpj, goldfire, alanz
      
      Reviewed By: RyanGlScott, simonpj
      
      Subscribers: alanz, simonpj, rwbarton, mpickering, carter
      
      GHC Trac Issues: #11622, #8708
      
      Differential Revision: https://phabricator.haskell.org/D5173
      bace26aa
  25. 23 Sep, 2018 2 commits
  26. 16 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15527 by pretty-printing an RdrName prefixly · 5238f204
      Ryan Scott authored
      Summary:
      When `(.) @Int` is used without enabling `TypeApplications`,
      the resulting error message will pretty-print the (symbolic)
      `RdrName` `(.)`. However, it does so without parenthesizing it, which
      causes the pretty-printed expression to appear as `.@Int`. Yuck.
      
      Since the expression in a type application will always be prefix,
      we can fix this issue by using `pprPrefixOcc` instead of plain ol'
      `ppr`.
      
      Test Plan: make test TEST=T15527
      
      Reviewers: bgamari, monoidal, simonpj
      
      Reviewed By: monoidal, simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15527
      
      Differential Revision: https://phabricator.haskell.org/D5071
      5238f204
  27. 20 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15423 by using pprAStmtContext · 99f45e2a
      Ryan Scott authored
      Summary:
      Previously, we were using `pprStmtContext` instead, which
      led to error messages missing indefinite articles where they were
      required.
      
      Test Plan: make test TEST="T13242a T7786 Typeable1"
      
      Reviewers: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15423
      
      Differential Revision: https://phabricator.haskell.org/D4992
      99f45e2a
  28. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  29. 14 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14875 by introducing PprPrec, and using it · 21e1a00c
      Ryan Scott authored
      Trying to determine when to insert parentheses during TH
      conversion is a bit of a mess. There is an assortment of functions
      that try to detect this, such as:
      
      * `hsExprNeedsParens`
      * `isCompoundHsType`
      * `hsPatNeedsParens`
      * `isCompoundPat`
      * etc.
      
      To make things worse, each of them have slightly different semantics.
      Plus, they don't work well in the presence of explicit type
      signatures, as #14875 demonstrates.
      
      All of these problems can be alleviated with the use of an explicit
      precedence argument (much like what `showsPrec` currently does). To
      accomplish this, I introduce a new `PprPrec` data type, and define
      standard predences for things like function application, infix
      operators, function arrows, and explicit type signatures (that last
      one is new). I then added `PprPrec` arguments to the various
      `-NeedsParens` functions, and use them to make smarter decisions
      about when things need to be parenthesized.
      
      A nice side effect is that functions like `isCompoundHsType` are
      now completely unneeded, since they're simply aliases for
      `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring
      to remove these sorts of functions. I also did a pass over various
      utility functions in GHC for constructing AST forms and used more
      appropriate precedences where convenient.
      
      Along the way, I also ripped out the existing `TyPrec`
      data type (which was tailor-made for pretty-printing `Type`s) and
      replaced it with `PprPrec` for consistency.
      
      Test Plan: make test TEST=T14875
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14875
      
      Differential Revision: https://phabricator.haskell.org/D4688
      21e1a00c
  30. 27 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG : complete for balance of hsSyn AST · c3823cba
      Alan Zimmerman authored
      Summary:
      - remove PostRn/PostTc fields
      - remove the HsVect In/Out distinction for Type, Class and Instance
      - remove PlaceHolder in favour of NoExt
      - Simplify OutputableX constraint
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4625
      c3823cba
  31. 13 Apr, 2018 1 commit
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  32. 09 Apr, 2018 1 commit
  33. 07 Apr, 2018 1 commit
  34. 13 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Drop GHC 8.0 compatibility · 152055a1
      Ryan Scott authored
      GHC 8.4.1 is out, so now GHC's support window only extends
      back to GHC 8.2. This means we can delete gobs of code that were
      only used for GHC 8.0 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: bgamari, erikd, dfeuer
      
      Reviewed By: bgamari, dfeuer
      
      Subscribers: alexbiehl, dfeuer, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4492
      152055a1
  35. 02 Mar, 2018 1 commit
  36. 21 Dec, 2017 1 commit
    • Ryan Scott's avatar
      Improve treatment of sectioned holes · 4d41e921
      Ryan Scott authored
      Summary:
      Previously, GHC was pretty-printing left-section holes
      incorrectly and not parsing right-sectioned holes at all. This patch
      fixes both problems.
      
      Test Plan: make test TEST=T14590
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #14590
      
      Differential Revision: https://phabricator.haskell.org/D4273
      4d41e921
  37. 18 Dec, 2017 1 commit
  38. 21 Nov, 2017 1 commit
    • Ben Gamari's avatar
      Revert "trees that grow" work · 314bc314
      Ben Gamari authored
      As documented in #14490, the Data instances currently blow up
      compilation time by too much to stomach. Alan will continue working on
      this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid
      having to perform painful cherry-picks in 8.2 minor releases.
      
      Reverts haddock submodule.
      
      This reverts commit 47ad6578.
      This reverts commit e3ec2e7a.
      This reverts commit 438dd1cb.
      This reverts commit 0ff152c9.
      314bc314