1. 17 Nov, 2015 1 commit
    • 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
  2. 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
  3. 15 Oct, 2015 2 commits
  4. 10 Oct, 2015 1 commit
  5. 21 Sep, 2015 1 commit
  6. 22 Jul, 2015 1 commit
  7. 21 Jul, 2015 1 commit
  8. 11 Jun, 2015 1 commit
  9. 01 Jun, 2015 1 commit
  10. 19 May, 2015 2 commits
  11. 07 Apr, 2015 1 commit
    • Edward Z. Yang's avatar
      Support for multiple signature files in scope. · a7524eae
      Edward Z. Yang authored
      Summary:
      A common pattern when programming with signatures is to combine multiple
      signatures together (signature linking).  We achieve this by making it
      not-an-error to have multiple, distinct interface files for the same module
      name, as long as they have the same backing implementation.  When a user
      imports a module name, they get ALL matching signatures dumped into their
      scope.
      
      On the way, I refactored the module finder code, which now distinguishes
      between exact finds (when you had a 'Module') and regular finds (when
      you had a 'ModuleName').  I also refactored the package finder code to
      use a Monoid instance on LookupResult to collect together various results.
      
      ToDo: At the moment, if a signature is declared in the local package,
      it completely overrides any remote signatures.  Eventually, we'll want
      to also pull in the remote signatures (or even override the local signature,
      if the full implementation is available.)  There are bunch of ToDos in the
      code for what to do once this is done.
      
      ToDo: At the moment, whenever a module name lookup occurs in GHCi and we
      would have seen a signature, we instead continue and return the Module
      for the backing implementation.  This is correct for most cases, but there
      might be some situations where we want something a little more fine-grained
      (e.g. :browse should only list identifiers which are available through
      the in-scope signatures, and not ALL of them.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, hvr, austin
      
      Subscribers: carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D790
      
      GHC Trac Issues: #9252
      a7524eae
  12. 19 Mar, 2015 2 commits
  13. 07 Mar, 2015 1 commit
  14. 10 Feb, 2015 1 commit
  15. 06 Jan, 2015 1 commit
  16. 29 Dec, 2014 1 commit
    • Peter Trommler's avatar
      Fix system linker on Mac OS X · b32c2276
      Peter Trommler authored
      Summary:
      Flag `-l:` is GNU ld specific and not supported by the
      Mac OS X link editor. So we create a temporary file name
      lib<tmpname>.<so_ext> and link with the standard -l<tmpname>
      option on Linux and OS X.
      
      Fixes #9875
      
      Test Plan: validate on Mac OS X
      
      Reviewers: austin, hvr, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: carter, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D579
      
      GHC Trac Issues: #9875
      b32c2276
  17. 20 Dec, 2014 1 commit
  18. 30 Nov, 2014 1 commit
    • Peter Trommler's avatar
      Fix obscure problem with using the system linker (#8935) · 383733b9
      Peter Trommler authored
      Summary:
      In a statically linked GHCi symbol `environ` resolves to NULL when
      called from a Haskell script.
      
      When resolving symbols in a Haskell script we need to search the
      executable program and its dependent (DT_NEEDED) shared libraries
      first and then search the loaded libraries.
      
      We want to be able to override functions in loaded libraries later.
      Libraries must be opened with local scope (RTLD_LOCAL) and not global.
      The latter adds all symbols to the executable program's symbols where
      they are then searched in loading order. We want reverse loading order.
      
      When libraries are loaded with local scope the dynamic linker
      cannot use symbols in that library when resolving the dependencies
      in another shared library. This changes the way files compiled to
      object code must be linked into temporary shared libraries. We link
      with the last temporary shared library created so far if it exists.
      Since each temporary shared library is linked to the previous temporary
      shared library the dynamic linker finds the latest definition of a
      symbol by following the dependency chain.
      
      See also Note [RTLD_LOCAL] for a summary of the problem and solution.
      
      Cherry-picked commit 2f8b4c
      
      Changed linker argument ordering
      
      On some ELF systems GNU ld (and others?) default to
      --as-needed and the order of libraries in the link
      matters.
      
      The last temporary shared library, must appear
      before all other libraries. Switching the position
      of extra_ld_inputs and lib_path_objs does that.
      
      Fixes #8935 and #9186
      
      Reviewers: austin, hvr, rwbarton, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D349
      
      GHC Trac Issues: #8935, #9186, #9480
      383733b9
  19. 28 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename some of the functions in NameSet, to make the uniform with VarSet etc · 7460dafa
      Simon Peyton Jones authored
      For ages NameSet has used different names,
        eg.   addOneToNameSet   rather than    extendNameSet
              nameSetToList     rather than    nameSetElems
      
      etc.  Other set-like modules use uniform naming conventions.
      This patch makes NameSet follow suit.
      
      No change in behaviour; this is just renaming.
      
      I'm doing this just before the fork so that merging is easier.
      7460dafa
  20. 30 Oct, 2014 1 commit
  21. 24 Sep, 2014 1 commit
  22. 20 Sep, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Change linker message verbosity to `-v2` (re #7863) · 9f7e3633
      Herbert Valerio Riedel authored
      With this change, the linker status logging output such as
      
          Loading package ghc-prim ... linking ... done.
          Loading package integer-gmp ... linking ... done.
          Loading package base ... linking ... done.
      
      is suppressed unless verbosity level is `-v2` or higher. This is done
      to reduce the compiler message noise when TH is involved, which can
      reduce the visibiliy of compile warnings.
      
      Reviewed By: ekmett, austin
      
      Differential Revision: https://phabricator.haskell.org/D232
      9f7e3633
  23. 16 Sep, 2014 1 commit
  24. 29 Aug, 2014 3 commits
  25. 19 Aug, 2014 1 commit
    • Austin Seipp's avatar
      build: require GHC 7.6 for bootstrapping · 527bcc41
      Austin Seipp authored
      Summary:
      Per the usual standards, a build of GHC is only compileable
      by the last two releases (e.g. 7.8 only by 7.4 and 7.6). To make sure
      we don't get suckered into supporting older compilers, let's remove
      this support now.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan:
      Try to bootstrap with GHC 7.4, watch it fail. Bootstrap
      with 7.6 or better, and everything works.
      
      Reviewers: hvr
      
      Reviewed By: hvr
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D167
      527bcc41
  26. 05 Aug, 2014 2 commits
    • Edward Z. Yang's avatar
      Make PackageState an abstract type. · de3f0644
      Edward Z. Yang authored
      Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D107
      de3f0644
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      explosion.
      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/D80
      66218d15
  27. 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
  28. 14 Jul, 2014 1 commit
    • kgardas's avatar
      add support for x86_64-solaris2 platform · 6da60321
      kgardas authored
      Summary:
      this set of patches adds support for x86_64-solaris2 platform
      Solaris is multi-lib platform which means it provides 32bit user-land together
      with 32bit and 64bit libraries. The 32bit libraries are located in <somewhere>/lib
      directories while 64bit libraries are located in <somewhere>/lib/64 directories.
      This is why GHCi required the fix since otherwise it'll attempt to load
      /usr/lib/libgmp.so which is 32bit library into 64bit binary process space (GHCi).
      This of course fails with wrong ELFCLASS32 error message.
      Another issue was that by default GNU C distributed with Solaris compiles
      into 32bit binary. We need to enforce compilation to 64bit binary
      by adding appropriate -m64 option.
      
      Test Plan: already built on x86_64-solaris2
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: phaskell, simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D68
      6da60321
  29. 30 Jun, 2014 1 commit
  30. 08 Jun, 2014 1 commit
  31. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  32. 17 Feb, 2014 1 commit
    • Austin Seipp's avatar
      Fix #8770 · dc080915
      Austin Seipp authored
      As usual, Mac OS X is extremely annoying (or the software is, anyway),
      because not only does it load dynamic libraries with the .dylib
      extension, but also the .so extension. For whatever reason. At least
      it's easy to fix.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      dc080915
  33. 09 Jan, 2014 1 commit
    • Simon Peyton Jones's avatar
      Re-work the naming story for the GHCi prompt (Trac #8649) · 73c08ab1
      Simon Peyton Jones authored
      The basic idea here is simple, and described in Note [The interactive package]
      in HscTypes, which starts thus:
      
          Note [The interactive package]
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          Type and class declarations at the command prompt are treated as if
          they were defined in modules
             interactive:Ghci1
             interactive:Ghci2
             ...etc...
          with each bunch of declarations using a new module, all sharing a
          common package 'interactive' (see Module.interactivePackageId, and
          PrelNames.mkInteractiveModule).
      
          This scheme deals well with shadowing.  For example:
      
             ghci> data T = A
             ghci> data T = B
             ghci> :i A
             data Ghci1.T = A  -- Defined at <interactive>:2:10
      
          Here we must display info about constructor A, but its type T has been
          shadowed by the second declaration.  But it has a respectable
          qualified name (Ghci1.T), and its source location says where it was
          defined.
      
          So the main invariant continues to hold, that in any session an original
          name M.T only refers to oe unique thing.  (In a previous iteration both
          the T's above were called :Interactive.T, albeit with different uniques,
          which gave rise to all sorts of trouble.)
      
      This scheme deals nicely with the original problem.  It allows us to
      eliminate a couple of grotseque hacks
        - Note [Outputable Orig RdrName] in HscTypes
        - Note [interactive name cache] in IfaceEnv
      (both these comments have gone, because the hacks they describe are no
      longer necessary). I was also able to simplify Outputable.QueryQualifyName,
      so that it takes a Module/OccName as args rather than a Name.
      
      However, matters are never simple, and this change took me an
      unreasonably long time to get right.  There are some details in
      Note [The interactive package] in HscTypes.
      73c08ab1