1. 17 Nov, 2015 2 commits
    • Tamar Christina's avatar
      Fix archive loading on Windows by the runtime loader · acce37f3
      Tamar Christina authored
      The runtime loader is unable to find archive files `.a` shipping
      with the inplace `GCC`.
      
      It seems the issue is caused by `findArchive` being unable to
      find any archives that are shipped using the in-place `GCC`.
      
      - It works on Linux because `findArchive` would search
        the standard Linux include path.
      - It works during compilation because `GCC` can find it's own libraries
        (we explicitly tell it where to look for libraries using the `gcc`
        wrapper around `realgcc`)
      
      So fixing the issue means using `searchForLibUsingGcc` in `findArchive`
      as well, which will then find the correct file.
      
      The reason for the error as it is, is because if we can't locate the
      library using any of the methods we have, we assume it is a system dll,
      or something on the system search path.  e.g. if trying to load
      `kernel32.dll`.
      
      There is a slight issue in that the `GHCi` code (incorrectly) favors
      `static archives` over `dynamic` ones
      
      ```
      findDll        `orElse`
      findArchive    `orElse`
      tryGcc         `orElse`
      tryGccPrefixed `orElse`
      assumeDll
      ```
      This has the unwanted effect of when `kernel32` is specified as a lib,
      it will try to load `kernel32.a` instead of `kernel32.dll`.
      
      To solve this I have added another search function that is able to
      search the Windows search paths using `SearchPath` in order to find if
      it is a dll on the system search path.
      
      The new search order is:
      
      ```
      findDll     `orElse`
      findSysDll  `orElse`
      tryGcc      `orElse`
      findArchive `orElse`
      assumeDll
      ```
      
      (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at
      top level)
      
      Test Plan: ./validate added new windows tests T3242
      
      Reviewers: thomie, erikd, hvr, austin, bgamari
      
      Reviewed By: thomie, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1455
      
      GHC Trac Issues: #3242
      acce37f3
    • Ben Gamari's avatar
      T9181: Fix testsuite output · 4e74ef96
      Ben Gamari authored
      I'm not really sure how this one snuck through my local validation. Hmm.
      4e74ef96
  2. 14 Nov, 2015 1 commit
  3. 13 Nov, 2015 2 commits
    • Simon Marlow's avatar
      Make 'error' include the CCS call stack when profiled · 8988be85
      Simon Marlow authored
      Summary:
      The idea here is that this gives a more detailed stack trace in two
      cases:
      
      1. With `-prof` and `-fprof-auto`
      2. In GHCi (see #11047)
      
      Example, with an error inserted in nofib/shootout/binary-trees:
      
      ```
      $ ./Main 3
      Main: z
      CallStack (from ImplicitParams):
        error, called at Main.hs:67:29 in main:Main
      CallStack (from -prof):
        Main.check' (Main.hs:(67,1)-(68,82))
        Main.check (Main.hs:63:1-21)
        Main.stretch (Main.hs:32:35-57)
        Main.main.c (Main.hs:32:9-57)
        Main.main (Main.hs:(27,1)-(43,42))
        Main.CAF (<entire-module>)
      ```
      
      This doesn't quite obsolete +RTS -xc, which also attempts to display
      more information in the case when the error is in a CAF, but I'm
      exploring other solutions to that.
      
      Includes submodule updates.
      
      Test Plan: validate
      
      Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1426
      8988be85
    • Joachim Breitner's avatar
      Give helpful advice when a fully qualified name is not in scope · e66f79df
      Joachim Breitner authored
      This implements #11071. It needs to thread through a GlobalRdrEnv
      corresponding to the export list of the module if its exports were not
      restricted.
      
      A refactoring of ImportedModsVal into a proper data type follows.
      
      Differential Revision: https://phabricator.haskell.org/D1462
      e66f79df
  4. 11 Nov, 2015 1 commit
  5. 08 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Fix sporadic failing ghci/Linker/Dyn tests · f4056324
      Tamar Christina authored
      Summary:
      Multiple tests use the same source C file.
      GHC was previously writing the resulting .o files
      in the same folder as the source. When these tests
      are run in parallel, sometimes one of the calls would
      use the partial .o file and throw an error.
      
      The .o files are moved into different folders with this
      change.
      
      Test Plan: make test -C testsuite/tests/ghci/linking/dyn
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1449
      f4056324
  6. 07 Nov, 2015 2 commits
    • Tamar Christina's avatar
      Allow the GHCi Linker to resolve related dependencies when loading DLLs · 6e6438e1
      Tamar Christina authored
      Summary:
      GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's
      that are not on the standard Windows load path:
      
      1. The directory from which the application loaded.
      2. The current directory.
      3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
      4. The 16-bit system directory. There is no function that obtains the path of this directory,
         but it is searched.
      5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
      6. The directories that are listed in the PATH environment variable.
         Note that this does not include the per-application path specified by the
         AppPaths registry key. The App Paths key is not used when computing the DLL search path.
      
      So what this means is given two DLLs `A` and `B` and `B` depending on `A`.
      If we put both DLLs into a new folder bin and then call GHC with:
      
      `ghc -L$(PWD)/bin -lB`
      
      the loading will fail as the Windows loader will try to load the dependency of `B` and fail
      since it cannot find `A`.
      
      *IMPORTANT* this patch drops XP Support.
      The  APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista
      via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has
      not been installed on certain machines. For those machines I display a warning and
      temporarily expand the `PATH` to allow it to load.
      
      This patch will make sure that paths provided by the user with `-L` *and* the folder in which a
      DLL is found are added to the search path. It does so using one of two methods depending upon how
      new of a Windows version we are running on:
      
      - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`.
         The order of which these directories are searched is nondeterministic.
      - If the APIs are not available it means that we're running on a pretty old unpatched machine.
        But if it's being used in an environment with no internet access it may be the case.
        So if the APIs are not available we temporarily extend the `PATH` with the directories.
        A warning is also displayed to the user informing them that the linking may fail,
        and if it does, install the needed patch. The `PATH` variable has limitations.
      
      Test Plan:
      ./validate
      
      Added two new test T10955 and T10955dyn
      
      Reviewers: erikd, bgamari, thomie, hvr, austin
      
      Reviewed By: erikd, thomie
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1340
      
      GHC Trac Issues: #10955
      6e6438e1
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  7. 01 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.9.0.0 (closes #11026) · f8ba4b55
      Herbert Valerio Riedel authored
      This also relaxes a few upper bounds on base in the ghc.git repo;
      
      This required a mass-rewrite in testsuite/
      
        sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')
      
      because it turns out the testsuite is still sensitive to package version
      changes.
      f8ba4b55
  8. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  9. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  10. 28 Oct, 2015 1 commit
    • Simon Peyton Jones's avatar
      Pattern synonyms: swap provided/required · 04b0a73a
      Simon Peyton Jones authored
      This patch swaps the order of provided and required constraints in
      a pattern signature, so it now goes
      
            pattern P :: req => prov => t1 -> ... tn -> res_ty
      
      See the long discussion in Trac #10928.
      
      I think I have found all the places, but I could have missed something
      particularly in comments.
      
      There is a Haddock changes; so a submodule update.
      04b0a73a
  11. 22 Oct, 2015 2 commits
  12. 15 Oct, 2015 2 commits
    • Simon Marlow's avatar
      ELF/x86_64: map object file sections separately into the low 2GB · 04e83666
      Simon Marlow authored
      On 64-bit ELF we need to link object files into the low 2GB due to the
      small memory model.  Previously we would map the entire object file
      using MAP_32BIT, but the object file can consist of 75% or more
      symbols, which only need to be present during linking, so this is
      wasteful.  In our particular application, we're already running out of
      space here.
      
      This patch changes the way we load object files on ELF platforms so
      that the object is first mapped above the 2GB boundary, parsed, and
      then the important sections are re-mapped into the low 2GB area.
      
      Test Plan:
      validate
      (also needs testing on OS X & Windows, preferably 32 & 64 bit)
      
      Reviewers: Phyx, trommler, bgamari, austin
      
      Subscribers: hsyl20, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D975
      04e83666
    • Edward Z. Yang's avatar
      Update Cabal to HEAD, IPID renamed to Component ID. · 5b0191f7
      Edward Z. Yang authored
      This commit contains a Cabal submodule update which unifies installed
      package IDs and package keys under a single notion, a Component ID.
      We update GHC to keep follow this unification.  However, this commit
      does NOT rename installed package ID to component ID and package key to
      unit ID; the plan is to do that in a companion commit.
      
          - Compiler info now has "Requires unified installed package IDs"
      
          - 'exposed' is now expected to contain unit keys, not IPIDs.
      
          - Shadowing is no more.  We now just have a very simple strategy
            to deal with duplicate unit keys in combined package databases:
            if their ABIs are the same, use the latest one; otherwise error.
            Package databases maintain the invariant that there can only
            be one entry of a unit ID.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr, goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1184
      
      GHC Trac Issues: #10714
      5b0191f7
  13. 10 Oct, 2015 2 commits
  14. 08 Oct, 2015 1 commit
  15. 21 Sep, 2015 1 commit
  16. 19 Sep, 2015 2 commits
    • eir@cis.upenn.edu's avatar
      Polish some error messages. · 8ee2b953
      eir@cis.upenn.edu authored
      8ee2b953
    • eir@cis.upenn.edu's avatar
      Fix #10815 by kind-checking type patterns against known kinds. · 2d4db40a
      eir@cis.upenn.edu authored
      tcFamTyPats now must take information about the instantiation of any
      class variables, when checking the instance of an associated type.
      
      Getting this to work out required some unexpected refactoring in
      TcDeriv. TcDeriv needs to look at class instances because of the
      possibility of associated datatypes with `deriving` specs. TcDeriv
      worked over the user-specified instances. But any data family instances
      were already processed, and TcDeriv had no way of finding the rep
      tycons. Indeed, TcDeriv *re-type-checked* any data family instances
      in an attempt to rediscover what GHC already knew. So, this commit
      introduces better tracking of compiled data families between TcInstDcls
      and TcDeriv to streamline all of this.
      2d4db40a
  17. 17 Sep, 2015 1 commit
  18. 15 Sep, 2015 1 commit
    • Sebastian Reuße's avatar
      Pretty: fix unicode arrow operators. · 14c4090e
      Sebastian Reuße authored
      As per issue #10509, the documentation gave the wrong glyphs for Unicode
      alternatives to the -< and >- arrow operators (the codepoints were
      correct, but the glyphs were not). The incorrect glyphs have also
      made it into the error output. This replaces those characters with the
      correct versions.
      
      GHC Trac Issues: #10883
      14c4090e
  19. 03 Sep, 2015 1 commit
  20. 02 Sep, 2015 3 commits
    • thomie's avatar
      Testsuite: update expected output · e0b3ff0f
      thomie authored
      e0b3ff0f
    • Simon Peyton Jones's avatar
      Improve the error messages for class instance errors · 28ac9d31
      Simon Peyton Jones authored
      Summary: See Note [Displaying potential instances].
      
      Reviewers: austin
      
      Subscribers: KaneTW, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1176
      28ac9d31
    • Eric Seidel's avatar
      Use IP based CallStack in error and undefined · 6740d70d
      Eric Seidel authored
      This patch modifies `error`, `undefined`, and `assertError` to use
      implicit call-stacks to provide better error messages to users.
      
      There are a few knock-on effects:
      
      - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
        types for `error` and `undefined`.
      
      - `TysPrim.tyVarList` has been replaced with a new function
        `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
        subtle bugs when you need tyvars of different kinds. The naive
      
        ```
        tv1 = head $ tyVarList kind1
        tv2 = head $ tyVarList kind2
        ```
      
        would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
        would be applied incorrectly, treating `tv1` and `tv2` as the same
        tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
        and producing a single tyvar of each kind.
      
      - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
        ghc-prim.
      
      - The type `GHC.Exception.ErrorCall` has a new constructor
        `ErrorCallWithLocation` that takes two `String`s instead of one, the
        2nd one being arbitrary metadata about the error (but usually the
        call-stack). A bi-directional pattern synonym `ErrorCall` continues to
        provide the old API.
      
      Updates Cabal, array, and haddock submodules.
      
      Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
      liyang, bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D861
      
      GHC Trac Issues: #5273
      6740d70d
  21. 12 Aug, 2015 1 commit
    • Tamar Christina's avatar
      Upgrade GCC to 5.2.0 for Windows x86 and x86_64 · 7b211b4e
      Tamar Christina authored
      This patch does a few things
      
      - Moved GHC x86 to MinGW-w64 (Using Awson's patch)
      - Moves Both GHCs to MSYS2 toolchains
      - Completely removes the dependencies on the git tarball repo
        - Downloads only the required tarball for the architecture for
          which we are building
        - Downloads the perl tarball is missing as well
        - Fixed a few bugs in the linker to fix tests on Windows
      
      The links currently point to repo.msys2.org and GitHub, it might be
      more desirable to mirror them on
      http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
      attempt.
      
      For more details on what the MSYS2 packages I include see #10726
      (Awson's comment). but it should contain all we need
      and no python or fortran, which makes the uncompressed tar a 1-2
      hundreds mb smaller.
      
      The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
      this is a problem since
      when compiling with -shared the produced dll now has a dependency on
      `libgcc_s_sjlj-1.dll`.
      To solve this the flag `-static-libgcc` is now being used for all GCC
      calls on windows.
      
      Test Plan:
      ./validate was ran both on x86 and x86_64 windows and compared against
      the baseline.
      
      A few test were failing due to Ld no longer being noisy. These were
      updated.
      
      The changes to the configure script *should* be validated by the build
      bots for the other platforms before landing
      
      Reviewers: simonmar, awson, bgamari, austin, thomie
      
      Reviewed By: thomie
      
      Subscribers: #ghc_windows_task_force, thomie, awson
      
      Differential Revision: https://phabricator.haskell.org/D1123
      
      GHC Trac Issues: #10726, #9014, #9218, #10435
      7b211b4e
  22. 06 Aug, 2015 1 commit
    • Ben Gamari's avatar
      Ensure DynFlags are consistent · eca9a1a1
      Ben Gamari authored
      While we have always had makeDynFlagsConsistent to enforce a variety of
      consistency invariants on DynFlags, it hasn't been widely used.
      GHC.Main, for instance, ignored it entirely. This leads to issues like
      Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency,
      leading to a perplexing crash later in compilation.
      
      Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags,
      closing this hole.
      
      Fixes #10549.
      
      Test Plan: Validate with T10549
      
      Reviewers: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1128
      
      GHC Trac Issues: #10549
      eca9a1a1
  23. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Tidy up and refactor wildcard handling · 95364812
      Simon Peyton Jones authored
      When examining #10615, I found the wildcard handling hard
      to understand.  This patch refactors quite a bit, but with
      no real change in behaviour.
      
       * Split out TcIdSigInfo from TcSigInfo, as a separate type,
         like TcPatSynInfo.
      
       * Make TcIdSigInfo express more invariants by pushing the
         wildard info into TcIdSigBndr
      
       * Remove all special treatment of unification variables that arise
         from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
         argument.
      
      A ton of konck on changes.  The result is significantly simpler, I think.
      95364812
  24. 24 Jul, 2015 1 commit
  25. 23 Jul, 2015 1 commit
    • thomie's avatar
      ghci: fixity declarations for infix data constructors (#10018) · e809ef57
      thomie authored
      Declaring a custom fixity for an infix data constructor should work:
      
          Prelude> data Infix a b = a :@: b; infixl 4 :@:
      
      This is a followup to #2947, which handled fixity declarations in ghci
      statements (e.g. let add = (+); infixl 6 `add`).
      
      Support for declarations (data, type, newtype, class, instance,
      deriving, and foreign) was added to GHCi in #4929.
      
      Reviewers: simonpj, austin, thomie
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1028
      
      GHC Trac Issues: #10018
      e809ef57
  26. 16 Jul, 2015 1 commit
  27. 14 Jul, 2015 1 commit
  28. 13 Jul, 2015 1 commit
  29. 04 Jul, 2015 2 commits