summaryrefslogtreecommitdiff
path: root/testsuite/tests/cabal
Commit message (Collapse)AuthorAgeFilesLines
* Multiple Home UnitsMatthew Pickering2021-12-282-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multiple home units allows you to load different packages which may depend on each other into one GHC session. This will allow both GHCi and HLS to support multi component projects more naturally. Public Interface ~~~~~~~~~~~~~~~~ In order to specify multiple units, the -unit @⟨filename⟩ flag is given multiple times with a response file containing the arguments for each unit. The response file contains a newline separated list of arguments. ``` ghc -unit @unitLibCore -unit @unitLib ``` where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode. ``` -this-unit-id lib-core-0.1.0.0 -i -isrc LibCore.Utils LibCore.Types ``` The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core. ``` -this-unit-id lib-0.1.0.0 -package-id lib-core-0.1.0.0 -i -isrc Lib.Parse Lib.Render ``` Then when the compiler starts in --make mode it will compile both units lib and lib-core. There is also very basic support for multiple home units in GHCi, at the moment you can start a GHCi session with multiple units but only the :reload is supported. Most commands in GHCi assume a single home unit, and so it is additional work to work out how to modify the interface to support multiple loaded home units. Options used when working with Multiple Home Units There are a few extra flags which have been introduced specifically for working with multiple home units. The flags allow a home unit to pretend it’s more like an installed package, for example, specifying the package name, module visibility and reexported modules. -working-dir ⟨dir⟩ It is common to assume that a package is compiled in the directory where its cabal file resides. Thus, all paths used in the compiler are assumed to be relative to this directory. When there are multiple home units the compiler is often not operating in the standard directory and instead where the cabal.project file is located. In this case the -working-dir option can be passed which specifies the path from the current directory to the directory the unit assumes to be it’s root, normally the directory which contains the cabal file. When the flag is passed, any relative paths used by the compiler are offset by the working directory. Notably this includes -i and -I⟨dir⟩ flags. -this-package-name ⟨name⟩ This flag papers over the awkward interaction of the PackageImports and multiple home units. When using PackageImports you can specify the name of the package in an import to disambiguate between modules which appear in multiple packages with the same name. This flag allows a home unit to be given a package name so that you can also disambiguate between multiple home units which provide modules with the same name. -hidden-module ⟨module name⟩ This flag can be supplied multiple times in order to specify which modules in a home unit should not be visible outside of the unit it belongs to. The main use of this flag is to be able to recreate the difference between an exposed and hidden module for installed packages. -reexported-module ⟨module name⟩ This flag can be supplied multiple times in order to specify which modules are not defined in a unit but should be reexported. The effect is that other units will see this module as if it was defined in this unit. The use of this flag is to be able to replicate the reexported modules feature of packages with multiple home units. Offsetting Paths in Template Haskell splices ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When using Template Haskell to embed files into your program, traditionally the paths have been interpreted relative to the directory where the .cabal file resides. This causes problems for multiple home units as we are compiling many different libraries at once which have .cabal files in different directories. For this purpose we have introduced a way to query the value of the -working-dir flag to the Template Haskell API. By using this function we can implement a makeRelativeToProject function which offsets a path which is relative to the original project root by the value of -working-dir. ``` import Language.Haskell.TH.Syntax ( makeRelativeToProject ) foo = $(makeRelativeToProject "./relative/path" >>= embedFile) ``` > If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units. A similar function already exists in the file-embed library. The function in template-haskell implements this function in a more robust manner by honouring the -working-dir flag rather than searching the file system. Closure Property for Home Units ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For tools or libraries using the API there is one very important closure property which must be adhered to: > Any dependency which is not a home unit must not (transitively) depend on a home unit. For example, if you have three packages p, q and r, then if p depends on q which depends on r then it is illegal to load both p and r as home units but not q, because q is a dependency of the home unit p which depends on another home unit r. If you are using GHC by the command line then this property is checked, but if you are using the API then you need to check this property yourself. If you get it wrong you will probably get some very confusing errors about overlapping instances. Limitations of Multiple Home Units ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are a few limitations of the initial implementation which will be smoothed out on user demand. * Package thinning/renaming syntax is not supported * More complicated reexports/renaming are not yet supported. * It’s more common to run into existing linker bugs when loading a large number of packages in a session (for example #20674, #20689) * Backpack is not yet supported when using multiple home units. * Dependency chasing can be quite slow with a large number of modules and packages. * Loading wired-in packages as home units is currently not supported (this only really affects GHC developers attempting to load template-haskell). * Barely any normal GHCi features are supported, it would be good to support enough for ghcid to work correctly. Despite these limitations, the implementation works already for nearly all packages. It has been testing on large dependency closures, including the whole of head.hackage which is a total of 4784 modules from 452 packages. Internal Changes ~~~~~~~~~~~~~~~~ * The biggest change is that the HomePackageTable is replaced with the HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv, which contains information specific to each home unit. * The HomeUnitEnv contains: - A unit state, each home unit can have different package db flags - A set of dynflags, each home unit can have different flags - A HomePackageTable * LinkNode: A new node type is added to the ModuleGraph, this is used to place the linking step into the build plan so linking can proceed in parralel with other packages being built. * New invariant: Dependencies of a ModuleGraphNode can be completely determined by looking at the value of the node. In order to achieve this, downsweep now performs a more complete job of downsweeping and then the dependenices are recorded forever in the node rather than being computed again from the ModSummary. * Some transitive module calculations are rewritten to use the ModuleGraph which is more efficient. * There is always an active home unit, which simplifies modifying a lot of the existing API code which is unit agnostic (for example, in the driver). The road may be bumpy for a little while after this change but the basics are well-tested. One small metric increase, which we accept and also submodule update to haddock which removes ExtendedModSummary. Closes #10827 ------------------------- Metric Increase: MultiLayerModules ------------------------- Co-authored-by: Fendor <power.walross@gmail.com>
* testsuite: Clean up dynlib support predicatesBen Gamari2021-10-122-2/+2
| | | | | | | | | | | | | | | | | | Previously it was unclear whether req_shared_libs should require: * that the platform supports dynamic library loading, * that GHC supports dynamic linking of Haskell code, or * that the dyn way libraries were built Clarify by splitting the predicate into two: * `req_dynamic_lib_support` demands that the platform support dynamic linking * `req_dynamic_hs` demands that the GHC support dynamic linking of Haskell code on the target platform Naturally `req_dynamic_hs` cannot be true unless `req_dynamic_lib_support` is also true.
* testsuite: Make cabal01 more robust to large environmentsMatthew Pickering2021-09-301-2/+8
| | | | | | | | Sebastian unfortunately wrote a very long commit message in !5667 which caused `xargs` to fail on windows because the environment was too big. Fortunately `xargs` and `rm` don't need anything from the environment so just run those commands in an empty environment (which is what env -i achieves).
* driver: Only check for unused package warning in after succesful downsweepMatthew Pickering2021-08-238-0/+56
| | | | | | | | | Before we would check for the unused package warning even if the module graph was compromised due to an error in downsweep. This is easily fixed by pushing warmUnusedPackages into depanalE, and then returning the errors like the other downsweep errors. Fixes #20242
* Add test for #18567Matthew Pickering2021-07-298-0/+68
| | | | Closes #18567
* driver: Fix interaction of -Wunused-packages and reexported-modulesMatthew Pickering2021-07-1316-0/+106
| | | | | | | | | | | | | | Spurious warnings were previously emitted if an import came from a reexport due to how -Wunused-packages were implemented. Removing the dependency would cause compilation to fail. The fix is to reimplement the warning a bit more directly, by searching for which package each import comes from using the normal module finding functions rather than consulting the EPS. This has the advantage that the check could be performed at any time after downsweep rather than also relying on a populated EPS. Fixes #19518 and #19777
* Correct treatment of rexported modules in mkModuleNameProvidersMapMatthew Pickering2021-04-261-2/+2
| | | | | | | | | | | | | | | | | | | | Before we would get the incorrect error message saying that the rexporting package was the same as the defining package. I think this only affects error messages for now. ``` - it is bound as p-0.1.0.0:P2 by a reexport in package p-0.1.0.0 - it is bound as P by a reexport in package p-0.1.0.0 + it is bound as p-0.1.0.0:P2 by a reexport in package q-0.1.0.0 + it is bound as P by a reexport in package r-0.1.0.0 ``` and the output of `-ddump-mod-map` claimed.. ``` Moo moo-0.0.0.1 (hidden package, reexport by moo-0.0.0.1) ```
* testsuite: Add winio and winio_threaded wayswip/winioBen Gamari2020-07-151-2/+0
| | | | Reverts many of the testsuite changes
* winio: fix cabal01 by accepting expected stderrAndreas Klebinger2020-07-151-0/+2
|
* winio: fix cabal04 by filtering rts argsAndreas Klebinger2020-07-151-1/+1
|
* winio: Fix cabal006 after upgrading cabal submoduleAndreas Klebinger2020-07-154-4/+4
| | | | Demand cabal 2.0 syntax instead of >= 1.20 as required by newer cabal versions.
* Bump Cabal submoduleBen Gamari2020-07-151-0/+1
| | | | | Updates a variety of tests as Cabal is now more strict about Cabal file form.
* Overloaded Quotation Brackets (#246)Matthew Pickering2020-01-121-1/+1
| | | | | | | | | | | | | | | | | | This patch implements overloaded quotation brackets which generalise the desugaring of all quotation forms in terms of a new minimal interface. The main change is that a quotation, for example, [e| 5 |], will now have type `Quote m => m Exp` rather than `Q Exp`. The `Quote` typeclass contains a single method for generating new names which is used when desugaring binding structures. The return type of functions from the `Lift` type class, `lift` and `liftTyped` have been restricted to `forall m . Quote m => m Exp` rather than returning a result in a Q monad. More details about the feature can be read in the GHC proposal. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0246-overloaded-bracket.rst
* Bump Cabal submodule to what will become 3.0.0.0Ben Gamari2019-06-251-0/+6
| | | | | Metric Increase: haddock.Cabal
* Visibility: handle multiple units with the same nameMichael Peyton Jones2019-03-297-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #16228. The included test case is adapted from the reproduction in the issue, and fails without this patch. ------ We compute an initial visilibity mapping for units based on what is present in the package databases. To seed this, we compute a set of all the package configs to add visibilities for. However, this set was keyed off the unit's *package name*. This is correct, since we compare packages across databases by version. However, we would only ever consider a single, most-preferable unit from the database in which it was found. The effect of this was that only one of the libraries in a Cabal package would be added to this initial set. This would cause attempts to use modules from the omitted libraries to fail, claiming that the package was hidden (even though `ghc-pkg` would correctly show it as visible). A solution is to do the selection of the most preferable packages separately, and then be sure to consider exposing all units in the same package in the same package db. We can do this by picking a most-preferable unit for each package name, and then considering exposing all units that are equi-preferable with that unit. ------ Why wasn't this bug apparent to all people trying to use sub-libraries in Cabal? The answer is that Cabal explicitly passes `-package` and `-package-id` flags for all the packages it wants to use, rather than relying on the state of the package database. So this bug only really affects people who are trying to use package databases produced by Cabal outside of Cabal itself. One particular example of this is the way that the Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these are equipped with a package database containing all the needed package dependencies, and the user is not expected to pass `-package` flags explicitly.
* Don't mark cabal09 as brokenBen Gamari2019-03-201-2/+1
| | | | It doesn't fail reliably.
* testsuite: Mark T16219 and cabal09 as broken on WindowsBen Gamari2019-03-201-1/+2
| | | | See #16386.
* testsuite: Use makefile_testBen Gamari2019-01-302-19/+16
| | | | | This eliminates most uses of run_command in the testsuite in favor of the more structured makefile_test.
* Revert "Batch merge"Ben Gamari2019-01-302-16/+19
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-302-19/+16
|
* Update `Cabal` submoduleHerbert Valerio Riedel2019-01-142-136/+123
| | | | | | | This also requires adapting `ghc-pkg` to use the new Cabal parsing API as the old ReadP-based one has finally been evicted for good. Hadrian bit finished by: Ben Gamari <ben@smart-cactus.org>
* Fix ghc-pkg when only prof way is enabledZejun Wu2018-10-284-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We saw following errors: ``` $ cabal install --disable-library-vanilla --disable-shared --enable-library-profiling hashable-1.2.7.0: cannot find any of ["libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ.a", "libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ.p_a", "libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ-ghc8.4.3.so", "libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ-ghc8.4.3.dylib", "HShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ-ghc8.4.3.dll"] ``` This is because ghc-pkg is looking for `libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ.p_a` instead of `libHShashable-1.2.7.0-Q2TKVDwk4GBEHmizb4teZ_p.a`. Test Plan: ./validate Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5234
* Bump Cabal submoduleBen Gamari2018-08-031-4/+0
|
* Make some tests robust against DEBUG compilerRichard Eisenberg2018-07-148-8/+8
| | | | | | Several tests were failing in DEBUG mode, but fixing this was easy: just pass $(TEST_HC_OPTS) in the relevant Makefiles.
* Handle abi-depends correctly in ghc-pkgTobias Dammers2018-06-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | When inferring the correct abi-depends, we now look at all the package databases in the stack, up to and including the current one, because these are the ones that the current package can legally depend on. While doing so, we will issue warnings: - In verbose mode, we warn about every package that declares abi-depends:, whether we actually end up overriding them with the inferred ones or not ("possibly broken abi-depends"). - Otherwise, we only warn about packages whose declared abi-depends does not match what we inferred ("definitely broken abi-depends"). Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14381 Differential Revision: https://phabricator.haskell.org/D4729
* Revert "ghc-pkg: recompute `abi-depends` for updated packages"Ben Gamari2018-05-216-10/+0
| | | | | | This reverts commit 1cdc14f9c014f1a520638f7c0a01799ac6d104e6. This is causing non-deterministic testsuite output.
* ghc-pkg: recompute `abi-depends` for updated packagesAustin Seipp2018-05-206-0/+10
| | | | | | | | | | | | | | | | | | | See `Note [Recompute abi-depends]` for more information. Signed-off-by: Austin Seipp <aseipp@pobox.com> Test Plan: `./validate` Reviewers: bgamari, ezyang Reviewed By: bgamari Subscribers: tdammers, juhp, carter, alexbiehl, shlevy, cocreature, rwbarton, thomie GHC Trac Issues: #14381 Differential Revision: https://phabricator.haskell.org/D4159
* Another batch of './validation --slow' tweaksAlp Mestanogullari2018-05-201-1/+4
| | | | | | | | | | | | | | | | | | | | | | This finally gets us to a green ./validate --slow on linux for a ghc checkout from the beginning of this week, see https://circleci.com/gh/ghc/ghc/4739 This is hopefully the final (or second to final) patch to address #14890. Test Plan: ./validate --slow Reviewers: bgamari, hvr, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14890 Differential Revision: https://phabricator.haskell.org/D4712
* Fix another batch of `./validate --slow` failuresAlp Mestanogullari2018-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | A rather detailed summary can be found at: https://gist.github.com/alpmestan/be82b47bb88b7dc9ff84105af9b1bb82 This doesn't fix all expectation mismatches yet, but we're down to about 20 mismatches with my previous patch and this one, as opposed to ~150 when I got started. Test Plan: ./validate --slow Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: thomie, carter GHC Trac Issues: #14890 Differential Revision: https://phabricator.haskell.org/D4636
* Update Cabal submoduleOleg Grenrus2018-01-211-33/+6
| | | | | | | | | | | | | | | | - Cabal-2.2 uses SPDX license identifiers, so I had to update `cabal-version: 2.1` packages `license: BSD3` to `license: BSD-3-Clause` - `ghc-cabal` used old ReadP parsec, now it uses `parsec` too - InstalledPackageInfo pretty-printing have changed a little, fields with default values aren't printed. This can be changed in `Cabal` still, but I haven't found problems with omitting them. Note: `BSD-3-Clause` is parsed as "name = BSD, version = 3" by old parser (because 3-Clause looks like version 3 with tag Clause). If you see *"BSD-3" is not a valid license*, then something is using old parser still. Fixes #9885.
* Update Win32 version for GHC 8.4.Tamar Christina2017-11-091-0/+6
| | | | | | | | | | | | | | | | | | | Update to Win32 2.6 which is the expected version release for 8.4 This involves moving Cabal forward which brings some backwards incompatible changes that needs various fixups. Bump a bunch of submodules Test Plan: ./validate Reviewers: austin, bgamari, angerman Reviewed By: bgamari, angerman Subscribers: angerman, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D4133
* testsuite: Fix cabal01 for real this timeBen Gamari2017-07-231-1/+1
| | | | | | | Somehow the previous version passed on master but fails on ghc-8.2. Will look deeper later. (cherry picked from commit a6774e1d70f18f5c05279453d62fb3bcc7f07d7e)
* testsuite: Fix cabal01 testBen Gamari2017-06-231-2/+2
| | | | | | | | | | | | | The other-modules field listed things that weren't in fact modules, causing this test to fail. See Cabal #4567. Test Plan: Validate Reviewers: hvr, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3665
* Fix #13703 by correctly using munged names in ghc-pkg.Edward Z. Yang2017-05-165-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Cabal internal libraries are implemented using a trick, where the 'name' field in ghc-pkg registration file is munged into a new form to keep each internal library looking like a distinct package to ghc-pkg and other tools; e.g. the internal library q from package p is named z-p-z-q. Later, Cabal library got refactored so that we made a closer distinction between these "munged" package names and the true package name of a package. Unfortunately, this is an example of a refactor for clarity in the source code which ends up causing problems downstream, because the point of "munging" the package name was to make it so that ghc-pkg and similar tools transparently used MungedPackageName whereever they previously used PackageName (in preparation for them learning proper syntax for package name + component name). Failing to do this meant that internal libraries from the same package (but with different names) clobber each other. This commit search-replaces most occurrences of PackageName in ghc-pkg and turns them into MungedPackageName. Otherwise there shouldn't be any functional differenes. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie GHC Trac Issues: #13703 Differential Revision: https://phabricator.haskell.org/D3590
* Correctly account for -package-db ordering when picking packages.Edward Z. Yang2017-03-203-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When I originally implemented ABI-based shadowing as per ee4e1654c31b9c6f6ad9b19ece25f040bbbcbd72, I switched our strategy from pasting together lists to creating a map of all units first, and then selecting packages from this. However, what I did not realize when doing this was that we actually depended on the *ordering* of these lists later, when we selected a preferred package to use. The crux is if I have -package-db db1 -package-db db2 -package p-0.1, and p-0.1 is provided by both db1 and db2, which one does the -package flag select? Previously, this was undetermined; now we always select the instance from the LATEST package database. (If p-0.1 shows up multiple times in the same database, once again the chosen package is undefined.) The reason why cabal08 intermittently failed was that, in practice, we were sorting on the UnitId, so when we bumped version numbers, that often wibbled the UnitIds so that they compared oppositely. I've extended the test so that we check that the relation is antisymmetric. Fixes #13313 Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3369
* Try submodule bumps againBen Gamari2017-02-281-1/+2
| | | | | | Bumps containers, time, and unix submodules. This reverts commit c347a121b07d22fb91172337407986b6541e319d.
* tests: remove extra_files.py (#12223)Reid Barton2017-02-2610-20/+23
| | | | | | | | | | | | The script I used is included as testsuite/driver/kill_extra_files.py, though at this point it is for mostly historical interest. Some of the tests in libraries/hpc relied on extra_files.py, so this commit includes an update to that submodule. One test in libraries/process also relies on extra_files.py, but we cannot update that submodule so easily, so for now we special-case it in the test driver.
* tests: manually move some extra_files into *.T filesReid Barton2017-02-262-2/+3
| | | | | Some of the *.T files were in libraries/hpc, so this contains an update to that submodule.
* Revert recent submodule bumpsBen Gamari2017-02-221-1/+1
| | | | | | | | They broke everything and the solution will be non-trivial. This reverts commit 8ccbc2e5252abd4fa67d155d4fff489ee9929906. This reverts commit c8d995db5d743358b0583fe97f8113bf9047641e. This reverts commit 7153370288e6075c4f8c996ff02227e48805da06.
* Bump Cabal and containers submodulesBen Gamari2017-02-211-1/+1
|
* Bump Cabal submoduleBen Gamari2017-02-201-2/+2
| | | | We are now tracking the 2.0 branch.
* Remove clean_cmd and extra_clean usage from .T filesThomas Miedema2017-01-223-90/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | The `clean_cmd` and `extra_clean` setup functions don't do anything. Remove them from .T files. Created using https://github.com/thomie/refactor-ghc-testsuite. This diff is a test for the .T-file parser/processor/pretty-printer in that repository. find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \; Tests containing inline comments or multiline strings are not modified. Preparation for #12223. Test Plan: Harbormaster Reviewers: austin, hvr, simonmar, mpickering, bgamari Reviewed By: mpickering Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D3000 GHC Trac Issues: #12223
* Support for abi-depends for computing shadowing.Edward Z. Yang2016-12-219-12/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a complete fix based off of ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling shadowing and out-of-order -package-db flags simultaneously. The general strategy is we first put all databases together, overriding packages as necessary. Once this is done, we successfully prune out broken packages, including packages which depend on a package whose ABI differs from the ABI we need. Our check gracefully degrades in the absence of abi-depends, as we only check deps which are recorded in abi-depends. Contains time and Cabal submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: niteria, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2846 GHC Trac Issues: #12485
* base: Bump version to 4.10.0.0Ben Gamari2016-12-151-1/+1
| | | | Updates a number of submodules.
* Replace -fshow-source-paths with -fhide-source-pathsSylvain Henry2016-11-291-2/+2
| | | | | | | | | | | | | | | | | | | | | This patch reverts the change introduced with 587dcccfdfa7a319e27300a4f3885071060b1f8e and restores the previous default output of GHC (i.e., show source path and object path for each compiled module). The -fhide-source-paths flag can be used to hide these paths and reduce the line noise. Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2728 GHC Trac Issues: #12851
* Make default output less verbose (source/object paths)Sylvain HENRY2016-11-111-2/+2
| | | | | | | | | | | | Reviewers: simonmar, mpickering, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D2679 GHC Trac Issues: #12807
* Compute export hash based on ALL transitive orphan modules.Edward Z. Yang2016-10-1813-0/+88
| | | | | | | | | | | | | | | | | | | Previously we pruned out orphan modules from external packages but this was wrong. Fixes #12733 (which has more discussion.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2610 GHC Trac Issues: #12733
* Distinguish between UnitId and InstalledUnitId.Edward Z. Yang2016-10-083-3/+9
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* The Backpack patch.Edward Z. Yang2016-10-081-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements Backpack for GHC. It's a big patch but I've tried quite hard to keep things, by-in-large, self-contained. The user facing specification for Backpack can be found at: https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst A guide to the implementation can be found at: https://github.com/ezyang/ghc-proposals/blob/backpack-impl/proposals/0000-backpack-impl.rst Has a submodule update for Cabal, as well as a submodule update for filepath to handle more strict checking of cabal-version. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, simonmar, bgamari, goldfire Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1482
* A failing testcase for T12485Bartosz Nitka2016-08-316-0/+38
| | | | | | | | | | | | Test Plan: it's just a testcase Reviewers: ezyang, simonmar, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2450 GHC Trac Issues: #12485
View Lorry Controller Status