summaryrefslogtreecommitdiff
path: root/compiler/ghci
Commit message (Collapse)AuthorAgeFilesLines
* Spelling fixesGabor Greif2017-07-201-4/+4
|
* [iserv] Fixing the word size for RemotePtr and toWordArrayBen Gamari2017-07-123-16/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | When we load non absolute pathed .so's this usually implies that we expect the system to have them in place already, and hence we should not need to ship them. Without the absolute path to the library, we are also unable to open and send said library. Thus we'll do library shipping only for libraries with absolute paths. When dealing with a host and target of different word size (say host hast 64bit, target has 32bit), we need to fix the RemotePtr size and the toWordArray function, as they are part of the iserv ResolvedBCO binary protocol. This needs to be word size independent. The choice for RemotePtr to 64bit was made to ensure we can store 64bit pointers when targeting 64bit. The choice for 32bit word arrays was made wrt. encoding/decoding on the potentially slower device. The efficient serialization code has been graciously provided by @bgamari. Reviewers: bgamari, simonmar, austin, hvr Reviewed By: bgamari Subscribers: Ericson2314, rwbarton, thomie, ryantrinkle Differential Revision: https://phabricator.haskell.org/D3443
* ByteCodeGen: use depth instead of offsets in BCEnvMichal Terepeta2017-07-111-29/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on unfinished work in D38 started by Simon Marlow and is the first step for fixing #13825. (next step use byte-indexing for stack) The change boils down to adjusting everything in BCEnv by +1, which simplifies the code a bit. I've also looked into a weird stack adjustement that we did in `getIdValFromApStack` and moved it to `ByteCodeGen` to just keep everything in one place. I've left a comment about this. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, hvr, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: simonmar, rwbarton, thomie GHC Trac Issues: #13825 Differential Revision: https://phabricator.haskell.org/D3708
* Allow bytecode interpreter to make unsafe foreign callsBen Gamari2017-06-272-7/+16
| | | | | | | | | | | | Reviewers: austin, hvr, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #8281, #13730. Differential Revision: https://phabricator.haskell.org/D3619
* Refactor temp files cleanupDouglas Wilson2017-06-081-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove filesToNotIntermediateClean from DynFlags, create a data type FilesToClean, and change filesToClean in DynFlags to be a FilesToClean. Modify SysTools.newTempName and the Temporary constructor of PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies whether a temp file should live until the end of GhcMonad.withSession, or until the next time cleanIntermediateTempFiles is called. These changes allow the cleaning of intermediate files in GhcMake to be much more efficient. HscTypes.hptObjs is removed as it is no longer used. A new performance test T13701 is added, which passes both with and without -keep-tmp-files. The test fails by 25% without the patch, and passes when -keep-tmp-files is added. Note that there are still at two hotspots caused by algorithms quadratic in the number of modules, however neither of them allocate. They are: * DriverPipeline.compileOne'.needsLinker * GhcMake.getModLoop DriverPipeline.compileOne'.needsLinker is changed slightly to improve the situation. I don't like adding these Types to DynFlags, but they need to be seen by Dynflags, SysTools and PipelineMonad. The alternative seems to be to create a new module. Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13701 Differential Revision: https://phabricator.haskell.org/D3620
* Use lengthIs and friends in more placesRyan Scott2017-06-022-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | While investigating #12545, I discovered several places in the code that performed length-checks like so: ``` length ts == 4 ``` This is not ideal, since the length of `ts` could be much longer than 4, and we'd be doing way more work than necessary! There are already a slew of helper functions in `Util` such as `lengthIs` that are designed to do this efficiently, so I found every place where they ought to be used and did just that. I also defined a couple more utility functions for list length that were common patterns (e.g., `ltLength`). Test Plan: ./validate Reviewers: austin, hvr, goldfire, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: goldfire, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3622
* Deal with exceptions in dsWhenNoErrsSimon Peyton Jones2017-05-041-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gracious me. Ever since this patch commit 374457809de343f409fbeea0a885877947a133a2 Author: Jan Stolarek <jan.stolarek@p.lodz.pl> Date: Fri Jul 11 13:54:45 2014 +0200 Injective type families TcRnMonad.askNoErrs has been wrong. It looked like this askNoErrs :: TcRn a -> TcRn (a, Bool) askNoErrs m = do { errs_var <- newTcRef emptyMessages ; res <- setErrsVar errs_var m ; (warns, errs) <- readTcRef errs_var ; addMessages (warns, errs) ; return (res, isEmptyBag errs) } The trouble comes if 'm' throws an exception in the TcRn monad. Then 'errs_var is never read, so any errors are simply lost. This mistake was then propgated into DsMonad.dsWhenNoErrs, where it gave rise to Trac #13642. Thank to Ryan for narrowing it down so sharply. I did some refactoring, as usual.
* Prefer #if defined to #ifdefBen Gamari2017-04-281-7/+7
| | | | Our new CPP linter enforces this.
* askCc should be using the linker, not the compilerSimon Marlow2017-03-311-1/+1
| | | | | | | | | | | | | | | | | When GHCi tries to find a shared lib, it calls "gcc --print-file-name" to ask gcc where to find it. But since we're looking for libraries, we're really using the linker here, not the C compiler, so we should be respecting the values of -pgml and -optl rather than -pgmc and -optc. Test Plan: validate Reviewers: bgamari, niteria, austin, hvr, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3393
* Spelling in comments only [ci skip]Gabor Greif2017-03-281-1/+1
|
* ghci/Linker.hs: Fix a typo in error messageÖmer Sinan Ağacan2017-03-241-1/+1
|
* Introduce putLogMsgBen Gamari2017-03-151-9/+8
| | | | | | | | | | | | | This factors out the repetition of (log_action dflags dflags) and will hopefully allow us to someday better abstract log output. Test Plan: Validate Reviewers: austin, hvr, goldfire Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3334
* Typos in manual and commentsGabor Greif2017-03-141-1/+1
|
* Add GCC bin folder to search path.Tamar Christina2017-03-061-2/+4
| | | | | | | | | | | | | | | | | | D3155 added pthread by default to GHCi. However this was only tested using something running in an msys2 shell. As it turns out it's been picking up pthread in the environment and not the inplace gcc. This results in an error when using ghci outside of msys2. Test Plan: start cmd, start ghc-stage2 --interactive Reviewers: austin, hvr, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3279
* Extend Windows runtime loader libsearchTamar Christina2017-03-021-4/+7
| | | | | | | | | | | | | | | | | | | | | | This adds `.obj` extension to the list of valid object file (we really shouldn't be using extensions but instead trying to read the file and see if the header makes sense.). Microsoft compilers use .obj instead of .o for object files. This also adds support to finding static archives when the "lib" prefix is already in the filename. e.g. `-llibfoo` to find `libfoo.a`. This is inline with binutils. Test Plan: ./validate Reviewers: simonmar, erikd, bgamari, hvr, austin Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3082
* Upgrade UniqSet to a newtypeDavid Feuer2017-03-012-11/+10
| | | | | | | | | | | | | | | | | | | | | The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet` has a key invariant `UniqFM` does not. For example, `fmap` over `UniqSet` will generally produce nonsense. * Upgrade `UniqSet` from a type synonym to a newtype. * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`. * Use cached unique in `tyConsOfType` by replacing `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`. Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari Reviewed By: niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3146
* Load `pthreads` by default on WindowsTamar Christina2017-02-261-1/+13
| | | | | | | | | | | | | | | | | | | | | The GCC Bindists that we use compile with `pthread` enabled by default. This means that on every link the dll is passed as a dependency by the driver. Lots of packages depend on it but the runtime linker doesn't provide it by default making compiled code work but not interpreted. Following D3028 `pthreads` would be provided by default ONLY when linked dynamicly, which we don't support yet (See D2592). Until this is the case we need to manually provide `libpthreads`. Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3155
* Tweaks and typos in manual, note refs, commentsGabor Greif2017-02-091-1/+1
|
* Ditch static flagsSylvain Henry2017-02-022-16/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440
* Add support for StaticPointers in GHCiBen Gamari2017-02-021-0/+7
| | | | | | | | | | | | | | | | | | | | | Here we add support to GHCi for StaticPointers. This process begins by adding remote GHCi messages for adding entries to the static pointer table. We then collect binders needing SPT entries after linking and send the interpreter a message adding entries with the appropriate fingerprints. Test Plan: `make test TEST=StaticPtr` Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin, hvr, erikd Reviewed By: simonpj, simonmar Subscribers: RyanGlScott, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2504 GHC Trac Issues: #12356
* Typos and grammar in manual/commentsGabor Greif2017-01-231-1/+1
|
* Always use -Xlinker for -rpathBartosz Nitka2017-01-211-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | Currently we use `-Wl` which takes a list of comma-separated options. Unfortunately that breaks when you use it with `-rpath` and a path that has commas in them. Buck, the build system, produces paths with commas in them. `-Xlinker` doesn't have this disadvantage and as far as I can tell is supported by both `gcc` and `clang`. Anecdotally `nvcc` supports `-Xlinker`, but not `-Wl`. Test Plan: ./validate, harbourmaster Reviewers: nomeata, simonmar, austin, bgamari, hvr Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2971
* Show explicit quantifiers in conflicting definitions errorPhil de Joux2017-01-201-1/+2
| | | | | | | | | | | | | | | | This fixes #12441, where definitions in a Haskell module and its boot file which differed only in their quantifiers produced a confusing error message. Here we teach GHC to always show quantifiers for these errors. Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari Reviewed By: bgamari Subscribers: snowleopard, simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2734 GHC Trac Issues: #12441
* Allow top-level string literals in Core (#8472)Takano Akio2017-01-202-18/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commits relaxes the invariants of the Core syntax so that a top-level variable can be bound to a primitive string literal of type Addr#. This commit: * Relaxes the invatiants of the Core, and allows top-level bindings whose type is Addr# as long as their RHS is either a primitive string literal or another variable. * Allows the simplifier and the full-laziness transformer to float out primitive string literals to the top leve. * Introduces the new StgGenTopBinding type to accomodate top-level Addr# bindings. * Introduces a new type of labels in the object code, with the suffix "_bytes", for exported top-level Addr# bindings. * Makes some built-in rules more robust. This was necessary to keep them functional after the above changes. This is a continuation of D2554. Rebasing notes: This had two slightly suspicious performance regressions: * T12425: bytes allocated regressed by roughly 5% * T4029: bytes allocated regressed by a bit over 1% * T13035: bytes allocated regressed by a bit over 5% These deserve additional investigation. Rebased by: bgamari. Test Plan: ./validate --slow Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari Reviewed By: trofi, simonpj, bgamari Subscribers: trofi, simonpj, gridaphobe, thomie Differential Revision: https://phabricator.haskell.org/D2605 GHC Trac Issues: #8472
* Update levity polymorphismRichard Eisenberg2017-01-195-68/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly.
* Fix abort and import lib search on WindowsTamar Christina2017-01-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: Apparently `sysErrorBelch` doesn't terminate the program anymore making previously unreachable code now execute. If a dll is not found the error message we return needs to be a heap value. Secondly also allow the pattern `lib<name>` to be allowed for finding an import library with the name `lib<name>.dll.a`. Test Plan: ./validate, new tests T13082_good and T13082_fail Reviewers: austin, RyanGlScott, hvr, erikd, simonmar, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2941 GHC Trac Issues: #13082
* Simplify CPP logic as we now need v7.10 for bootstrappingGabor Greif2017-01-131-5/+1
|
* Allow use of the external interpreter in stage1.Shea Levy2016-12-205-2/+72
| | | | | | | | | | | | | | | | | | | Summary: Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. This was originally added in https://phabricator.haskell.org/D2826 but that led to a compatibility issue with ghc 7.10.x on Windows. That's fixed here and the revert reverted. Reviewers: goldfire, hvr, austin, bgamari, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2884 GHC Trac Issues: #13008
* Revert "Allow use of the external interpreter in stage1."Tamar Christina2016-12-195-49/+2
| | | | This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
* Allow use of the external interpreter in stage1.Shea Levy2016-12-175-2/+49
| | | | | | | | | | | | Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. Reviewers: simonmar, goldfire, austin, hvr, bgamari Reviewed By: simonmar Subscribers: RyanGlScott, mpickering, angerman, thomie Differential Revision: https://phabricator.haskell.org/D2826
* Make globals use sharedCAFMoritz Angermann2016-12-111-22/+22
| | | | | | | | | | | | | | | | | | | Summary: The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. This is a reboot of D2575, that should hopefully not exhibit the same windows build issues. Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd Reviewed By: Phyx, simonmar, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2773
* Revert "Make globals use sharedCAF"Ben Gamari2016-11-301-22/+22
| | | | | This reverts commit 6f7ed1e51bf360621a3c2a447045ab3012f68575 due to breakage of the build on Windows.
* Make globals use sharedCAFMoritz Angermann2016-11-291-22/+22
| | | | | | | | | | | | | | | The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2575
* GHCi: Unconditionally import System.DirectoryBen Gamari2016-11-171-1/+1
| | | | Both Windows and POSIX codepaths use System.Directory.canonicalizePath.
* Fix -fobject-code with -fexternal-interpreterSimon Marlow2016-11-161-3/+15
| | | | | If the user does :cd in GHCi with -fexternal-interpreter, then we can fail to find the object files.
* Remove CONSTR_STATICSimon Marlow2016-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have two info tables for a constructor * XXX_con_info: the info table for a heap-resident instance of the constructor, It has type CONSTR, or one of the specialised types like CONSTR_1_0 * XXX_static_info: the info table for a static instance of this constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. I'm getting rid of the latter, and using the `con_info` info table for both static and dynamic constructors. For rationale and more details see Note [static constructors] in SMRep.hs. I also removed these macros: `isSTATIC()`, `ip_STATIC()`, `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC distinction, and anyway HEAP_ALLOCED() does the same job. Test Plan: validate Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2690 GHC Trac Issues: #12455
* Some minor linker cleanups.Tamar Christina2016-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Just some cleanups to some oddities I've noticed while investigating a linker issue. Particularly the dll name returned by `findSysDll` was decorated. So foo.dll is returned. We make it `foo.dll.dll` and later drop one `.dll` when passed to `addDll` which expects it without extension, but still tries the name *as is* which is why it worked. This should be slightly faster, since we don't try 4 loads before we succeed. Test Plan: ./validate Reviewers: austin, hvr, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2680
* Align GHCi's library search order more closely with LDsTamar Christina2016-10-311-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Given a static library and an import library in the same folder. e.g. ``` libfoo.a libfoo.dll.a ``` running `ghci -lfoo` we should prefer the import library `libfoo.dll.a` over `libfoo.a` because we prefer having to just load the DLL. And not having to do any linking. This also more closely emulated the behaviour of LD, which has a search order of ``` libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll ``` Test Plan: ./validate Reviewers: RyanGlScott, austin, hvr, bgamari, erikd, simonmar Reviewed By: RyanGlScott Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2651 GHC Trac Issues: #12771
* Add and use a new dynamic-library-dirs field in the ghc-pkg infoDuncan Coutts2016-10-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Build systems / package managers want to be able to control the file layout of installed libraries. In general they may want/need to be able to put the static libraries and dynamic libraries in different places. The ghc-pkg library regisrtation needs to be able to handle this. This is already possible in principle by listing both a static lib dir and a dynamic lib dir in the library-dirs field (indeed some previous versions of Cabal did this for shared libs on ELF platforms). The downside of listing both dirs is twofold. There is a lack of precision, if we're not careful with naming then we could end up picking up the wrong library. The more immediate problem however is that if we list both directories then both directories get included into the ELF and Mach-O shared object runtime search paths. On ELF this merely slows down loading of shared libs (affecting prog startup time). On the latest OSX versions this provokes a much more serious problem: that there is a rather low limit on the total size of the section containing the runtime search path (and lib names and related) and thus listing any unnecessary directories wastes the limited space. So the solution in this patch is fairly straightforward: split the static and dynamic library search paths in the ghc-pkg db and its use within ghc. This is a traditional solution: pkg-config has the same static / dynamic split (though it describes in in terms of private and public, but it translates into different behaviour for static and dynamic linking). Indeed it would make perfect sense to also have a static/dynamic split for the list of the libraries to use i.e. to have dynamic variants of the hs-libraries and extra-libraries fields. These are not immediately required so this patch does not add it, but it is a reasonable direction to follow. To handle compatibility, if the new dynamic-library-dirs field is not specified then its value is taken from the library-dirs field. Contains Cabal submodule update. Test Plan: Run ./validate Get christiaanb and carter to test it on OSX Sierra, in combination with Cabal/cabal-install changes to the default file layout for libraries. Reviewers: carter, austin, hvr, christiaanb, bgamari Reviewed By: christiaanb, bgamari Subscribers: ezyang, Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2611 GHC Trac Issues: #12479
* A collection of type-inference refactorings.Simon Peyton Jones2016-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a raft of useful tidy-ups in the type checker. I've been meaning to do this for some time, and finally made time to do it en route to ICFP. 1. Modify TcType.ExpType to make a distinct data type, InferResult for the Infer case, and consequential refactoring. 2. Define a new function TcUnify.fillInferResult, to fill in an InferResult. It uses TcMType.promoteTcType to promote the type to the level of the InferResult. See TcMType Note [Promoting a type] This refactoring is in preparation for an improvement to typechecking pattern bindings, coming next. I flirted with an elaborate scheme to give better higher rank inference, but it was just too complicated. See TcMType Note [Promotion and higher rank types] 3. Add to InferResult a new field ir_inst :: Bool to say whether or not the type used to fill in the InferResult should be deeply instantiated. See TcUnify Note [Deep instantiation of InferResult]. 4. Add a TcLevel to SkolemTvs. This will be useful generally - it's a fast way to see if the type variable escapes when floating (not used yet) - it provides a good consistency check when updating a unification variable (TcMType.writeMetaTyVarRef, the level_check_ok check) I originally had another reason (related to the flirting in (2), but I left it in because it seems like a step in the right direction. 5. Reduce and simplify the plethora of uExpType, tcSubType and related functions in TcUnify. It was such an opaque mess and it's still not great, but it's better. 6. Simplify the uo_expected field of TypeEqOrigin. Richard had generatlised it to a ExpType, but it was almost always a Check type. Now it's back to being a plain TcType which is much, much easier. 7. Improve error messages by refraining from skolemisation when it's clear that there's an error: see TcUnify Note [Don't skolemise unnecessarily] 8. Type.isPiTy and isForAllTy seem to be missing a coreView check, so I added it 9. Kill off tcs_used_tcvs. Its purpose is to track the givens used by wanted constraints. For dictionaries etc we do that via the free vars of the /bindings/ in the implication constraint ic_binds. But for coercions we just do update-in-place in the type, rather than generating a binding. So we need something analogous to bindings, to track what coercions we have added. That was the purpose of tcs_used_tcvs. But it only worked for a /single/ iteration, whereas we may have multiple iterations of solving an implication. Look at (the old) 'setImplicationStatus'. If the constraint is unsolved, it just drops the used_tvs on the floor. If it becomes solved next time round, we'll pick up coercions used in that round, but ignore ones used in the first round. There was an outright bug. Result = (potentialy) bogus unused-constraint errors. Constructing a case where this actually happens seems quite trick so I did not do so. Solution: expand EvBindsVar to include the (free vars of the) coercions, so that the coercions are tracked in essentially the same way as the bindings. This turned out to be much simpler. Less code, more correct. 10. Make the ic_binds field in an implication have type ic_binds :: EvBindsVar instead of (as previously) ic_binds :: Maybe EvBindsVar This is notably simpler, and faster to use -- less testing of the Maybe. But in the occaional situation where we don't have anywhere to put the bindings, the belt-and-braces error check is lost. So I put it back as an ASSERT in 'setImplicationStatus' (see the use of 'termEvidenceAllowed') All these changes led to quite bit of error message wibbling
* Typos in commentsGabor Greif2016-10-171-1/+1
|
* Distinguish between UnitId and InstalledUnitId.Edward Z. Yang2016-10-081-12/+15
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Fix #12442.Richard Eisenberg2016-09-231-1/+1
| | | | | | | | | | | | | | | | | | | The problem is described in the ticket. This patch adds new variants of the access points to the pure unifier that allow unification of types only when the caller wants this behavior. (The unifier used to also unify kinds.) This behavior is appropriate when the kinds are either already known to be the same, or the list of types provided are a list of well-typed arguments to some type constructor. In the latter case, unifying earlier types in the list will unify the kinds of any later (dependent) types. At use sites, I went through and chose the unification function according to the criteria above. This patch includes some modest performance improvements as we are now doing less work.
* Codegen for case: Remove redundant void id checksÖmer Sinan Ağacan2016-09-201-8/+10
| | | | | | | | | | | | | | | | New unarise (714bebf) eliminates void binders in patterns already, so no need to eliminate them here. I leave assertions to make sure this is the case. Assertion failure -> bug in unarise Reviewers: bgamari, simonpj, austin, simonmar, hvr Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2416
* Add hook for creating ghci external interpreterAlan Zimmerman2016-09-091-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The external interpreter is launched by calling 'System.Process.createProcess' with a 'CreateProcess' parameter. The current value for this has the 'std_in', 'std_out' and 'std_err' fields use the default of 'Inherit', meaning that the remote interpreter shares the stdio with the original ghc/ghci process. This patch introduces a new hook to the DynFlags, which has an opportunity to override the 'CreateProcess' fields, launch the process, and retrieve the stdio handles actually used. So if a ghci external interpreter session is launched from the GHC API the stdio can be redirected if required, which is useful for tooling/IDE integration. Test Plan: ./validate Reviewers: austin, hvr, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2518
* Tag pointers in interpreted constructorsmniip2016-08-301-1/+3
| | | | | | | | | | | | | | | | | | | | | Instead of stg_interp_constr_entry there are now 7 functions (one for each value of the tag bits) that tag the constructor pointer before returning. This is consistent with compiled constructors' entry code, and expectations that compiled code places on compiled constructors. The iserv protocol is extended with an extra field that explains what pointer tag the constructor should use. Test Plan: Added tests for #12523 Reviewers: erikd, bgamari, hvr, austin, simonmar Reviewed By: simonmar Subscribers: osa1, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2473 GHC Trac Issues: #12523
* RtClosureInspect: Fix off-by-one error in cvReconstructTypemniip2016-08-231-4/+3
| | | | | | | | | | | | | | | | | Replaced error-prone index manipulation on a pointer array with a simple fold on the array elements. Test Plan: Added a test case that triggers the bug Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2439 GHC Trac Issues: #12458
* Annotate initIfaceCheck with usage information.Edward Z. Yang2016-08-211-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Squash space leaks in the result of byteCodeGenSimon Marlow2016-07-222-18/+70
| | | | | | | | | | | | | | | | | | | | When loading a large number of modules into GHCi, we collect CompiledByteCode for every module and then link it all at the end. Space leaks in the CompiledByteCode linger until we traverse it all for linking, and possibly longer, if there are bits we don't look at. This is the nuke-it-from-orbit approach: we deepseq the whole thing after code generation. It's the only way to be sure. Test Plan: Heap profile of GHCi while loading nofib/real/anna into GHCi, this patch reduces the peak heap usage from ~100M to ~50M. Reviewers: hvr, austin, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2419
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-213-101/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements primitive unboxed sum types, as described in https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes. Main changes are: - Add new syntax for unboxed sums types, terms and patterns. Hidden behind `-XUnboxedSums`. - Add unlifted unboxed sum type constructors and data constructors, extend type and pattern checkers and desugarer. - Add new RuntimeRep for unboxed sums. - Extend unarise pass to translate unboxed sums to unboxed tuples right before code generation. - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better code generation when sum values are involved. - Add user manual section for unboxed sums. Some other changes: - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to `MultiValAlt` to be able to use those with both sums and tuples. - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really wrong, given an `Any` `TyCon`, there's no way to tell what its kind is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`. - Fix some bugs on the way: #12375. Not included in this patch: - Update Haddock for new the new unboxed sum syntax. - `TemplateHaskell` support is left as future work. For reviewers: - Front-end code is mostly trivial and adapted from unboxed tuple code for type checking, pattern checking, renaming, desugaring etc. - Main translation routines are in `RepType` and `UnariseStg`. Documentation in `UnariseStg` should be enough for understanding what's going on. Credits: - Johan Tibell wrote the initial front-end and interface file extensions. - Simon Peyton Jones reviewed this patch many times, wrote some code, and helped with debugging. Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin, simonmar, hvr, erikd Reviewed By: simonpj Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2259
View Lorry Controller Status