summaryrefslogtreecommitdiff
path: root/compiler/prelude
Commit message (Collapse)AuthorAgeFilesLines
...
* Typos in comments only [ci skip]Gabor Greif2017-01-181-1/+1
|
* Refine exprOkForSpeculationSimon Peyton Jones2017-01-161-3/+27
| | | | | | | | | | | | | | | | | This patch implements two related changes, both inspired by the discussion on Trac #13027, comment:23: * exprOkForSpeculation (op# a1 .. an), where op# is a primop, now skips over arguments ai of lifted type. See the comments at Note [Primops with lifted arguments] in CoreUtils. There is no need to treat dataToTag# specially any more. * dataToTag# is now treated as a can-fail primop. See Note [dataToTag#] in primops.txt.pp I don't expect this to have a visible effect on anything, but it's much more solid than before.
* Desugar static forms to makeStatic calls.Facundo Domínguez2017-01-131-0/+11
| | | | | | | | | | | | | | | | | | | Summary: Using makeStatic instead of applications of the StaticPtr data constructor makes possible linting core when unboxing strict fields. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari, hvr Reviewed By: simonpj Subscribers: RyanGlScott, mboes, thomie Differential Revision: https://phabricator.haskell.org/D2930 GHC Trac Issues: #12622
* Revert "Have addModFinalizer expose the local type environment."Facundo Domínguez2017-01-061-11/+0
| | | | This reverts commit e5d1ed9c8910839e109da59820ca793642961284.
* Have addModFinalizer expose the local type environment.Facundo Domínguez2017-01-061-0/+11
| | | | | | | | | | | | | | | | | | | Summary: Kind inference in ghci was interfered when renaming of type splices introduced the HsSpliced data constructor. This patch has kind inference skip over it. Test Plan: ./validate Reviewers: simonpj, rrnewton, austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie, mboes Differential Revision: https://phabricator.haskell.org/D2886 GHC Trac Issues: #12985
* Float unboxed expressions by boxingSimon Peyton Jones2016-12-232-6/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes GHC's floating more robust, by allowing it to float unboxed expressions of at least some common types. See Note [Floating MFEs of unlifted type] in SetLevels. This was all provoked by Trac #12603 In working this through I also made a number of other corner-case changes in SetLevels: * Previously we inconsistently use exprIsBottom (which checks for bottom) instead of exprBotStrictness_maybe (which checks for bottoming functions). As well as being inconsistent it was simply less good. See Note [Bottoming floats] * I fixed a case where were were unprofitably floating an expression because we thought it escaped a value lambda (see Note [Escaping a value lambda]). The relevant code is float_me = (dest_lvl `ltMajLvl` (le_ctxt_lvl env) && not float_is_lam) -- NEW * I made lvlFloatRhs work properly in the case where abs_vars is non-empty. It wasn't wrong before, but it did some stupid extra floating.
* Introduce unboxedSum{Data,Type}Name to template-haskellRyan Scott2016-12-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: In D2448 (which introduced Template Haskell support for unboxed sums), I neglected to add `unboxedSumDataName` and `unboxedSumTypeName` functions, since there wasn't any way you could write unboxed sum data or type constructors in prefix form to begin with (see #12514). But even if you can't write these `Name`s directly in source code, it would still be nice to be able to use these `Name`s in Template Haskell (for instance, to be able to treat unboxed sum type constructors like any other type constructors). Along the way, this uncovered a minor bug in `isBuiltInOcc_maybe` in `TysWiredIn`, which was calculating the arity of unboxed sum data constructors incorrectly. Test Plan: make test TEST=T12478_5 Reviewers: osa1, goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2854 GHC Trac Issues: #12478, #12514
* Verify that known-key uniques fit in interface fileBen Gamari2016-12-151-0/+5
| | | | | | | | | | | | | | Here we introduce a debug check asserting that all uniques in knownKeyNames will fit in the space allowed in the interface file's symbol encoding. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2845
* Make unboxedTuple{Type,Data}Name support 0- and 1-tuplesRyan Scott2016-12-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Previously, these functions were hardcoded so as to always `error` whenever given an argument of 0 or 1. This restriction can be lifted pretty easily, however. This requires a slight tweak to `isBuiltInOcc_maybe` in `TysWiredIn` to allow it to recognize `Unit#` (which is the hard-wired `OccName` for unboxed 1-tuples). Fixes #12977. Test Plan: make test TEST=12977 Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2847 GHC Trac Issues: #12977
* Revert "Float unboxed expressions by boxing"Ben Gamari2016-12-132-34/+6
| | | | This reverts commit bc3d37dada357b04fc5a35f740b4fe7e05292b06.
* Float unboxed expressions by boxingSimon Peyton Jones2016-12-122-6/+34
| | | | | | | | | This patch makes GHC's floating more robust, by allowing it to float unboxed expressions of at least some common types. See Note [Floating MFEs of unlifted type] in SetLevels. This was all provoked by Trac #12603
* Rename TH constructors for deriving strategiesRyan Scott2016-12-091-5/+7
| | | | | | | | | | | | | | | | | | | After talking to Richard, he and I concluded that choosing the rather common name `Newtype` to represent the corresponding deriving strategy in Template Haskell was a poor choice of name. I've opted to rename it to something less common (`NewtypeStrategy`) while we still have time. I also renamed the corrsponding datatype in the GHC internals so as to match it. Reviewers: austin, goldfire, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2814 GHC Trac Issues: #10598
* Scrutinee Constant FoldingSylvain Henry2016-12-091-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces new rules to perform constant folding through case-expressions. E.g., ``` case t -# 10# of _ { ===> case t of _ { 5# -> e1 15# -> e1 8# -> e2 18# -> e2 DEFAULT -> e DEFAULT -> e ``` The initial motivation is that it allows "Merge Nested Cases" optimization to kick in and to further simplify the code (see Trac #12877). Currently we recognize the following operations for Word# and Int#: Add, Sub, Xor, Not and Negate (for Int# only). Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2762 GHC Trac Issues: #12877
* Add HsSyn prettyprinter testsAlan Zimmerman2016-12-073-18/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384
* Overhaul of Compact Regions (#12455)Simon Marlow2016-12-071-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit makes various improvements and addresses some issues with Compact Regions (aka Compact Normal Forms). This was the most important thing I wanted to fix. Compaction previously prevented GC from running until it was complete, which would be a problem in a multicore setting. Now, we compact using a hand-written Cmm routine that can be interrupted at any point. When a GC is triggered during a sharing-enabled compaction, the GC has to traverse and update the hash table, so this hash table is now stored in the StgCompactNFData object. Previously, compaction consisted of a deepseq using the NFData class, followed by a traversal in C code to copy the data. This is now done in a single pass with hand-written Cmm (see rts/Compact.cmm). We no longer use the NFData instances, instead the Cmm routine evaluates components directly as it compacts. The new compaction is about 50% faster than the old one with no sharing, and a little faster on average with sharing (the cost of the hash table dominates when we're doing sharing). Static objects that don't (transitively) refer to any CAFs don't need to be copied into the compact region. In particular this means we often avoid copying Char values and small Int values, because these are static closures in the runtime. Each Compact# object can support a single compactAdd# operation at any given time, so the Data.Compact library now enforces mutual exclusion using an MVar stored in the Compact object. We now get exceptions rather than killing everything with a barf() when we encounter an object that cannot be compacted (a function, or a mutable object). We now also detect pinned objects, which can't be compacted either. The Data.Compact API has been refactored and cleaned up. A new compactSize operation returns the size (in bytes) of the compact object. Most of the documentation is in the Haddock docs for the compact library, which I've expanded and improved here. Various comments in the code have been improved, especially the main Note [Compact Normal Forms] in rts/sm/CNF.c. I've added a few tests, and expanded a few of the tests that were there. We now also run the tests with GHCi, and in a new test way that enables sanity checking (+RTS -DS). There's a benchmark in libraries/compact/tests/compact_bench.hs for measuring compaction speed and comparing sharing vs. no sharing. The field totalDataW in StgCompactNFData was unnecessary. Test Plan: * new unit tests * validate * tested manually that we can compact Data.Aeson data Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2751 GHC Trac Issues: #12455
* Kill Type pretty-printerBen Gamari2016-11-132-3/+6
| | | | | | | | | | | | | | | | | | | | | | Here we consolidate the pretty-printing logic for types in IfaceType. We need IfaceType regardless and the printer for Type can be implemented in terms of that for IfaceType. See #11660. Note that this is very much a work-in-progress. Namely I still have yet to ponder how to ease the hs-boot file situation, still need to rip out more dead code, need to move some of the special cases for, e.g., `*` to the IfaceType printer, and need to get it to validate. That being said, it comes close to validating as-is. Test Plan: Validate Reviewers: goldfire, austin Subscribers: goldfire, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2528 GHC Trac Issues: #11660
* Take account of injectivity when doing fundepsSimon Peyton Jones2016-11-041-0/+5
| | | | | | This fixes Trac #12803. Yikes! See Note [Care with type functions].
* Document unpackClosure# primopÖmer Sinan Ağacan2016-10-281-0/+5
|
* Refactor occurrence-check logicSimon Peyton Jones2016-10-212-3/+5
| | | | | | | | | | | | | | | | This patch does two related things * Combines the occurrence-check logic in the on-the-fly unifier with that in the constraint solver. They are both doing the same job, after all. The resulting code is now in TcUnify: metaTyVarUpdateOK occCheckExpand occCheckForErrors (called in TcErrors) * In doing this I disovered checking for family-free-ness and foralls can be unnecessarily inefficient, because it expands type synonyms. It's easy just to cache this info in the type syononym TyCon, which I am now doing.
* PrelInfo: Fix styleBen Gamari2016-10-131-13/+12
|
* Clean up handling of known-key Names in interface filesBen Gamari2016-10-135-85/+383
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415
* Implement deriving strategiesRyan Scott2016-09-301-61/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allows users to explicitly request which approach to `deriving` to use via keywords, e.g., ``` newtype Foo = Foo Bar deriving Eq deriving stock Ord deriving newtype Show ``` Fixes #10598. Updates haddock submodule. Test Plan: ./validate Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin, erikd, simonmar Reviewed By: alanz, bgamari, simonpj Subscribers: thomie, mpickering, oerjan Differential Revision: https://phabricator.haskell.org/D2280 GHC Trac Issues: #10598
* Turn divInt# and modInt# into bitwise operations when possibleTakano Akio2016-09-053-4/+37
| | | | | | | | | | | | | | | | | | | This implements #5615 for divInt# and modInt#. I also included rules to do constant-folding when the both arguments are known. Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2486 GHC Trac Issues: #5615
* TysWiredIn: Use dataConWorkerUnique instead of incrUniqueBen Gamari2016-08-311-2/+2
| | | | | | | | | | Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2465
* Template Haskell support for TypeApplicationsRyan Scott2016-08-291-30/+32
| | | | | | | | | | | | | | | | Summary: Fixes #12530. Test Plan: make test TEST=12530 Reviewers: austin, bgamari, hvr, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2472 GHC Trac Issues: #12530
* Template Haskell support for unboxed sumsRyan Scott2016-08-231-58/+64
| | | | | | | | | | | | | | | | | | | | | | | This adds new constructors `UnboxedSumE`, `UnboxedSumT`, and `UnboxedSumP` to represent unboxed sums in Template Haskell. One thing you can't currently do is, e.g., `reify ''(#||#)`, since I don't believe unboxed sum type/data constructors can be written in prefix form. I will look at fixing that as part of #12514. Fixes #12478. Test Plan: make test TEST=T12478_{1,2,3} Reviewers: osa1, goldfire, austin, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2448 GHC Trac Issues: #12478
* Support for noinline magic function.Edward Z. Yang2016-08-211-1/+4
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2209
* Remove StgRubbishArg and CmmArgÖmer Sinan Ağacan2016-08-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea behind adding special "rubbish" arguments was in unboxed sum types depending on the tag some arguments are not used and we don't want to move some special values (like 0 for literals and some special pointer for boxed slots) for those arguments (to stack locations or registers). "StgRubbishArg" was an indicator to the code generator that the value won't be used. During Stg-to-Cmm we were then not generating any move or store instructions at all. This caused problems in the register allocator because some variables were only initialized in some code paths. As an example, suppose we have this STG: (after unarise) Lib.$WT = \r [dt_sit] case case dt_sit of { Lib.F dt_siv [Occ=Once] -> (#,,#) [1# dt_siv StgRubbishArg::GHC.Prim.Int#]; Lib.I dt_siw [Occ=Once] -> (#,,#) [2# StgRubbishArg::GHC.Types.Any dt_siw]; } of dt_six { (#,,#) us_giC us_giD us_giE -> Lib.T [us_giC us_giD us_giE]; }; This basically unpacks a sum type to an unboxed sum with 3 fields, and then moves the unboxed sum to a constructor (`Lib.T`). This is the Cmm for the inner case expression (case expression in the scrutinee position of the outer case): ciN: ... -- look at dt_sit's tag if (_ciT::P64 != 1) goto ciS; else goto ciR; ciS: -- Tag is 2, i.e. Lib.F _siw::I64 = I64[_siu::P64 + 6]; _giE::I64 = _siw::I64; _giD::P64 = stg_RUBBISH_ENTRY_info; _giC::I64 = 2; goto ciU; ciR: -- Tag is 1, i.e. Lib.I _siv::P64 = P64[_siu::P64 + 7]; _giD::P64 = _siv::P64; _giC::I64 = 1; goto ciU; Here one of the blocks `ciS` and `ciR` is executed and then the execution continues to `ciR`, but only `ciS` initializes `_giE`, in the other branch `_giE` is not initialized, because it's "rubbish" in the STG and so we don't generate an assignment during code generator. The code generator then panics during the register allocations: ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160722 for x86_64-unknown-linux): LocalReg's live-in to graph ciY {_giE::I64} (`_giD` is also "rubbish" in `ciS`, but it's still initialized because it's a pointer slot, we have to initialize it otherwise garbage collector follows the pointer to some random place. So we only remove assignment if the "rubbish" arg has unboxed type.) This patch removes `StgRubbishArg` and `CmmArg`. We now always initialize rubbish slots. If the slot is for boxed types we use the existing `absentError`, otherwise we initialize the slot with literal 0. Reviewers: simonpj, erikd, austin, simonmar, bgamari Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2446
* ForeignCall.hs: Remove DrIFT directivesÖmer Sinan Ağacan2016-08-021-7/+0
|
* More typos in commentsGabor Greif2016-07-221-1/+1
|
* Correct a few mistyped words in prose/commentsGabor Greif2016-07-221-1/+1
|
* Fix and document Unique generation for sum TyCon and DataConsÖmer Sinan Ağacan2016-07-211-4/+15
| | | | | | | | | | | | Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2420
* Comments onlySimon Peyton Jones2016-07-212-48/+107
|
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-214-14/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements primitive unboxed sum types, as described in https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes. Main changes are: - Add new syntax for unboxed sums types, terms and patterns. Hidden behind `-XUnboxedSums`. - Add unlifted unboxed sum type constructors and data constructors, extend type and pattern checkers and desugarer. - Add new RuntimeRep for unboxed sums. - Extend unarise pass to translate unboxed sums to unboxed tuples right before code generation. - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better code generation when sum values are involved. - Add user manual section for unboxed sums. Some other changes: - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to `MultiValAlt` to be able to use those with both sums and tuples. - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really wrong, given an `Any` `TyCon`, there's no way to tell what its kind is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`. - Fix some bugs on the way: #12375. Not included in this patch: - Update Haddock for new the new unboxed sum syntax. - `TemplateHaskell` support is left as future work. For reviewers: - Front-end code is mostly trivial and adapted from unboxed tuple code for type checking, pattern checking, renaming, desugaring etc. - Main translation routines are in `RepType` and `UnariseStg`. Documentation in `UnariseStg` should be enough for understanding what's going on. Credits: - Johan Tibell wrote the initial front-end and interface file extensions. - Simon Peyton Jones reviewed this patch many times, wrote some code, and helped with debugging. Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin, simonmar, hvr, erikd Reviewed By: simonpj Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2259
* Revert "Clean up interaction between name cache and built-in syntax"Ben Gamari2016-07-203-32/+7
| | | | | | This reverts commit 9513fe6bdeafd35ca1a04e17b5f94732516766aa. Sadly this broke with -DDEBUG.
* Compact RegionsGiovanni Campagna2016-07-203-2/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | This brings in initial support for compact regions, as described in the ICFP 2015 paper "Efficient Communication and Collection with Compact Normal Forms" (Edward Z. Yang et.al.) and implemented by Giovanni Campagna. Some things may change before the 8.2 release, but I (Simon M.) wanted to get the main patch committed so that we can iterate. What documentation there is is in the Data.Compact module in the new compact package. We'll need to extend and polish the documentation before the release. Test Plan: validate (new test cases included) Reviewers: ezyang, simonmar, hvr, bgamari, austin Subscribers: vikraman, Yuras, RyanGlScott, qnikst, mboes, facundominguez, rrnewton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1264 GHC Trac Issues: #11493
* Clean up interaction between name cache and built-in syntaxBen Gamari2016-07-203-33/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This cleans up various aspects of the handling of built-in syntax in the original name cache (hopefully resulting in a nice reduction in compiler allocations), * Remove tuple types from original name cache: There is really no reason for these to be in the name cache since we already handle them specially in interface files to ensure that we can resolve them directly to Names, avoiding extraneous name cache lookups. * Sadly it's not possible to remove all traces of tuples from the name cache, however. Namely we need to keep the tuple type representations in since otherwise they would need to be wired-in * Remove the special cases for (:), [], and (##) in isBuiltInOcc_maybe and rename it to isTupleOcc_maybe * Split lookupOrigNameCache into two variants, * lookupOrigNameCache': Merely looks up an OccName in the original name cache, making no attempt to resolve tuples * lookupOrigNameCache: Like the above but handles tuples as well. This is given the un-primed name since it does the "obvious" thing from the perspective of an API user, who knows nothing of our special treatment of tuples. Arriving at this design took a significant amount of iteration. The trail of debris leading here can be found in #11357. Thanks to ezyang and Simon for all of their help in coming to this solution. Test Plan: Validate Reviewers: goldfire, simonpj, austin Reviewed By: simonpj Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2414 GHC Trac Issues: #11357
* IfaceEnv: Only check for built-in OccNames if mod is GHC.TypesBen Gamari2016-07-161-24/+43
| | | | | | | | | | | | This check is not entirely cheap and will not succeed unless we are looking for something in the module where built-in syntax lives, GHC.Types. Reviewers: simonpj, austin Subscribers: simonpj, thomie, osa1 Differential Revision: https://phabricator.haskell.org/D2400
* TysWiredIn: Use UniqFM lookup for built-in OccNamesBen Gamari2016-07-101-27/+25
| | | | | | | | | | | | | | | | | | | | | Previously we would unpack the OccName into a String, then pattern match against this string. Due to the implementation of `unpackFS`, this actually unpacks the entire contents, even though we often only need to look at the first few characters. Here we take another approach: build a UniqFM with the known built-in OccNames, allowing us to use `FastString`'s hash-based comparison instead. Reviewers: simonpj, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2385 GHC Trac Issues: #12357
* Axe RecFlag on TyCons.Edward Z. Yang2016-06-301-25/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit removes the information about whether or not a TyCon is "recursive", as well as the code responsible for calculating this information. The original trigger for this change was complexity regarding how we computed the RecFlag for hs-boot files. The problem is that in order to determine if a TyCon is recursive or not, we need to determine if it was defined in an hs-boot file (if so, we conservatively assume that it is recursive.) It turns that doing this is quite tricky. The "obvious" strategy is to typecheck the hi-boot file (since we are eventually going to need the typechecked types to check if we properly implemented the hi-boot file) and just extract the names of all defined TyCons from the ModDetails, but this actually does not work well if Names from the hi-boot file are being knot-tied via if_rec_types: the "extraction" process will force thunks, which will force the typechecking process earlier than we have actually defined the types locally. Rather than work around all this trickiness (it certainly can be worked around, either by making interface loading MORE lazy, or just reading of the set of defined TyCons directly from the ModIface), we instead opted to excise the source of the problem, the RecFlag. For one, it is not clear if the RecFlag even makes sense, in the presence of higher-orderness: data T f a = MkT (f a) T doesn't look recursive, but if we instantiate f with T, then it very well is! It was all very shaky. So we just don't bother anymore. This has two user-visible implications: 1. is_too_recursive now assumes that all TyCons are recursive and will bail out in a way that is still mysterious to me if there are too many TyCons. 2. checkRecTc, which is used when stripping newtypes to get to representation, also assumes all TyCons are recursive, and will stop running if we hit the limit. The biggest risk for this patch is that we specialize less than we used to; however, the codeGen tests still seem to be passing. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewers: simonpj, austin, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2360
* s/Invisible/Inferred/g s/Visible/Required/gRichard Eisenberg2016-06-252-3/+3
| | | | | | | | | | | | | This renames VisibilityFlag from > data VisibilityFlag = Visible | Specified | Invisible to > data ArgFlag = Required | Specified | Inferred The old name was quite confusing, because both Specified and Invisible were invisible! The new names are hopefully clearer.
* Fix #11974 by adding a more smarts to TcDefaults.Richard Eisenberg2016-06-231-0/+12
| | | | | | Test cases: typecheck/should_compile/T11974 typecheck/should_fail/T11974b
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-153-139/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, following the TypeInType innovations, each TyCon had two lists: - tyConBinders :: [TyBinder] - tyConTyVars :: [TyVar] They were in 1-1 correspondence and contained overlapping information. More broadly, there were many places where we had to pass around this pair of lists, instead of a single list. This commit tidies all that up, by having just one list of binders in a TyCon: - tyConBinders :: [TyConBinder] The new data types look like this: Var.hs: data TyVarBndr tyvar vis = TvBndr tyvar vis data VisibilityFlag = Visible | Specified | Invisible type TyVarBinder = TyVarBndr TyVar VisibilityFlag TyCon.hs: type TyConBinder = TyVarBndr TyVar TyConBndrVis data TyConBndrVis = NamedTCB VisibilityFlag | AnonTCB TyCoRep.hs: data TyBinder = Named TyVarBinder | Anon Type Note that Var.TyVarBdr has moved from TyCoRep and has been made polymorphic in the tyvar and visiblity fields: type TyVarBinder = TyVarBndr TyVar VisibilityFlag -- Used in ForAllTy type TyConBinder = TyVarBndr TyVar TyConBndrVis -- Used in TyCon type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis -- Ditto, in interface files There are a zillion knock-on changes, but everything arises from these types. It was a bit fiddly to get the module loops to work out right! Some smaller points ~~~~~~~~~~~~~~~~~~~ * Nice new functions TysPrim.mkTemplateKiTyVars TysPrim.mkTemplateTyConBinders which help you make the tyvar binders for dependently-typed TyCons. See comments with their definition. * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code was making an assumption about the order of the kind variables in the kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-152-15/+14
| | | | | | | | | | | | | | | | | | | | | | With TypeInType Richard combined ForAllTy and FunTy, but that was often awkward, and yielded little benefit becuase in practice the two were always treated separately. This patch re-introduces FunTy. Specfically * New type data TyVarBinder = TvBndr TyVar VisibilityFlag This /always/ has a TyVar it. In many places that's just what what we want, so there are /lots/ of TyBinder -> TyVarBinder changes * TyBinder still exists: data TyBinder = Named TyVarBinder | Anon Type * data Type = ForAllTy TyVarBinder Type | FunTy Type Type | .... There are a LOT of knock-on changes, but they are all routine. The Haddock submodule needs to be updated too
* Rename isPinnedByteArray# to isByteArrayPinned#Ben Gamari2016-06-041-2/+8
| | | | | | | | | | | | Reviewers: simonmar, duncan, erikd, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2290 GHC Trac Issues: #12059
* PrelInfo: Ensure that tuple promoted datacon names are in knownKeyNamesBen Gamari2016-06-041-3/+4
| | | | | | | | | | | | | | | | | Previously the promoted datacons of the boxed tuple types were not included in knownKeyNames, which lead to #12132. Test Plan: Test with included TypeOf testcase Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2279 GHC Trac Issues: #12132
* Reduce special-casing for nullary unboxed tupleSimon Peyton Jones2016-05-261-7/+4
| | | | | | | | | | | | | | | When we built the kind of a nullary unboxed tuple, we said, in TysWiredIn.mk_tuple: res_rep | arity == 0 = voidRepDataConTy -- See Note [Nullary unboxed tuple] in Type | otherwise = unboxedTupleRepDataConTy But this is bogus. The Note deals with what the 'unarise' transformation does, and up to that point it's simpler and more uniform to treat nullary unboxed tuples the same as all the others. Nicer now. And it fixes the Lint error in Trac #12115
* Remove 'deriving Typeable' statementsRyan Scott2016-05-241-6/+6
| | | | | | | | | | | | | | | | | 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
* rts: Add isPinnedByteArray# primopBen Gamari2016-05-181-0/+5
| | | | | | | | | | | | | | | | | Adds a primitive operation to determine whether a particular `MutableByteArray#` is backed by a pinned buffer. Test Plan: Validate with included testcase Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2217 GHC Trac Issues: #12059
* Add TH support for pattern synonyms (fixes #8761)Dominik Bollmann2016-05-121-72/+102
| | | | | | | | | | | | | | | | | | This commit adds Template Haskell support for pattern synonyms as requested by trac ticket #8761. Test Plan: ./validate Reviewers: thomie, jstolarek, osa1, RyanGlScott, mpickering, austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: rdragon Differential Revision: https://phabricator.haskell.org/D1940 GHC Trac Issues: #8761
View Lorry Controller Status