1. 17 Nov, 2015 1 commit
  2. 13 Nov, 2015 1 commit
    • Alan Zimmerman's avatar
      APIAnnotations:add Locations in hsSyn for layout · 2290c8bd
      Alan Zimmerman authored
      Summary:
      At the moment ghc-exactprint, which uses the GHC API Annotations to
      provide a framework for roundtripping Haskell source code with optional
      AST edits, has to implement a horrible workaround to manage the points
      where layout needs to be captured.
      
      These are
      
          MatchGroup
          HsDo
          HsCmdDo
          HsLet
          LetStmt
          HsCmdLet
          GRHSs
      
      To provide a more natural representation, the contents subject to layout
      rules need to be wrapped in a SrcSpan.
      
      This commit does this.
      
      Trac ticket #10250
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari, austin, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1370
      
      GHC Trac Issues: #10250
      2290c8bd
  3. 07 Nov, 2015 1 commit
    • Matthew Pickering's avatar
      Remove PatSynBuilderId · 22080113
      Matthew Pickering authored
      Summary:
      It was only used to pass field labels between the typechecker and
      desugarer. Instead we add an extra field the RecordCon to carry this
      information.
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1443
      
      GHC Trac Issues: #11057
      22080113
  4. 30 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Disambiguate record selectors by type signature · 0a163741
      Adam Gundry authored
      This makes DuplicateRecordFields more liberal in when it will
      accept ambiguous record selectors, making use of type information in a
      similar way to updates. See Note [Disambiguating record fields] for more
      details. I've also refactored how record updates are disambiguated.
      
      Test Plan: New and amended tests in overloadedrecflds
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1391
      0a163741
  5. 29 Oct, 2015 1 commit
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      
      === Interaction with Duplicate Record Fields ===
      
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      
      Consider the following module:
      
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
      
          module Main where
      
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
      
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      
      (example due to Adam Gundry)
      
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      
      Consider the following
      
      ```
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      
      f1 = a [5] -- 5
      
      f2 = [5] {a = 6} -- currently [6,6]
      ```
      
      === Fixing Polymorphic Updates ===
      
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      
      ```
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      ```
      
      === Mixed selectors error ===
      
      Note [Mixed Record Field Updates]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Consider the following pattern synonym.
      
          data MyRec = MyRec { foo :: Int, qux :: String }
      
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      
      This allows updates such as the following
      
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      
      It would also make sense to allow the following update (which we
      reject).
      
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
      
          updater a = a {f1 = 1, foo = 2} ==? ???
      
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
      
          updater a = (a {f1 = 1}) {foo = 2}
      
          > updater (MyRec 0 "str")
          MyRec 2 "str"
      2a74a64e
  6. 16 Oct, 2015 2 commits
    • Jan Stolarek's avatar
      Add typed holes support in Template Haskell. · 75492e74
      Jan Stolarek authored
      Fixes #10267. Typed holes in typed Template Haskell currently don't work.
      See #10945 and #10946.
      75492e74
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  7. 15 Oct, 2015 1 commit
  8. 21 Sep, 2015 1 commit
  9. 17 Sep, 2015 1 commit
  10. 03 Sep, 2015 1 commit
  11. 27 Jul, 2015 1 commit
    • Adam Sandberg Eriksson's avatar
      Implementation of StrictData language extension · f842ad6c
      Adam Sandberg Eriksson authored
      This implements the `StrictData` language extension, which lets the
      programmer default to strict data fields in datatype declarations on a
      per-module basis.
      
      Specification and motivation can be found at
      https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
      
      This includes a tricky parser change due to conflicts regarding `~` in
      the type level syntax: all ~'s are parsed as strictness annotations (see
      `strict_mark` in Parser.y) and then turned into equality constraints at
      the appropriate places using `RdrHsSyn.splitTilde`.
      
      Updates haddock submodule.
      
      Test Plan: Validate through Harbormaster.
      
      Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari
      
      Reviewed By: simonpj, tibbe, bgamari
      
      Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1033
      
      GHC Trac Issues: #8347
      f842ad6c
  12. 20 Jul, 2015 2 commits
    • Luite Stegeman's avatar
      Do not treat prim and javascript imports as C imports in TH and QQ · 4cd008b6
      Luite Stegeman authored
      Reviewers: austin, hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1070
      
      GHC Trac Issues: #10638
      4cd008b6
    • thomasw's avatar
      Support wild cards in TH splices · 49373ffe
      thomasw authored
      - Declaration splices: partial type signatures are fully supported in TH
        declaration splices.
      
        For example, the wild cards in the example below will unify with `Eq
      a`
        and `a -> a -> Bool`, as expected:
      
      ```
      [d| foo :: _ => _
          foo x y = x == y |]
      ```
      
      - Expression splices: anonymous and named wild cards are supported in
        expression signatures, but extra-constraints wild cards aren't. Just
        as is the case for regular expression signatures.
      
      ```
      [e | Just True :: _a _ |]
      ```
      
      - Typed expression splices: the same wildcards as in (untyped)
        expression splices are supported.
      
      - Pattern splices: TH doesn't support type signatures in pattern
        splices, consequently, partial type signatures aren't supported
        either.
      
      - Type splices: partial type signatures are only partially supported in
        type splices, specifically: only anonymous wild cards are allowed.
      
        So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
        `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
        the named wild card is treated as a type variable).
      
        Normally, named wild cards are collected before renaming a (partial)
        type signature. However, TH type splices are run during renaming, i.e.
        after the initial traversal, leading to out of scope errors for named
        wild cards. We can't just extend the initial traversal to collect the
        named wild cards in TH type splices, as we'd need to expand them,
        which is supposed to happen only once, during renaming.
      
        Similarly, the extra-constraints wild card is handled right before
        renaming too, and is therefore also not supported in a TH type splice.
        Another reason not to support extra-constraints wild cards in TH type
        splices is that a single signature can contain many TH type splices,
        whereas it mustn't contain more than one extra-constraints wild card.
        Enforcing would this be hard the way things are currently organised.
      
        Anonymous wild cards pose no problem, because they start without names
        and are given names during renaming. These names are collected right
        after renaming. The names generated for anonymous wild cards in TH
        type splices will thus be collected as well.
      
        With a more invasive refactoring of the renaming, partial type
        signatures could be fully supported in TH type splices. As only
        anonymous wild cards have been requested so far, these small changes
        satisfying this request will do for now. Also don't forget that a TH
        declaration splices support all kinds of wild cards.
      
      - Extra-constraints wild cards were silently ignored in expression and
        pattern signatures, appropriate error messages are now generated.
      
      Test Plan: run new tests
      
      Reviewers: austin, goldfire, adamgundry, bgamari
      
      Reviewed By: goldfire, adamgundry, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1048
      
      GHC Trac Issues: #10094, #10548
      49373ffe
  13. 16 Jul, 2015 1 commit
    • RyanGlScott's avatar
      Handle Char#, Addr# in TH quasiquoter (fixes #10620) · 2c9de9c9
      RyanGlScott authored
      DsMeta does not attempt to handle quasiquoted Char# or Addr# values,
      which causes expressions like `$([| 'a'# |])` or `$([| "abc"# |])` to
      fail
      with an `Exotic literal not (yet) handled by Template Haskell` error.
      
      To fix this, the API of `template-haskell` had to be changed so that
      `Lit`
      now has an extra constructor `CharPrimL` (a `StringPrimL` constructor
      already
      existed, but it wasn't used). In addition, `DsMeta` has to manipulate
      `CoreExpr`s directly that involve `Word8`s. In order to do this,
      `Word8` had
      to be added as a wired-in type to `TysWiredIn`.
      
      Actually converting from `HsCharPrim` and `HsStringPrim` to `CharPrimL`
      and
      `StringPrimL`, respectively, is pretty straightforward after that, since
      both `HsCharPrim` and `CharPrimL` use `Char` internally, and
      `HsStringPrim`
      uses a `ByteString` internally, which can easily be converted to
      `[Word8]`,
      which is what `StringPrimL` uses.
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1054
      
      GHC Trac Issues: #10620
      2c9de9c9
  14. 09 Jun, 2015 1 commit
    • thomasw's avatar
      Refactor wild card renaming · 058af6c9
      thomasw authored
      Summary:
      Refactor wild card error reporting
      
      * Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor
        `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two
        constructors: `AnonWildCard` and `NamedWildCard`.
      
      * All partial type checks are removed from `RdrHsSyn.hs` and are now done
        during renaming in order to report better error messages. When wild cards
        are allowed in a type, the new function `rnLHsTypeWithWildCards` (or
        `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild
        cards into scope before renaming them. When this is not done, renaming will
        trigger "Unexpected wild card..." errors.
      
        Unfortunately, this has to be done separately for anonymous wild cards
        because they are given a fresh name during renaming, so they will not cause
        an out-of-scope error. They are handled in `tc_hs_type`, as a special case
        of a lookup that fails.
      
        The previous opt-out approach is replaced with an opt-in approach. No more
        panics because of forgotten checks!
      
      * `[t| _ |]` isn't caught by the above two checks, so it is currently handled
        by a special case. The error message (generated in the `DsM` monad) doesn't
        provide as much context information as the other cases.
      
      * Instead of three (!) functions that walk `HsType`, there is now only one
        pure function called `collectWildCards`.
      
      * Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking
        at the `HsDocContext`. This will reduce the number of places to catch
        unwanted wild cards form three to one, and make the error messages more
        uniform, albeit less informative, as the error context for renaming is not
        as informative as the one for type checking. A new constructor of
        `HsDocContext` will be required for pattern synonyms signatures.
      
        Small problem: currently type-class type signatures can't be distinguished
        from type signatures using the `HsDocContext`.
      
      This requires an update to the Haddock submodule.
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: bgamari, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D613
      
      GHC Trac Issues: #10098
      058af6c9
  15. 01 Jun, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations : strings in warnings do not return SourceText · e6191d1c
      Alan Zimmerman authored
      Summary:
      The strings used in a WARNING pragma are captured via
      
          strings :: { Located ([AddAnn],[Located FastString]) }
              : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) }
          ..
      
      The STRING token has a method getSTRINGs that returns the original
      source text for a string.
      
      A warning of the form
      
          {-# WARNING Logic
                    , mkSolver
                    , mkSimpleSolver
                    , mkSolverForLogic
                    , solverSetParams
                    , solverPush
                    , solverPop
                    , solverReset
                    , solverGetNumScopes
                    , solverAssertCnstr
                    , solverAssertAndTrack
                    , solverCheck
                    , solverCheckAndGetModel
                    , solverGetReasonUnknown
                    "New Z3 API support is still incomplete and fragile: \
                    \you may experience segmentation faults!"
            #-}
      
      returns the concatenated warning string rather than the original source.
      
      This patch now deals with all remaining instances of getSTRING to bring
      in a SourceText for each.
      
      This updates the haddock submodule as well, for the AST change.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire
      
      Reviewed By: austin
      
      Subscribers: bgamari, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D907
      
      GHC Trac Issues: #10313
      e6191d1c
  16. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  17. 14 May, 2015 1 commit
  18. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  19. 06 May, 2015 2 commits
  20. 04 May, 2015 1 commit
    • Adam Gundry's avatar
      Permit empty closed type families · 4efa4213
      Adam Gundry authored
      Fixes #9840 and #10306, and includes an alternative resolution to #8028.
      This permits empty closed type families, and documents them in the user
      guide. It updates the Haddock submodule to support the API change.
      
      Test Plan: Added `indexed-types/should_compile/T9840` and updated
      `indexed-types/should_fail/ClosedFam4` and `th/T8028`.
      
      Reviewers: austin, simonpj, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: bgamari, jstolarek, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D841
      
      GHC Trac Issues: #9840, #10306
      4efa4213
  21. 10 Feb, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor the handling of quasi-quotes · f46360ed
      Simon Peyton Jones authored
      As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed
      to behave exactly like $(n "...blah...").  But it doesn't!  This was outright
      wrong: quasiquotes were being run even inside brackets.
      
      Now that TH supports both typed and untyped splices, a quasi-quote is properly
      regarded as a particular syntax for an untyped splice. But apart from that
      they should be treated the same.  So this patch refactors the handling of
      quasiquotes to do just that.
      
      The changes touch quite a lot of files, but mostly in a routine way.
      The biggest changes by far are in RnSplice, and more minor changes in
      TcSplice.  These are the places where there was real work to be done.
      Everything else is routine knock-on changes.
      
      * No more QuasiQuote forms in declarations, expressions, types, etc.
        So we get rid of these data constructors
          * HsBinds.QuasiQuoteD
          * HsExpr.HsSpliceE
          * HsPat.QuasiQuotePat
          * HsType.HsQuasiQuoteTy
      
      * We get rid of the HsQuasiQuote type altogether
      
      * Instead, we augment the HsExpr.HsSplice type to have three
        consructors, for the three types of splice:
          * HsTypedSplice
          * HsUntypedSplice
          * HsQuasiQuote
        There are some related changes in the data types in HsExpr near HsSplice.
        Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour.
      
      * In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one.
        A smaller, clearer interface.
      
      * We have to update the Haddock submodule, to accommodate the hsSyn changes
      f46360ed
  22. 16 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations tweaks. · 11881ec6
      Alan Zimmerman authored
      Summary:
      HsTyLit now has SourceText
      
      Update documentation of HsSyn to reflect which annotations are attached to which element.
      
      Ensure that the parser always keeps HsSCC and HsTickPragma values, to
      be ignored in the desugar phase if not needed
      
      Bringing in SourceText for pragmas
      
      Add Location in NPlusKPat
      
      Add Location in FunDep
      
      Make RecCon payload Located
      
      Explicitly add AnnVal to RdrName where it is compound
      
      Add Location in IPBind
      
      Add Location to name in IEThingAbs
      
      Add Maybe (Located id,Bool) to Match to track fun_id,infix
        This includes converting Match into a record and adding a note about why
        the fun_id needs to be replicated in the Match.
      
      Add Location in KindedTyVar
      
      Sort out semi-colons for parsing
      
        - import statements
        - stmts
        - decls
        - decls_cls
        - decls_inst
      
      This updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D538
      11881ec6
  23. 08 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve HsBang · 9564bb8c
      Simon Peyton Jones authored
      Provoked by questions from Johan
      
       - Improve comments, fix misleading stuff
       - Add commented synonyms for HsSrcBang, HsImplBang, and use them throughout
       - Rename HsUserBang to HsSrcBang
       - Rename dataConStrictMarks to dataConSrcBangs
                dataConRepBangs    to dataConImplBangs
      
      This renaming affects Haddock in a trivial way, hence submodule update
      9564bb8c
  24. 15 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix dll-split problem with patch 'Make Core Lint check for locally-bound GlobalId' · 3f87866a
      Simon Peyton Jones authored
      The trouble was that my changes made a lot more files transitively link with
      DynFlags, which is the root module for the revolting Windows dll-split stuff.
      
      Anyway this patch fixes it, in a good way:
      
       - Make GHC/Hooks *not* import DsMonad, because DsMonad imports too
         much other stuff (notably tcLookup variants).  Really, Hooks depends
         only on *types* not *code*.
      
       - To do this I need the DsM type, and the types it depends on,
         not to be part of DsMonad.  So I moved it to TcRnTypes, which is
         where the similar pieces for the TcM and IfM monads live.
      
       - We can then delete DsMonad.hs-boot
      
       - There are a bunch of knock-on change, of no great significance
      3f87866a
  25. 10 Dec, 2014 1 commit
  26. 28 Nov, 2014 1 commit
  27. 21 Nov, 2014 2 commits
  28. 20 Nov, 2014 1 commit
  29. 12 Nov, 2014 2 commits
  30. 04 Nov, 2014 1 commit
  31. 02 Nov, 2014 2 commits
  32. 07 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      When desugaring Use the smart mkCoreConApps and friends · 1fc60ea1
      Simon Peyton Jones authored
      This is actually the bug that triggered Trac #9390.  We had
      an unboxed tuple (# writeArray# ..., () #), and that writeArray#
      argument isn't ok-for-speculation, so disobeys the invariant.
      
      The desugaring of unboxed tuples was to blame; the fix is easy.
      1fc60ea1
  33. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  34. 15 Jul, 2014 1 commit
    • Simon Peyton Jones's avatar
      Entirely re-jig the handling of default type-family instances (fixes Trac #9063) · 9b8ba629
      Simon Peyton Jones authored
      In looking at Trac #9063 I decided to re-design the default
      instances for associated type synonyms.  Previously it was all
      jolly complicated, to support generality that no one wanted, and
      was arguably undesirable.
      
      Specifically
      
      * The default instance for an associated type can have only
        type variables on the LHS.  (Not type patterns.)
      
      * There can be at most one default instances declaration for
        each associated type.
      
      To achieve this I had to do a surprisingly large amount of refactoring
      of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type
      of the LHS patterns.
      
      That change in HsDecls has a (trivial) knock-on effect in Haddock, so
      this commit does a submodule update too.
      
      The net result is good though.  The code is simpler; the language
      specification is simpler.  Happy days.
      
      Trac #9263 and #9264 are thereby fixed as well.
      9b8ba629