summaryrefslogtreecommitdiff
path: root/compiler/utils/FastString.hs
Commit message (Collapse)AuthorAgeFilesLines
* Taming the Kind Inference MonsterSimon Peyton Jones2018-11-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881
* Fix deadlock bug when mkFastStringWith is duplicatedZejun Wu2018-11-221-2/+4
| | | | | | | | | | | | | | | | | | | | In D5211, we use `withMVar` to guard writes to the same segment, this is unsafe to be duplicated. It can lead to deadlock if it is only run partially and `putMVar` is not called after `takeMVar`. Test Plan: ./validate We used to see deadlock when building stackage without this fix, and it no longer happens. Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5349
* Rename literal constructorsSylvain Henry2018-11-221-29/+29
| | | | | | | | | | | | | | | | | | | | | | | | In a previous patch we replaced some built-in literal constructors (MachInt, MachWord, etc.) with a single LitNumber constructor. In this patch we replace the `Mach` prefix of the remaining constructors with `Lit` for consistency (e.g., LitChar, LitLabel, etc.). Sadly the name `LitString` was already taken for a kind of FastString and it would become misleading to have both `LitStr` (literal constructor renamed after `MachStr`) and `LitString` (FastString variant). Hence this patch renames the FastString variant `PtrString` (which is more accurate) and the literal string constructor now uses the least surprising `LitString` name. Both `Literal` and `LitString/PtrString` have recently seen breaking changes so doing this kind of renaming now shouldn't harm much. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4881
* Rewrite FastString table in concurrent hashtableZejun Wu2018-10-281-87/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reimplement global FastString table using a concurrent hashatable with fixed size segments and dynamically growing buckets instead of fixed size buckets. This addresses the problem that `mkFastString` was not linear when the total number of entries was large. Test Plan: ./validate ``` inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null GHCi, version 8.7.20181005: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. FastString stats: segments: 256 buckets: 16384 entries: 7117 largest segment: 64 smallest segment: 64 longest bucket: 5 has z-encoding: 0% ``` Also comapre the two implementation using {P187} The new implementation is on a par with the old version with different conbination of parameters and perform better when the number of FastString's are large. {P188} Reviewers: simonmar, bgamari, niteria Reviewed By: simonmar, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14854 Differential Revision: https://phabricator.haskell.org/D5211
* Refactor LitStringSylvain Henry2018-05-131-18/+17
| | | | | | | | | | | | | | | | | | Refactor LitString so that the string length is computed at most once and then stored. Also remove strlen and memcmp wrappers (it seems like they were a workaround for a very old GCC when using -fvia-C). Bumps haddock submodule. Reviewers: bgamari, dfeuer, nickkuk Reviewed By: bgamari, nickkuk Subscribers: nickkuk, dfeuer, thomie, carter Differential Revision: https://phabricator.haskell.org/D4630
* Change `OPTIONS_GHC -O` to `OPTIONS_GHC -O2`Douglas Wilson2017-11-091-1/+1
| | | | | | | | | | | | | | | These pragmas were having the perverse effect of having these performance critical modules be LESS optimized in builds with -O2. Test Plan: Check on gipedia whether this is worthwhile. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4156
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Add missing Semigroup instances to compilerHerbert Valerio Riedel2017-08-311-1/+5
| | | | | This is a pre-requisite for implementing the Semigroup/Monoid proposal. The instances have been introduced in a way to minimise warnings.
* utils: Lazily decode UTF8 stringsBen Gamari2017-04-171-3/+1
| | | | | | | | | | Reviewers: austin, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #13527 Differential Revision: https://phabricator.haskell.org/D3442
* Improve StringBuffer and FastString docsPhil Ruffwind2016-12-171-0/+13
| | | | | | | | | | | | | | | This area of code contains a lot of unsafe functionality, so it might be worth documenting to reduce the risk of misuse. Test Plan: inspection Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2872
* Make globals use sharedCAFMoritz Angermann2016-12-111-7/+0
| | | | | | | | | | | | | | | | | | | 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-0/+7
| | | | | This reverts commit 6f7ed1e51bf360621a3c2a447045ab3012f68575 due to breakage of the build on Windows.
* Make globals use sharedCAFMoritz Angermann2016-11-291-7/+0
| | | | | | | | | | | | | | | 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
* Add deepseq dependency and a few NFData instancesSimon Marlow2016-07-221-1/+4
| | | | | | | | | | | | | | | | | | | | I needed to rnf a data structure (CompiledByteCode) but we don't have any good deepseq infrastructure in the compiler yet. There are bits and pieces, but nothing consistent, so this is a start. We already had a dependency on deepseq indirectly via other packages (e.g. containers). Includes an update to the haddock submodule, to remove orphan NFData instances in there. Test Plan: validate Reviewers: austin, bgamari, erikd, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2418
* FastString: Supply mconcat implementationBen Gamari2016-07-081-0/+1
| | | | | | | | | | Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2389
* FastString: Add IsString instanceBen Gamari2016-07-081-0/+3
|
* FastString: Reduce allocations of concatFSBen Gamari2016-07-081-1/+1
| | | | | Instead of unpacking and then repacking we simply concatenate all of the individual ByteStrings.
* Remove 'deriving Typeable' statementsRyan Scott2016-05-241-2/+2
| | | | | | | | | | | | | | | | | Summary: Deriving `Typeable` has been a no-op since GHC 7.10, and now that we require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable` statements in GHC. Test Plan: ./validate Reviewers: goldfire, austin, hvr, bgamari Reviewed By: austin, hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2260
* Add Monoid instance for FastStringBen Gamari2016-03-051-0/+4
|
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-4/+0
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* Delete ExtsCompat46 (#8330)Thomas Miedema2015-08-241-4/+4
| | | | | | We require ghc-7.8 to build HEAD (ghc-7.11). Differential Revision: https://phabricator.haskell.org/D1165
* Refactor: delete most of the module FastTypesThomas Miedema2015-08-211-36/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverses some of the work done in #1405, and goes back to the assumption that the bootstrap compiler understands GHC-haskell. In particular: * use MagicHash instead of _ILIT and _CLIT * pattern matching on I# if possible, instead of using iUnbox unnecessarily * use Int#/Char#/Addr# instead of the following type synonyms: - type FastInt = Int# - type FastChar = Char# - type FastPtr a = Addr# * inline the following functions: - iBox = I# - cBox = C# - fastChr = chr# - fastOrd = ord# - eqFastChar = eqChar# - shiftLFastInt = uncheckedIShiftL# - shiftR_FastInt = uncheckedIShiftRL# - shiftRLFastInt = uncheckedIShiftRL# * delete the following unused functions: - minFastInt - maxFastInt - uncheckedIShiftRA# - castFastPtr - panicDocFastInt and pprPanicFastInt * rename panicFastInt back to panic# These functions remain, since they actually do something: * iUnbox * bitAndFastInt * bitOrFastInt Test Plan: validate Reviewers: austin, bgamari Subscribers: rwbarton Differential Revision: https://phabricator.haskell.org/D1141 GHC Trac Issues: #1405
* Use strict atomicModifyIORef' (added in GHC 7.6).Edward Z. Yang2015-01-281-4/+4
| | | | | | | | | | | | Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D635
* compiler: de-lhs utils/Austin Seipp2014-12-031-0/+640
Signed-off-by: Austin Seipp <austin@well-typed.com>
View Lorry Controller Status