summaryrefslogtreecommitdiff
path: root/utils
Commit message (Collapse)AuthorAgeFilesLines
* Add MonadFail instance for ParserMErik de Castro Lopo2019-06-241-0/+11
|
* ghc-pkg needs settings file to un-hardcode target platformJohn Ericson2019-06-192-5/+34
| | | | This matches GHC itself getting the target platform from there.
* fix runghc's GHC detection logic to cover the "in-tree Hadrian build" scenarioAlp Mestanogullari2019-06-161-1/+6
| | | | | | | | Before this patch, runghc would only run the GHC detection logic on Windows and assume that it was invoked through a wrapper script on all other platforms. This patch lifts this limitation and makes that logic work for the scenario where someone is calling the runghc executable directly, without passing an explicit path to GHC.
* Disable optimisation when building Cabal lib for stage0Ben Gamari2019-06-151-0/+3
| | | | | | | | This disables optimisation when building Cabal for Hadrian and stage0 `ghc-cabal`. Cabal is performance critical in neither case nor will any performance difference here be visible to the end-user. See #16817.
* Add a few missing llvm-targetsBen Gamari2019-06-131-14/+52
| | | | | | This should finally fix #14261. [skip ci]
* Bump Cabal submoduleBen Gamari2019-06-122-3/+41
| | | | | | | (cherry picked from commit ff438786613f07df9b2d43eaeac49b13815d849d) Metric Increase: haddock.Cabal
* llvm-targets: Add armv7l-unknown-linux-gnueabiBen Gamari2019-06-121-0/+1
| | | | | | Fixes #15208. [skip ci]
* Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETERAlp Mestanogullari2019-06-111-1/+1
| | | | | | | | | | | | | | | | | As discussed in #16331, the GHCI macro, defined through 'ghci' flags in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate whether GHC is built with support for an internal interpreter, that runs in the same process. It is however overloaded in a few places to mean "there is an interpreter available", regardless of whether it's an internal or external interpreter. For the sake of clarity and with the hope of more easily being able to build stage 1 GHCs with external interpreter support, this patch splits the previous GHCI macro into 3 different ones: - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
* llvm-targets: Add x86_64 android layoutMoritz Angermann2019-06-071-1/+1
|
* Factor out 'getLibDir' / 'getBaseDir' into a new GHC.BaseDir ghc-boot moduleJohn Ericson2019-06-071-15/+3
| | | | | | | | | | | | | | ghc-pkg and ghc already both needed this. I figure it is better to deduplicate, especially seeing that changes to one (FreeBSD CPP) didn't make it to the other. Additionally in !1090 I make ghc-pkg look up the settings file, which makes it use the top dir a bit more widely. If that lands, any difference in the way they find the top dir would be more noticable. That change also means sharing more code between ghc and ghc-package (namely the settings file parsing code), so I'd think it better to get off the slipperly slope of duplicating code now.
* Fix and enforce validation of header for .hie filesZubin Duggal2019-05-311-0/+0
| | | | | | | | | | Implements #16686 The files version is automatically generated from the current GHC version in the same manner as normal interface files. This means that clients can first read the version and then decide how to read the rest of the file.
* Use types already in AST when making .hie fileMatthew Pickering2019-05-311-0/+0
| | | | | | | These were meant to be added in !214 but for some reason wasn't included in the patch. Update Haddock submodule for new Types.hs hyperlinker output
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-4/+4
| | | | | | | | | | After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
* Some forall-related cleanup in deriving codeRyan Scott2019-05-231-0/+0
| | | | | | | | * Tweak the parser to allow `deriving` clauses to mention explicit `forall`s or kind signatures without gratuitous parentheses. (This fixes #14332 as a consequence.) * Allow Haddock comments on `deriving` clauses with explicit `forall`s. This requires corresponding changes in Haddock.
* Use HsTyPats in associated type family defaultsRyan Scott2019-05-221-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associated type family default declarations behave strangely in a couple of ways: 1. If one tries to bind the type variables with an explicit `forall`, the `forall`'d part will simply be ignored. (#16110) 2. One cannot use visible kind application syntax on the left-hand sides of associated default equations, unlike every other form of type family equation. (#16356) Both of these issues have a common solution. Instead of using `LHsQTyVars` to represent the left-hand side arguments of an associated default equation, we instead use `HsTyPats`, which is what other forms of type family equations use. In particular, here are some highlights of this patch: * `FamEqn` is no longer parameterized by a `pats` type variable, as the `feqn_pats` field is now always `HsTyPats`. * The new design for `FamEqn` in chronicled in `Note [Type family instance declarations in HsSyn]`. * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This means that many of `TyFamDefltEqn`'s code paths can now reuse the code paths for `TyFamInstEqn`, resulting in substantial simplifications to various parts of the code dealing with associated type family defaults. Fixes #16110 and #16356.
* update-autoconf: Initial commitBen Gamari2019-04-251-0/+27
|
* Clean up URLs to point to GitLabTakenobu Tani2019-04-011-1/+1
| | | | | | | | | | | | This moves URL references to old Trac to their corresponding GitLab counterparts. This patch does not update the submodule library, such as libraries/Cabal. See also !539, !606, !618 [ci skip]
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-2533-65/+65
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* Bump Cabal submodule to 3.0Ben Gamari2019-03-193-3/+3
| | | | | Metric Increase: haddock.Cabal
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-154-4/+4
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Drop utils/count_linesBen Gamari2019-03-092-73/+0
| | | | | This doesn't appear to be used anywhere in the build system and it relies on perl. Drop it.
* Rip out perl dependencyBen Gamari2019-03-091-1/+1
| | | | | | The object splitter was the last major user of perl. There remain a few uses in nofib but we can just rely on the system's perl for this since it's not critical to the build.
* Stop inferring over-polymorphic kindsSimon Peyton Jones2019-03-091-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch GHC was trying to be too clever (Trac #16344); it succeeded in kind-checking this polymorphic-recursive declaration data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) As Note [No polymorphic recursion] discusses, the "solution" was horribly fragile. So this patch deletes the key lines in TcHsType, and a wodge of supporting stuff in the renamer. There were two regressions, both the same: a closed type family decl like this (T12785b) does not have a CUSK: type family Payload (n :: Peano) (s :: HTree n x) where Payload Z (Point a) = a Payload (S n) (a `Branch` stru) = a To kind-check the equations we need a dependent kind for Payload, and we don't get that any more. Solution: make it a CUSK by giving the result kind -- probably a good thing anyway. The other case (T12442) was very similar: a close type family declaration without a CUSK.
* Always do the worker/wrapper split for NOINLINEsSebastian Graf2019-03-071-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #10069 revealed that small NOINLINE functions didn't get split into worker and wrapper. This was due to `certainlyWillInline` saying that any unfoldings with a guidance of `UnfWhen` inline unconditionally. That isn't the case for NOINLINE functions, so we catch this case earlier now. Nofib results: -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- fannkuch-redux -0.3% 0.0% gg +0.0% +0.1% maillist -0.2% -0.2% minimax 0.0% -0.8% -------------------------------------------------------------------------------- Min -0.3% -0.8% Max +0.0% +0.1% Geometric Mean -0.0% -0.0% Fixes #10069. ------------------------- Metric Increase: T9233 -------------------------
* Fix #16391 by using occCheckExpand in TcValidityRyan Scott2019-03-071-0/+0
| | | | | | | | | | | | | The type-variables-escaping-their-scope-via-kinds check in `TcValidity` was failing to properly expand type synonyms, which led to #16391. This is easily fixed by using `occCheckExpand` before performing the validity check. Along the way, I refactored this check out into its own function, and sprinkled references to Notes to better explain all of the moving parts. Many thanks to @simonpj for the suggestions. Bumps the haddock submodule.
* Rip out object splittingBen Gamari2019-03-051-0/+0
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* Visible dependent quantificationRyan Scott2019-03-011-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide.
* Cleanup iserv/iserv-proxyMoritz Angermann2019-02-288-23/+259
| | | | | | | | | | | | This adds trace messages that include the processes name and as such make debugging and following the communication easier. It also adds a note regarding the fwd*Call proxy-communication logic between the proxy and the slave. The proxy will now also poll for 60s to wait for the remote iserv to come up. (Alternatively you can start the remote process beforehand; and just have iserv-proxy connect to it)
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-232-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263
* ghc-in-ghci: Fix capitalization of hieFileBen Gamari2019-02-221-1/+1
|
* Bump ghc version to 8.9Ryan Scott2019-02-201-0/+0
| | | | | | | Along the way, I discovered that `template-haskell.cabal` was hard-coding the GHC version (in the form of its `ghc-boot-th` version bounds), so I decided to make life a little simpler in the future by generating `template-haskell.cabal` with autoconf.
* Hadrian: Fix untracked dependenciesAndrey Mokhov2019-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a preparation for #16295: https://ghc.haskell.org/trac/ghc/ticket/16295 This commit mostly focuses on getting rid of untracked dependencies, which prevent Shake's new `--shared` feature from appropriately caching build rules. There are three different solutions to untracked dependencies: * Track them! This is the obvious and the best approach, but in some situations we cannot use it, for example, because a build rule creates files whose names are not known statically and hence cannot be specified as the rule's outputs. * Use Shake's `produces` to record outputs dynamically, within the rule. * Use Shake's `historyDisable` to disable caching for a particular build rule. We currently use this approach only for `ghc-pkg` which mutates the package database and the file `package.cache`. These two tickets are fixed as the result: Ticket #16271: ​https://ghc.haskell.org/trac/ghc/ticket/16271 Ticket #16272: ​https://ghc.haskell.org/trac/ghc/ticket/16272 (this one is fixed only partially: we correctly record the dependency, but we still copy files into the RTS build tree).
* Fix warnings and fatal parsing errorsVladislav Zavialov2019-02-171-0/+0
|
* Run some of Haddock's tests in the testsuiteAlec Theriault2019-02-161-0/+0
| | | | | | | | The 4 main testsuites in Haddock don't have many dependencies, but are regularly broken in small ways by changes to the GHC AST or the GHC API. The main gotcha is that we'll have to make sure that `haddock-test` and the test suite don't add modules without modifying this test. Then again, if that happens, the test will fail and someone will noticed.
* Remove ghctags (#16274)Sylvain Henry2019-02-104-418/+0
|
* API Annotations: parens anns discarded for `(*)` operatorAlan Zimmerman2019-02-081-0/+0
| | | | | | | | | | | | | | | The patch from https://phabricator.haskell.org/D4865 introduces go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix = do { warnStarBndr l ; let name = mkOccName tcClsName (if isUni then "★" else "*") ; return (cL l (Unqual name), acc, fix, ann) } which discards the parens annotations belonging to the HsParTy. Updates haddock submodule Closes #16265
* Fix #14579 by defining tyConAppNeedsKindSig, and using itRyan Scott2019-02-051-0/+0
|
* Bump hsc2hs for removed unused matchSebastian Graf2019-02-021-0/+0
|
* Update hsc2hs submoduleHerbert Valerio Riedel2019-01-311-0/+0
|
* API Annotations: Parens not attached correctly for ClassDeclAlan Zimmerman2019-01-301-0/+0
| | | | | | | | | | | The parens around the kinded tyvars should be attached to the class declaration as a whole, they are attached to the tyvar instead, outside the span. An annotation must always be within or after the span it is contained in. Closes #16212
* make ghc-pkg shut upMoritz Angermann2019-01-301-1/+1
|
* Revert "Batch merge"Ben Gamari2019-01-302-1/+1
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-302-1/+1
|
* Test that hsc2hs works with promoted data constructorsAndrew Martin2019-01-271-0/+0
|
* check-api-annotations checks for annotation preceding its spanAlan Zimmerman2019-01-271-5/+17
| | | | | | | | | | | | | | | | For an API annotation to be useful, it must not occur before the span it is enclosed in. So, for check-api-annotation output, a line such as ((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]), should be flagged as an error, as the AnnOpenP location of 3:21 precedes its enclosing span of 3:22-26. This patch does this. Closes #16217
* [T16199] Adds a verify-packages scriptghc-8.9-startMoritz Angermann2019-01-201-0/+20
|
* Documentation for StgRetFunÖmer Sinan Ağacan2019-01-161-1/+1
|
* Update `Cabal` submoduleHerbert Valerio Riedel2019-01-142-35/+26
| | | | | | | 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>
* Visible kind applicationmynguyen2019-01-031-0/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362. It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind application, just like in term-level. There are a few remaining issues with this patch, as documented in ticket #16082. Includes a submodule update for Haddock. Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816` Differential Revision: https://phabricator.haskell.org/D5229
* llvm-targets: Add amd64-unknown-freebsd tripleBen Gamari2018-12-131-0/+1
| | | | | | | 396aac4c65a47b6252e0a73d2a3066e924d53f11 added the amd64-portbld-freebsd triple but #15718 suggests that we should rather be using x86_64-unknown-freebsd. Not knowing which is correct I've left the amd64-portbld- triplet in place.
View Lorry Controller Status