summaryrefslogtreecommitdiff
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* Introduce DerivingViaRyan Scott2018-06-042-4/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the `DerivingVia` proposal put forth in https://github.com/ghc-proposals/ghc-proposals/pull/120. This introduces the `DerivingVia` deriving strategy. This is a generalization of `GeneralizedNewtypeDeriving` that permits the user to specify the type to `coerce` from. The major change in this patch is the introduction of the `ViaStrategy` constructor to `DerivStrategy`, which takes a type as a field. As a result, `DerivStrategy` is no longer a simple enumeration type, but rather something that must be renamed and typechecked. The process by which this is done is explained more thoroughly in section 3 of this paper ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ), although I have inlined the relevant parts into Notes where possible. There are some knock-on changes as well. I took the opportunity to do some refactoring of code in `TcDeriv`, especially the `mkNewTypeEqn` function, since it was bundling all of the logic for (1) deriving instances for newtypes and (2) `GeneralizedNewtypeDeriving` into one huge broth. `DerivingVia` reuses much of part (2), so that was factored out as much as possible. Bumps the Haddock submodule. Test Plan: ./validate Reviewers: simonpj, bgamari, goldfire, alanz Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15178 Differential Revision: https://phabricator.haskell.org/D4684
* Serialize docstrings to ifaces, display them with new GHCi :doc commandSimon Jakobi2018-06-042-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | If `-haddock` is set, we now extract docstrings from the renamed ast and serialize them in the .hi-files. This includes some of the changes from D4749 with the notable exceptions of the docstring lexing and renaming. A currently limited and experimental GHCi :doc command can be used to display docstrings for declarations. The formatting of pretty-printed docstrings is changed slightly, causing some changes in testsuite/tests/haddock. Test Plan: ./validate Reviewers: alexbiehl, hvr, gershomb, harpocrates, bgamari Reviewed By: alexbiehl Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4758
* Implement QuantifiedConstraintsSimon Peyton Jones2018-06-041-2/+258
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers
* Document the fact that cmm dumps won't show unreachable blocks.klebinger.andreas@gmx.at2018-06-041-0/+3
| | | | | | | | | | Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4788
* Fix typo in OverloadedLabels docsJoachim Breitner2018-06-031-1/+1
| | | | as helpfully reported by elpinal (#15217).
* Allow aligning of cmm procs at specific boundryklebinger.andreas@gmx.at2018-06-031-0/+11
| | | | | | | | | | | | | | | | | | | | Allows to align CmmProcs at the given boundries. It makes performance usually worse but can be helpful to limit the effect of a unrelated function B becoming faster/slower after changing function A. Test Plan: ci, using it. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15148 Differential Revision: https://phabricator.haskell.org/D4706
* Turn "inaccessible code" error into a warningTobias Dammers2018-06-021-1/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With GADTs, it is possible to write programs such that the type constraints make some code branches inaccessible. Take, for example, the following program :: {-# LANGUAGE GADTs #-} data Foo a where Foo1 :: Foo Char Foo2 :: Foo Int data TyEquality a b where Refl :: TyEquality a a checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u) checkTEQ x y = error "unimportant" step2 :: Bool step2 = case checkTEQ Foo1 Foo2 of Just Refl -> True -- Inaccessible code Nothing -> False Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1` and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl` constructor essentially mandates `t ~ u`, and thus `Char ~ Int`. Previously, GHC would reject such programs entirely; however, in practice this is too harsh. Accepting such code does little harm, since attempting to use the "impossible" code will still produce errors down the chain, while rejecting it means we cannot legally write or generate such code at all. Hence, we turn the error into a warning, and provide `-Winaccessible-code` to control GHC's behavior upon encountering this situation. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11066 Differential Revision: https://phabricator.haskell.org/D4744
* Extended the plugin system to run plugins on more representationsBoldizsar Nemeth2018-06-021-0/+203
| | | | | | | | | | | | | | | | | | | | Extend GHC plugins to access parsed, type checked representation, interfaces that are loaded. And splices that are evaluated. The goal is to enable development tools to access the GHC representation in the pre-existing build environment. See the full proposal here: https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Reviewers: goldfire, bgamari, ezyang, angerman, mpickering Reviewed By: mpickering Subscribers: ezyang, angerman, mpickering, ulysses4ever, rwbarton, thomie, carter GHC Trac Issues: #14709 Differential Revision: https://phabricator.haskell.org/D4342
* rts: Rip out support for STM invariantsBen Gamari2018-06-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | This feature has some very serious correctness issues (#14310), introduces a great deal of complexity, and hasn't seen wide usage. Consequently we are removing it, as proposed in Proposal #77 [1]. This is heavily based on a patch from fryguybob. Updates stm submodule. [1] https://github.com/ghc-proposals/ghc-proposals/pull/77 Test Plan: Validate Reviewers: erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14310 Differential Revision: https://phabricator.haskell.org/D4760
* vectorise: Put it out of its miseryBen Gamari2018-06-027-936/+1
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* users-guide: Fix various issues in debugging flags sectionBen Gamari2018-05-301-8/+6
| | | | | | | | | | Reviewers: ggreif Reviewed By: ggreif Subscribers: rwbarton, thomie, carter, ggreif Differential Revision: https://phabricator.haskell.org/D4750
* Implement "An API for deciding whether plugins should cause recompilation"Matthew Pickering2018-05-301-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366
* Improved Valid Hole FitsMatthías Páll Gissurarson2018-05-302-204/+265
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've changed the name from `Valid substitutions` to `Valid hole fits`, since "substitution" already has a well defined meaning within the theory. As part of this change, the flags and output is reanamed, with substitution turning into hole-fit in most cases. "hole fit" was already used internally in the code, it's clear and shouldn't cause any confusion. In this update, I've also reworked how we manage side-effects in the hole we are considering. This allows us to consider local bindings such as where clauses and arguments to functions, suggesting e.g. `a` for `head (x:xs) where head :: [a] -> a`. It also allows us to find suggestions such as `maximum` for holes of type `Ord a => a -> [a]`, and `max` when looking for a match for the hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`. We also show much improved output for refinement hole fits, and fixes #14990. We now show the correct type of the function, but we also now show what the arguments to the function should be e.g. `foldl1 (_ :: Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`. I've moved the bulk of the code from `TcErrors.hs` to a new file, `TcHoleErrors.hs`, since it was getting too big to not live on it's own. This addresses the considerations raised in #14969, and takes proper care to set the `tcLevel` of the variables to the right level before passing it to the simplifier. We now also zonk the suggestions properly, which improves the output of the refinement hole fits considerably. This also filters out suggestions from the `GHC.Err` module, since even though `error` and `undefined` are indeed valid hole fits, they are "trivial", and almost never useful to the user. We now find the hole fits using the proper manner, namely by solving nested implications. This entails that the givens are passed along using the implications the hole was nested in, which in turn should mean that there will be fewer weird bugs in the typed holes. I've also added a new sorting method (as suggested by SPJ) and sort by the size of the types needed to turn the hole fits into the type of the hole. This gives a reasonable approximation to relevance, and is much faster than the subsumption check. I've also added a flag to toggle whether to use this new sorting algorithm (as is done by default) or the subsumption algorithm. This fixes #14969 I've also added documentation for these new flags and update the documentation according to the new output. Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14969, #14990, #10946 Differential Revision: https://phabricator.haskell.org/D4444
* users-guide: Point out GNTD may require additional extensionsBen Gamari2018-05-301-1/+38
| | | | | | | | | | | | | | | | | | | | As noted in #15073, GeneralizedNewtypeDeriving may produce code that uses extensions that do not directly appear in the code written by the user. Make this clear in the users guide. [skip ci] Test Plan: Read it Reviewers: RyanGlScott Reviewed By: RyanGlScott Subscribers: fosskers, rwbarton, thomie, carter GHC Trac Issues: #15073 Differential Revision: https://phabricator.haskell.org/D4701
* Improve the documentation of lexically scoped type variablesAntC2018-05-301-23/+64
| | | | | | | Section 10.16 in the Users Guide. Also reviewed mentions/links from other sections: none need revision. Fixes #15146.
* Typofix in manual [ci skip]Gabor Greif2018-05-291-1/+1
|
* Add -fghci-leak-check to check for space leaksSimon Marlow2018-05-251-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (re-applying this patch now that D4659 is committed) Space leaks in GHCi emerge from time to time and tend to come back again after they get fixed. This is an attempt to limit regressions by * adding a reliable detection for some classes of space leaks in GHCi * turning on leak checking for all GHCi tests in the test suite, so that we'll notice if the leak appears again. The idea for detecting space leaks is quite simple: * find some data that we expect to be GC'd later, make a weak pointer to it * when we expect the data to be dead, do a `performGC` and then check the status of the weak pointer. It would be nice to apply this trick to lots of things in GHC, e.g. ensuring that HsSyn is not retained after the desugarer, or ensuring that CoreSyn from the previous simplifier pass is not retained. Test Plan: validate Reviewers: bgamari, simonpj, erikd, niteria Subscribers: thomie, carter GHC Trac Issues: #15111
* Clarify what the FFI spec saysDavid Feuer2018-05-131-10/+16
| | | | | | | | | | | | | | | | | | | | | Section 10.1.1 claimed that > The FFI addendum stipulates that an implementation is free to implement an unsafe call by performing a safe call ... Reading through the FFI addendum (and the Haskell 2010 Report, which integrates it), I see no such stipulation. I think this explains the situation a bit better. [ci skip] Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4656
* Revert "Add -fghci-leak-check to check for space leaks"Simon Marlow2018-05-101-11/+0
| | | | This reverts commit 5fe6aaa3756cda654374ebfd883fa8f064ff64a4.
* Add -fghci-leak-check to check for space leaksSimon Marlow2018-05-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Space leaks in GHCi emerge from time to time and tend to come back again after they get fixed. This is an attempt to limit regressions by * adding a reliable detection for some classes of space leaks in GHCi * turning on leak checking for all GHCi tests in the test suite, so that we'll notice if the leak appears again. The idea for detecting space leaks is quite simple: * find some data that we expect to be GC'd later, make a weak pointer to it * when we expect the data to be dead, do a `performGC` and then check the status of the weak pointer. It would be nice to apply this trick to lots of things in GHC, e.g. ensuring that HsSyn is not retained after the desugarer, or ensuring that CoreSyn from the previous simplifier pass is not retained. Test Plan: validate Reviewers: bgamari, simonpj, erikd, niteria Subscribers: thomie, carter GHC Trac Issues: #15111 Differential Revision: https://phabricator.haskell.org/D4658
* users-guide: Move discussion MAX_PATH out of release notesBen Gamari2018-05-082-43/+55
| | | | | | | | | | | | | | | This discussion will be useful for users; move it into the users-guide proper. Also fixes a few typos noted by @Phyx. Test Plan: Read it Reviewers: Phyx Reviewed By: Phyx Subscribers: dfeuer, Phyx, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4420
* Add 'addWordC#' PrimOpSebastian Graf2018-05-051-1/+6
| | | | | | | | | | | | | | | | | | | This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'. I found 'plusWord2#' while implementing this, which both lacks documentation and has a slightly different specification than 'addWordC#', which means the generic implementation is unnecessarily complex. While I was at it, I also added lacking meta-information on PrimOps and refactored 'subWordC#'s generic implementation to be branchless. Reviewers: bgamari, simonmar, jrtc27, dfeuer Reviewed By: bgamari, dfeuer Subscribers: dfeuer, thomie, carter Differential Revision: https://phabricator.haskell.org/D4592
* rel-notes: Note that -hT is now allowedBen Gamari2018-05-051-0/+3
| | | | | | See #15086. [skip-ci]
* Fix typo in user guide about promoted listMasahiro Sakai2018-05-051-1/+1
| | | `:'` in explanation text should be `':` to match code example.
* users-guide: Fix up formatting in 8.6 release notesBen Gamari2018-04-231-7/+7
|
* Caching coercion roles in NthCo and coercionKindsRole refactoringTobias Dammers2018-04-204-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While addressing nonlinear behavior related to coercion roles, particularly `NthCo`, we noticed that coercion roles are recalculated often even though they should be readily at hand already in most cases. This patch adds a `Role` to the `NthCo` constructor so that we can cache them rather than having to recalculate them on the fly. https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the approach. Performance improvement over GHC HEAD, when compiling Grammar.hs (see below): GHC 8.2.1: ``` ghc Grammar.hs 176.27s user 0.23s system 99% cpu 2:56.81 total ``` before patch (but with other optimizations applied): ``` ghc Grammar.hs -fforce-recomp 175.77s user 0.19s system 100% cpu 2:55.78 total ``` after: ``` ../../ghc/inplace/bin/ghc-stage2 Grammar.hs 10.32s user 0.17s system 98% cpu 10.678 total ``` Introduces the following regressions: - perf/compiler/parsing001 (possibly false positive) - perf/compiler/T9872 - perf/compiler/haddock.base Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11735 Differential Revision: https://phabricator.haskell.org/D4394
* users-guide: Override mathjax_pathBen Gamari2018-04-191-0/+3
| | | | | | | | | | | | | | | | | | The Mathjax CDN no longer exists. Use CDNJS instead. See #15006. Test Plan: Build HTML users guide, see whether math is rendered. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: thomie, carter GHC Trac Issues: #15006 Differential Revision: https://phabricator.haskell.org/D4603
* Fix #14710 with more validity checks during renamingRyan Scott2018-04-191-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: #14710 revealed two unfortunate regressions related to kind polymorphism that had crept in in recent GHC releases: 1. While GHC was able to catch illegal uses of kind polymorphism (i.e., if `PolyKinds` wasn't enabled) in limited situations, it wasn't able to catch kind polymorphism of the following form: ```lang=haskell f :: forall a. a -> a f x = const x g where g :: Proxy (x :: a) g = Proxy ``` Note that the variable `a` is being used as a kind variable in the type signature of `g`, but GHC happily accepts it, even without the use of `PolyKinds`. 2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC incorrectly accepts the following definition: ```lang=haskell f :: forall k (a :: k). Proxy a f = Proxy ``` Even though `k` is explicitly bound and then later used as a kind variable within the same telescope. This patch fixes these two bugs as follows: 1. Whenever we rename any `HsTyVar`, we check if the following three criteria are met: (a) It's a type variable (b) It's used at the kind level (c) `PolyKinds` is not enabled If so, then we have found an illegal use of kind polymorphism, so throw an error. This check replaces the `checkBadKindBndrs` function, which could only catch illegal uses of kind polymorphism in very limited situations (when the bad kind variable happened to be implicitly quantified in the same type signature). 2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not enabled and either of the following criteria are met: (a) An explicitly bound type variable is used in kind position in the body of a `forall` type. (b) An explicitly bound type variable is used in kind position in the kind of a bound type variable in a `forall` type. `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr Reviewed By: simonpj Subscribers: thomie, carter GHC Trac Issues: #14710 Differential Revision: https://phabricator.haskell.org/D4554
* Fix markup in the UNPACK pragma section of the user's guide.theindigamer2018-04-171-5/+2
| | | | The ticket 5252 wasn't linked earlier.
* users guide: Note improved constant folding in 8.6 release notesBen Gamari2018-04-131-0/+4
|
* Make shortcutting at the asm stage toggleable and default for O2.Andreas Klebinger2018-04-131-0/+17
| | | | | | | | | | | | | | | | | | | Shortcutting during the asm stage of codegen is often redundant as most cases get caught during the Cmm passes. For example during compilation of all of nofib only 508 jumps are eleminated. For this reason I moved the pass from -O1 to -O2. I also made it toggleable with -fasm-shortcutting. Test Plan: ci Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4555
* users-guide: Update release notes and language extensionsTakenobu Tani2018-04-132-11/+15
| | | | | | | | | | | | | | | | | Update release notes and language extensions for GHC 8.6.1. * Add `BlockArguments` and `NumericUndescores` in release note * Fix directive for `HexFloatLiterals` and `NumericUndescores` Test Plan: build Reviewers: bgamari Reviewed By: bgamari Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D4579
* Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0Ryan Scott2018-04-131-4/+10
| | | | | | | | | | | | | | | | | | | | | This takes care of bumping the `base` and `integer-gmp` minor version numbers in anticipation of a GHC 8.4.2 release. While I was in town, I also filled in a `@since TODO` Haddock annotation for `powModSecInteger` in `integer-gmp` with `1.0.2.0`, and updated the changelog accordingly. Test Plan: ./validate Reviewers: hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15025 Differential Revision: https://phabricator.haskell.org/D4586
* Track type variable scope more carefully.Richard Eisenberg2018-03-311-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h}
* Remove MAX_PATH restrictions from RTS, I/O manager and various utilitiesTamar Christina2018-03-311-2/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This shims out fopen and sopen so that they use modern APIs under the hood along with namespaced paths. This lifts the MAX_PATH restrictions from Haskell programs and makes the new limit ~32k. There are only some slight caveats that have been documented. Some utilities have not been upgraded such as lndir, since all these things are different cabal packages I have been forced to copy the source in different places which is less than ideal. But it's the only way to keep sdist working. Test Plan: ./validate Reviewers: hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #10822 Differential Revision: https://phabricator.haskell.org/D4416
* Fix syntax in -flate-specialise docsSimon Jakobi2018-03-291-0/+2
|
* Add new debugging flag -dinline-checkBen Gamari2018-03-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | This flag reports a summary of the inlining decision for identifiers prefixed by the flag's argument. For example, `-dinline-check foo` will report why definitions whose prefix is `foo` are inlined or not. Previously the only way to get this information was to pass a combination of `-dverbose-core2core` and `-ddump-inlinings`. This combination led to a log of 12 million lines in a module of about 200 lines I recently had to apply it to. This flag provides a much more direct way to find the occurence you care about. Reviewers: osa1, dfeuer, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4458
* Fix scoped type variables in TH for several constructsHE, Tao2018-03-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Namely class methods, default signatures and pattern synonyms. When scoped type variables occur inside class default methods, default signatures and pattern synonyms, avoid re-create explicit type variables when represent the type signatures. This patch should fix Trac#14885. Signed-off-by: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T14885a T14885b T14885c" Reviewers: goldfire, bgamari, simonpj, RyanGlScott Reviewed By: simonpj, RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14885 Differential Revision: https://phabricator.haskell.org/D4469
* document: fix trac issue #14229Võ Anh Duy2018-03-251-2/+2
| | | | | | | | | | | | | | | Accroding to https://git.haskell.org/ghc.git/commitdiff/49672659113371c3bee691e6d913d f8e6f60a1d8, `-Wredundant-constraints` is no longer turn on by default. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4528
* Allow PartialTypeSignatures in standalone deriving contextsRyan Scott2018-03-232-2/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At its core, this patch is a simple tweak that allows a user to write: ```lang=haskell deriving instance _ => Eq (Foo a) ``` Which is functionally equivalent to: ```lang=haskell data Foo a = ... deriving Eq ``` But with the added flexibility that `StandaloneDeriving` gives you (namely, the ability to use it anywhere, not just in the same module that `Foo` was declared in). This fixes #13324, and should hopefully address a use case brought up in #10607. Currently, only the use of a single, extra-constraints wildcard is permitted in a standalone deriving declaration. Any other wildcard is rejected, so things like `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden. There are quite a few knock-on changes brought on by this change: * The `HsSyn` type used to represent standalone-derived instances was previously `LHsSigType`, which isn't sufficient to hold wildcard types. This needed to be changed to `LHsSigWcType` as a result. * Previously, `DerivContext` was a simple type synonym for `Maybe ThetaType`, under the assumption that you'd only ever be in the `Nothing` case if you were in a `deriving` clause. After this patch, that assumption no longer holds true, as you can also be in this situation with standalone deriving when an extra-constraints wildcard is used. As a result, I changed `DerivContext` to be a proper datatype that reflects the new wrinkle that this patch adds, and plumbed this through the relevant parts of `TcDeriv` and friends. * Relatedly, the error-reporting machinery in `TcErrors` also assumed that if you have any unsolved constraints in a derived instance, then you should be able to fix it by switching over to standalone deriving. This was always sound advice before, but with this new feature, it's possible to have unsolved constraints even when you're standalone-deriving something! To rectify this, I tweaked some constructors of `CtOrigin` a bit to reflect this new subtlety. This requires updating the Haddock submodule. See my fork at https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7 Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #13324 Differential Revision: https://phabricator.haskell.org/D4383
* Special-case record fields ending with hash when deriving ReadRyan Scott2018-03-232-2/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In commit dbd81f7e86514498218572b9d978373b1699cc5b, a regression was inadvertently introduced which caused derived `Read` instances for record data types with fields ending in a `#` symbol (using `MagicHash`) would no longer parse on valid output. This is ultimately due to the same reasons as #5041, as we cannot parse a field name like `foo#` as a single identifier. We fix this issue by employing the same workaround as in #5041: first parse the identifier name `foo`, then then symbol `#`. This is accomplished by the new `readFieldHash` function in `GHC.Read`. This will likely warrant a `base-4.11.1.0` release. Test Plan: make test TEST=T14918 Reviewers: tdammers, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14918 Differential Revision: https://phabricator.haskell.org/D4502
* Allow as-patterns in unidirectional patttern synonymsSimon Peyton Jones2018-03-211-0/+18
| | | | | | | | | | | | | | This patch implements GHC Proposal #94, described here https://github.com/ghc-proposals/ghc-proposals/pull/94 The effect is simply to lift a totally-undocumented restriction to unidirecional pattern synonyms, namely that they can't have as-patterns or n+k patterns. The fix is easy: just remove the checks. I also took the opportunity to improve the manual entry for the semantics of pattern matching for pattern synonyms.
* relnotes: Fix parsing of Version: field from Cabal fileBen Gamari2018-03-191-2/+2
| | | | | | Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4491
* Add -flate-specialise which runs a later specialisation passMatthew Pickering2018-03-191-0/+14
| | | | | | | | | | | | | | | | | | | | | Runs another specialisation pass towards the end of the optimisation pipeline. This can catch specialisation opportunities which arose from the previous specialisation pass or other inlining. You might want to use this if you are you have a type class method which returns a constrained type. For example, a type class where one of the methods implements a traversal. It is not enabled by default or any optimisation level. Only by manually enabling the flag `-flate-specialise`. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4457
* Fix typo in user guide about ConstraintKindsFrank Steffahn2018-03-191-1/+1
| | | The backslash currently in this type signature makes no sense. Without it, the example is fine.
* Implement -dword-hex-literalsAndrew Martin2018-03-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide flag for showing showing Word# and Word64# as hexadecimal when dumping GHC core. The only affects Word, not Int, and it prefixes the hexadecimal with enough zeroes to make the total character count a power of two. For example: - 0x0C0C instead of 0xC0C - 0x00BA00BA instead of 0xBA00BA This also affects the presentation of Word# and Word64# in GHC's error messages. It is not expected that the flag will be used for this, but it is a side-effect worth noting. Test Plan: none Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, mpickering, rwbarton, thomie, carter, andrewthad GHC Trac Issues: #14872 Differential Revision: https://phabricator.haskell.org/D4465
* rts: Add --internal-counters RTS flag and several countersDouglas Wilson2018-03-191-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing internal counters: * gc_alloc_block_sync * whitehole_spin * gen[g].sync * gen[1].sync are now not shown in the -s report unless --internal-counters is also passed. If --internal-counters is passed we now show the counters above, reformatted, as well as several other counters. In particular, we now count the yieldThread() calls that SpinLocks do as well as their spins. The added counters are: * gc_spin (spin and yield) * mut_spin (spin and yield) * whitehole_threadPaused (spin only) * whitehole_executeMessage (spin only) * whitehole_lockClosure (spin only) * waitForGcThreadsd (spin and yield) As well as the following, which are not SpinLock-like things: * any_work * do_work * scav_find_work See the Note for descriptions of what these counters are. We add busy_wait_nops in these loops along with the counter increment where it was absent. Old internal counters output: ``` gc_alloc_block_sync: 0 whitehole_gc_spin: 0 gen[0].sync: 0 gen[1].sync: 0 ``` New internal counters output: ``` Internal Counters: Spins Yields gc_alloc_block_sync 323 0 gc_spin 9016713 752 mut_spin 57360944 47716 whitehole_gc 0 n/a whitehole_threadPaused 0 n/a whitehole_executeMessage 0 n/a whitehole_lockClosure 0 0 waitForGcThreads 2 415 gen[0].sync 6 0 gen[1].sync 1 0 any_work 2017 no_work 2014 scav_find_work 1004 ``` Test Plan: ./validate Check it builds with #define PROF_SPIN removed from includes/rts/Config.h Reviewers: bgamari, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #3553, #9221 Differential Revision: https://phabricator.haskell.org/D4302
* Remove outdated documentation bits concerning -Wmissing-methodsRyan Scott2018-03-082-17/+4
| | | | | | | | | | | | | | | | | | | In commit 503219e3e1667ac39607021b2d9586260fbab32b, we stopped suppressing `-Wmissing-methods` warnings on class methods whose names begin with an underscore. However, it seems the users' guide documentation concerning this was never updated. Let's do so. Test Plan: Read it Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12959 Differential Revision: https://phabricator.haskell.org/D4476
* Error message and doc improvements for #14335Ömer Sinan Ağacan2018-03-081-0/+3
| | | | | | | | | | | | | | | | | | | | - Show a more friendly error message when -fplugin is used with -fexternal-interpreter - Add a few words to users guide about the interaction with -fplugin and -fexternal-interpreter - Update test for #14335 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14335 Differential Revision: https://phabricator.haskell.org/D4456
* Add -fexternal-dynamic-refsSimon Marlow2018-03-082-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `-dynamic` flag does two things: * In the code generator, it generates code designed to link against external shared libraries. References outside of the current module go through platform-specific indirection tables (e.g. the GOT on ELF). * It enables a "way", which changes which hi files we look for (`Foo.dyn_hi`) and which libraries we link against. Some specialised applications want the first of these without the second. (I could go into detail here but it's probably not all that important). This diff splits out the code-generation effects of `-dynamic` from the "way" parts of its behaviour, via a new flag `-fexternal-dynamic-refs`. Test Plan: validate Reviewers: niteria, bgamari, erikd Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4477
View Lorry Controller Status