summaryrefslogtreecommitdiff
path: root/testsuite/tests/ghci.debugger
Commit message (Collapse)AuthorAgeFilesLines
* Fix #14690 - :steplocal panics after break-on-errorRoland Senn2019-10-264-0/+19
| | | | | | | | | | | | | | `:steplocal` enables only breakpoints in the current top-level binding. When a normal breakpoint is hit, then the module name and the break id from the `BRK_FUN` byte code allow us to access the corresponding entry in a ModBreak table. From this entry we then get the SrcSpan (see compiler/main/InteractiveEval.hs:bindLocalsAtBreakpoint). With this source-span we can then determine the current top-level binding, needed for the steplocal command. However, if we break at an exception or at an error, we don't have an BRK_FUN byte-code, so we don't have any source information. The function `bindLocalsAtBreakpoint` creates an `UnhelpfulSpan`, which doesn't allow us to determine the current top-level binding. To avoid a `panic`, we have to check for `UnhelpfulSpan` in the function `ghc/GHCi/UI.hs:stepLocalCmd`. Hence a :steplocal command after a break-on-exception or a break-on-error is not possible.
* testsuite: Mark print037 as fragile, not brokenBen Gamari2019-10-031-2/+2
| | | | See #16205.
* Fix #8487: Debugger confuses variablesRoland Senn2019-07-214-0/+19
| | | | | | | | | | To display the free variables for a single breakpoint, GHCi pulls out the information from the fields `modBreaks_breakInfo` and `modBreaks_vars` of the `ModBreaks` data structure. For a specific breakpoint this gives 2 lists of types 'Id` (`Var`) and `OccName`. They are used to create the Id's for the free variables and must be kept in sync: If we remove an element from the Names list, then we also must remove the corresponding element from the OccNames list.
* ghci: Don't rely on resolution of System.IO to base moduleBen Gamari2019-06-224-5/+5
| | | | | | | | | Previously we would hackily evaluate a textual code snippet to compute actions to disable I/O buffering and flush the stdout/stderr handles. This broke in a number of ways (#15336, #16563). Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing the needed actions. We can then easily refer to these via `Orig` names.
* Fix #1620: ModBreaks.modBreaks_array not initialisedRoland Senn2019-06-194-0/+34
| | | | | | | | | After a :cd command and after setting some package flags, GHCi unloads all loaded modules by resetting the list of targets. This patch deletes eventually defined debugger breakpoints, before GHCi resets the target list. The common code is factored out into the new function clearAllTargets.
* Add disable/enable commands to ghci debugger #2215Roland Senn2019-06-094-0/+72
| | | | | | | | | | | | | | | | | | | | This patch adds two new commands `:enable` and `:disable` to the GHCi debugger. Opposite to `:set stop <n> :continue` a breakpoint disabled with `:disable` will not loose its previously set stop command. A new field breakEnabled is added to the BreakLocation data structure to track the enable/disable state. When a breakpoint is disabled with a `:disable` command, the following happens: The corresponding BreakLocation data element is searched dictionary of the `breaks` field of the GHCiStateMonad. If the break point is found and not already in the disabled state, the breakpoint is removed from bytecode. The BreakLocation data structure is kept in the breaks list and the new breakEnabled field is set to false. The `:enable` command works similar. The breaks field in the GHCiStateMonad was changed from an association list to int `IntMap`.
* Fix #16700: Tiny errors in output of GHCi commands :forward and :infoRoland Senn2019-06-074-0/+18
| | | | | | `:info Coercible` now outputs the correct section number of the GHCi User's guide together with the secion title. `:forward x` gives the correct syntax hint.
* Reject nested predicates in impredicativity checkingRyan Scott2019-03-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | When GHC attempts to unify a metavariable with a type containing foralls, it will be rejected as an occurrence of impredicativity. GHC was /not/ extending the same treatment to predicate types, such as in the following (erroneous) example from #11514: ```haskell foo :: forall a. (Show a => a -> a) -> () foo = undefined ``` This will attempt to instantiate `undefined` at `(Show a => a -> a) -> ()`, which is impredicative. This patch catches impredicativity arising from predicates in this fashion. Since GHC is pickier about impredicative instantiations, some test cases needed to be updated to be updated so as not to fall afoul of the new validity check. (There were a surprising number of impredicative uses of `undefined`!) Moreover, the `T14828` test case now has slightly less informative types shown with `:print`. This is due to a a much deeper issue with the GHCi debugger (see #14828). Fixes #11514.
* testsuite: Mark print037 as broken when GHC is built with LLVMBen Gamari2019-02-041-1/+4
| | | | As noted in #16205 this configuration reliably segfaults.
* Fix tests for `integer-simple`Alec Theriault2019-01-1629-130/+135
| | | | | | | | | | | | A bunch of tests for `integer-simple` were now broken for a foolish reason: unlike the `integer-gmp` case, there is no CorePrep optimization for turning small integers directly into applications of `S#`. Rather than port this optimization to `integer-simple` (which would involve moving a bunch of `integer-simple` names into `PrelNames`), I switched as many tests as possible to use `Int`. The printing of `Integer` is already tested in `print037`.
* Support printing `integer-simple` Integers in GHCiAlec Theriault2019-01-163-0/+31
| | | | | | | | | | This means that `:p` no longer leaks the implementation details of `Integer` with `integer-simple`. The `print037` test case should exercise all possible code paths for GHCi's code around printing `Integer`s (both in `integer-simple` and `integer-gmp`). `ghc` the package now also has a Cabal `integer-simple` flag (like the `integer-gmp` one).
* testsuite: Fix a number of GHCi-related failures due to integer-simpleBen Gamari2018-12-121-26/+27
| | | | Towards fixing #16043.
* Mark broken tests on powerpc64le and skip ghci-extPeter Trommler2018-12-071-1/+1
| | | | | | | | | | | | | | | Mark tests with DWARF as broken Test way `ghci-ext` only where available Test Plan: validate Reviewers: bgamari, hvr, simonmar, erikd, Phyx Reviewed By: bgamari, Phyx Subscribers: Phyx, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5297
* Clean up TcHsSyn.zonkEnvSimon Peyton Jones2018-08-247-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn. This patch does some minor refactoring * Make ZonkEnv into a record with named fields, and use them. (I'm planning to add a new field, for TyCons, so this prepares the way.) * Replace UnboundTyVarZonker (a higer order function) with the simpler and more self-descriptive ZonkFlexi data type, below. It's just much more perspicuous and direct, and (I suspect) a tiny bit faster too -- no unknown function calls. data ZonkFlexi -- See Note [Un-unified unification variables] = DefaultFlexi -- Default unbound unificaiton variables to Any | SkolemiseFlexi -- Skolemise unbound unification variables -- See Note [Zonking the LHS of a RULE] | RuntimeUnkFlexi -- Used in the GHCi debugger There was one knock-on effect in the GHCi debugger -- the RuntimeUnkFlexi case. Somehow previously, these RuntimeUnk variables were sometimes getting SystemNames (and hence printed as 'a0', 'a1', etc) and sometimes not (and hence printed as 'a', 'b' etc). I'm not sure precisely why, but the new behaviour seems more uniform, so I just accepted the (small) renaming wibbles in some ghci.debugger tests. I had a quick look at perf: any changes are tiny.
* Fix the GHCi debugger with ApplicativeDoSimon Marlow2018-07-224-0/+23
| | | | | | | | | | | | | | | | | | | | | Summary: `collectLStmtsBinders` was returning nothing for `ApplicativeStmts`, which caused the debugger to not track free variables in many cases when using `ApplicativeDo`. Test Plan: * new test case * validate Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15422 Differential Revision: https://phabricator.haskell.org/D4991
* Support the GHCi debugger with -fexternal-interpreterSimon Marlow2018-07-161-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * All the tests in tests/ghci.debugger now pass with -fexternal-interpreter. These tests are now run with the ghci-ext way in addition to the normal way so we won't break it in the future. * I removed all the unsafeCoerce# calls from RtClosureInspect. Yay! The main changes are: * New messages: GetClosure and Seq. GetClosure is a remote interface to GHC.Exts.Heap.getClosureData, which required Binary instances for various datatypes. Fortunately this wasn't too painful thanks to DeriveGeneric. * No cheating by unsafeCoercing values when printing them. Now we have to turn the Closure representation back into the native representation when printing Int, Float, Double, Integer and Char. Of these, Integer was the most painful - we now have a dependency on integer-gmp due to needing access to the representation. * Fixed a bug in rts/Heap.c - it was bogusly returning stack content as pointers for an AP_STACK closure. Test Plan: * `cd testsuite/tests/ghci.debugger && make` * validate Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter GHC Trac Issues: #13184 Differential Revision: https://phabricator.haskell.org/D4955
* Fix nptr field alignment in RtClosureInspectÖmer Sinan Ağacan2018-07-041-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | `extractSubTerms` (which is extracting pointer and non-pointer fields of a closure) was computing the alignment incorrectly when aligning a 64-bit value (e.g. a Double) on i386 by aligning it to 64-bits instead of to word size (32-bits). This is documented in `mkVirtHeapOffsetsWithPadding`: > Align the start offset (eg, 2-byte value should be 2-byte aligned). > But not more than to a word. Fixes #15061 Test Plan: Validated on both 32-bit and 64-bit. 32-bit fails with various unrelated stat failures, but no actual test failures. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15061 Differential Revision: https://phabricator.haskell.org/D4906
* testsuite: Mark print022 as broken on 32-bit platformsBen Gamari2018-06-171-2/+4
| | | | Due to #15061.
* Built-in Natural literals in CoreSylvain Henry2018-06-152-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212
* Do not unpack class dictionaries with INLINABLESimon Peyton Jones2018-04-263-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Matthew Pickering uncovered a bad performance hole in the way that single-method dictionaries work, described in Trac #14955. See Note [Do not unpack class dictionaries] in WwLib. I tried to fix this 6 years ago, but got it slightly wrong. This patch fixes it, which makes a dramatic improvement in the test case. Nofib highlights: not much happening: Program Size Allocs Runtime Elapsed TotalMem ----------------------------------------------------------------- VSM -0.3% +2.7% -7.4% -7.4% 0.0% cacheprof -0.0% +0.1% +0.3% +0.7% 0.0% integer -0.0% +1.1% +7.5% +7.5% 0.0% tak -0.1% -0.2% 0.024 0.024 0.0% ----------------------------------------------------------------- Min -4.4% -0.2% -7.4% -7.4% -8.0% Max +0.6% +2.7% +7.5% +7.5% 0.0% Geom Mean -0.1% +0.0% +0.1% +0.1% -0.2% I investigated VSM. The patch unpacks class dictionaries a bit more than before (i.e. does so if there is no INLINABLE pragma). And that gives better code in VSM (less dictionary selection etc), but one closure gets one word bigger. I'll accept these changes in exchange for more robust performance. Some ghci.debugger output wobbled around (order of bindings being displayed). I have no idea why; but I accepted the changes.
* Revert "GHCi: Don't remove shadowed bindings from typechecker scope."Ömer Sinan Ağacan2018-03-083-15/+0
| | | | | | | | | | | | | | | | | This reverts commit 59d7ee53906b9cee7f279c1f9567af7b930f8636 and enables the test for #14052. (See #14052 for the discussion) Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14052 Differential Revision: https://phabricator.haskell.org/D4478
* Cache TypeRep kinds aggressivelyDavid Feuer2017-12-012-3/+3
| | | | | | | | | | | | | | | | | | | Cache `TypeRep k` in each `TrApp` or `TrTyCon` constructor of `TypeRep (a :: k)`. This makes `typeRepKind` cheap. With this change, we won't need any special effort to deserialize typereps efficiently. The downside, of course, is that we make `TypeRep`s slightly larger. Reviewers: austin, hvr, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: carter, simonpj, rwbarton, thomie GHC Trac Issues: #14254 Differential Revision: https://phabricator.haskell.org/D4085
* RTS: Disable warnings in ffi.hPeter Trommler2017-11-151-2/+4
| | | | | | | | | | | | | | | | | | | | | The update of GHC's in-tree libffi causes warnings about undefined macros and hence validate fails. Also mark broken tests that have a ticket. Fixes #14353 Test Plan: ./validate (on AIX and powerpc if possible) Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #14353, #11259, #14455, #11261 Differential Revision: https://phabricator.haskell.org/D4181
* Allow packing constructor fieldsMichal Terepeta2017-10-294-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is another step for fixing #13825 and is based on D38 by Simon Marlow. The change allows storing multiple constructor fields within the same word. This currently applies only to `Float`s, e.g., ``` data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Float ``` on 64-bit arch, will now store both fields within the same constructor word. For `WordX/IntX` we'll need to introduce new primop types. Main changes: - We now use sizes in bytes when we compute the offsets for constructor fields in `StgCmmLayout` and introduce padding if necessary (word-sized fields are still word-aligned) - `ByteCodeGen` had to be updated to correctly construct the data types. This required some new bytecode instructions to allow pushing things that are not full words onto the stack (and updating `Interpreter.c`). Note that we only use the packed stuff when constructing data types (i.e., for `PACK`), in all other cases the behavior should not change. - `RtClosureInspect` was changed to handle the new layout when extracting subterms. This seems to be used by things like `:print`. I've also added a test for this. - I deviated slightly from Simon's approach and use `PrimRep` instead of `ArgRep` for computing the size of fields. This seemed more natural and in the future we'll probably want to introduce new primitive types (e.g., `Int8#`) and `PrimRep` seems like a better place to do that (where we already have `Int64Rep` for example). `ArgRep` on the other hand seems to be more focused on calling functions. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar, austin, hvr, goldfire, erikd Reviewed By: bgamari Subscribers: maoe, rwbarton, thomie GHC Trac Issues: #13825 Differential Revision: https://phabricator.haskell.org/D3809
* Untag the potential AP_STACK in stg_getApStackValzhJames Clarke2017-10-193-1/+61
| | | | | | | | | | | | | | | | | If the AP_STACK has been evaluated and a GC has run, the BLACKHOLE indirection will have been removed, and the StablePtr for the original AP_STACK referred to be GHCi will therefore now point directly to the value, and may be tagged. Add a hist002 test for this, and make sure hist001 doesn't do an idle GC, so the case when it's still a BLACKHOLE is definitely also tested. Reviewers: austin, bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4099
* RtClosureInspect: Fix inspecting Char# on 64-bit big-endianJames Clarke2017-10-161-2/+1
| | | | | | | | | | | | | | | | | Char# is represented with a full machine word, whereas Char's Storable instance uses an Int32, so we can't just treat it like a single-element Char array. Instead, read it as an Int and use chr to turn it into a Char. This fixes Trac #11262. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11262 Differential Revision: https://phabricator.haskell.org/D4089
* Move NonEmpty definition into GHC.BaseHerbert Valerio Riedel2017-09-042-3/+3
| | | | | | This is a preparatory refactoring for Semigroup=>Monoid as it prevents a messy .hs-boot file which would interact inconveniently with the buildsystem...
* Initialize hs_init with UTF8 encoded arguments on Windows.Andreas Klebinger2017-07-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: Get utf8 encoded arguments before we call hs_init and use them instead of ignoring hs_init arguments. This reduces differing behaviour of the RTS between windows and linux and simplifies the code involved. A few testcases were changed to expect the same result on windows as on linux after the changes. This fixes #13940. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar, Phyx Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #13940 Differential Revision: https://phabricator.haskell.org/D3739
* Improve error messages around kind mismatches.Richard Eisenberg2017-07-271-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, when canonicalizing (or unifying, in uType) a heterogeneous equality, we emitted a kind equality and used the resulting coercion to cast one side of the heterogeneous equality. While sound, this led to terrible error messages. (See the bugs listed below.) The problem is that using the coercion built from the emitted kind equality is a bit like a wanted rewriting a wanted. The solution is to keep heterogeneous equalities as irreducible. See Note [Equalities with incompatible kinds] in TcCanonical. This commit also removes a highly suspicious switch to FM_SubstOnly when flattening in the kinds of a type variable. I have no idea why this was there, other than as a holdover from pre-TypeInType. I've not left a Note because there is simply no reason I can conceive of that the FM_SubstOnly should be there. One challenge with this patch is that the emitted derived equalities might get emitted several times: when a heterogeneous equality is in an implication and then gets floated out from the implication, the Derived is present both in and out of the implication. This causes a duplicate error message. (Test case: typecheck/should_fail/T7368) Solution: track the provenance of Derived constraints and refuse to float out a constraint that has an insoluble Derived. Lastly, this labels one test (dependent/should_fail/RAE_T32a) as expect_broken, because the problem is really #12919. The different handling of constraints in this patch exposes the error. This fixes bugs #11198, #12373, #13530, and #13610. test cases: typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
* Fix TcSimplify.decideQuantification for kind variablesSimon Peyton Jones2017-03-101-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TcSimplify.decideQuantification was doing the Wrong Thing when "growing" the type variables to quantify over. We were trying to do this on a tyvar set where we'd split off the dependent type varaibles; and we just got it wrong. A kind variable wasn't being generalised properly, with confusing knock on consequences. All this led to Trac #13371 and Trac #13393. This commit tidies it all up: * The type TcDepVars is renamed as CandidateQTvs; and splitDepVarsOfType to candidateQTyVarsOfType * The code in TcSimplify.decideQuantification is simpler. It no longer does the tricky "grow" stuff over TcDepVars. Instead it use ordinary VarSets (thereby eliminating the nasty growThetaTyVarsDSet) and uses that to filter the result of candidateQTyVarsOfType. * I documented that candidateQTyVarsOfType returns the type variables in a good order in which to quantify, and rewrote it to use an accumulator pattern, so that we would predicatably get left-to-right ordering. In doing all this I also made UniqDFM behave a little more nicely: * When inserting an element that is there already, keep the old tag, while still overwriting with the new value. * This means that when doing udfmToList we get back elements in the order they were originally inserted, rather than in reverse order. It's not a big deal, but in a subsequent commit I use it to improve the order of type variables in inferred types. All this led to a lot of error message wibbles: - changing the order of quantified variables - changing the order in which instances are listed in GHCi - changing the tidying of variables in typechecker erors There's a submodule update for 'array' because one of its tests has an error-message change. I may not have associated all of them with the correct commit.
* Try submodule bumps againBen Gamari2017-02-281-4/+7
| | | | | | Bumps containers, time, and unix submodules. This reverts commit c347a121b07d22fb91172337407986b6541e319d.
* tests: remove extra_files.py (#12223)Reid Barton2017-02-263-46/+50
| | | | | | | | | | | | The script I used is included as testsuite/driver/kill_extra_files.py, though at this point it is for mostly historical interest. Some of the tests in libraries/hpc relied on extra_files.py, so this commit includes an update to that submodule. One test in libraries/process also relies on extra_files.py, but we cannot update that submodule so easily, so for now we special-case it in the test driver.
* tests: manually move some extra_files into *.T filesReid Barton2017-02-261-1/+2
| | | | | Some of the *.T files were in libraries/hpc, so this contains an update to that submodule.
* Revert recent submodule bumpsBen Gamari2017-02-221-7/+4
| | | | | | | | They broke everything and the solution will be non-trivial. This reverts commit 8ccbc2e5252abd4fa67d155d4fff489ee9929906. This reverts commit c8d995db5d743358b0583fe97f8113bf9047641e. This reverts commit 7153370288e6075c4f8c996ff02227e48805da06.
* Bump Cabal and containers submodulesBen Gamari2017-02-211-4/+7
|
* Type-indexed TypeableBen Gamari2017-02-181-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal.
* Remove clean_cmd and extra_clean usage from .T filesThomas Miedema2017-01-223-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The `clean_cmd` and `extra_clean` setup functions don't do anything. Remove them from .T files. Created using https://github.com/thomie/refactor-ghc-testsuite. This diff is a test for the .T-file parser/processor/pretty-printer in that repository. find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \; Tests containing inline comments or multiline strings are not modified. Preparation for #12223. Test Plan: Harbormaster Reviewers: austin, hvr, simonmar, mpickering, bgamari Reviewed By: mpickering Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D3000 GHC Trac Issues: #12223
* A collection of type-inference refactorings.Simon Peyton Jones2016-10-212-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a raft of useful tidy-ups in the type checker. I've been meaning to do this for some time, and finally made time to do it en route to ICFP. 1. Modify TcType.ExpType to make a distinct data type, InferResult for the Infer case, and consequential refactoring. 2. Define a new function TcUnify.fillInferResult, to fill in an InferResult. It uses TcMType.promoteTcType to promote the type to the level of the InferResult. See TcMType Note [Promoting a type] This refactoring is in preparation for an improvement to typechecking pattern bindings, coming next. I flirted with an elaborate scheme to give better higher rank inference, but it was just too complicated. See TcMType Note [Promotion and higher rank types] 3. Add to InferResult a new field ir_inst :: Bool to say whether or not the type used to fill in the InferResult should be deeply instantiated. See TcUnify Note [Deep instantiation of InferResult]. 4. Add a TcLevel to SkolemTvs. This will be useful generally - it's a fast way to see if the type variable escapes when floating (not used yet) - it provides a good consistency check when updating a unification variable (TcMType.writeMetaTyVarRef, the level_check_ok check) I originally had another reason (related to the flirting in (2), but I left it in because it seems like a step in the right direction. 5. Reduce and simplify the plethora of uExpType, tcSubType and related functions in TcUnify. It was such an opaque mess and it's still not great, but it's better. 6. Simplify the uo_expected field of TypeEqOrigin. Richard had generatlised it to a ExpType, but it was almost always a Check type. Now it's back to being a plain TcType which is much, much easier. 7. Improve error messages by refraining from skolemisation when it's clear that there's an error: see TcUnify Note [Don't skolemise unnecessarily] 8. Type.isPiTy and isForAllTy seem to be missing a coreView check, so I added it 9. Kill off tcs_used_tcvs. Its purpose is to track the givens used by wanted constraints. For dictionaries etc we do that via the free vars of the /bindings/ in the implication constraint ic_binds. But for coercions we just do update-in-place in the type, rather than generating a binding. So we need something analogous to bindings, to track what coercions we have added. That was the purpose of tcs_used_tcvs. But it only worked for a /single/ iteration, whereas we may have multiple iterations of solving an implication. Look at (the old) 'setImplicationStatus'. If the constraint is unsolved, it just drops the used_tvs on the floor. If it becomes solved next time round, we'll pick up coercions used in that round, but ignore ones used in the first round. There was an outright bug. Result = (potentialy) bogus unused-constraint errors. Constructing a case where this actually happens seems quite trick so I did not do so. Solution: expand EvBindsVar to include the (free vars of the) coercions, so that the coercions are tracked in essentially the same way as the bindings. This turned out to be much simpler. Less code, more correct. 10. Make the ic_binds field in an implication have type ic_binds :: EvBindsVar instead of (as previously) ic_binds :: Maybe EvBindsVar This is notably simpler, and faster to use -- less testing of the Maybe. But in the occaional situation where we don't have anywhere to put the bindings, the belt-and-braces error check is lost. So I put it back as an ASSERT in 'setImplicationStatus' (see the use of 'termEvidenceAllowed') All these changes led to quite bit of error message wibbling
* testsuite: Mark break011 as brokenBen Gamari2016-10-171-1/+4
| | | | See #12712.
* GHCi: Don't remove shadowed bindings from typechecker scope.mniip2016-10-012-0/+11
| | | | | | | | | | | | | | | | | | | | | | | The shadowed out bindings are accessible via qualified names like Ghci1.foo. Since they are accessable in the renamer the typechecker should be able to see them too. As a consequence they show up in :show bindings. This fixes T11547 Test Plan: Fixed current tests to accomodate to new stuff in :show bindings Added a test that verifies that the typechecker doesn't crash Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2447 GHC Trac Issues: #11547
* RtClosureInspect: Fix off-by-one error in cvReconstructTypemniip2016-08-233-0/+7
| | | | | | | | | | | | | | | | | Replaced error-prone index manipulation on a pointer array with a simple fold on the array elements. Test Plan: Added a test case that triggers the bug Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2439 GHC Trac Issues: #12458
* InstEnv: Ensure that instance visibility check is lazyBen Gamari2016-07-201-8/+6
| | | | | | | | | | | | | | | | | | | | | Previously instIsVisible had completely broken the laziness of lookupInstEnv' since it would examine is_dfun_name to check the name of the defining module (to know whether it is an interactive module). This resulted in the visibility check drawing in an interface file unnecessarily. This contributed to the unnecessary regression in compiler allocations reported in #12367. Test Plan: Validate, check nofib changes Reviewers: simonpj, ezyang, austin Reviewed By: ezyang Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2411 GHC Trac Issues: #12367
* Testsuite: remove `-Wno-warn-tabs` from default flagsThomas Miedema2016-06-201-1/+1
| | | | This allows the removal of the override_flags stuff in testlib.py.
* Testsuite: tabs -> spaces [skip ci]Thomas Miedema2016-06-204-16/+16
|
* Testsuite: run tests in <testdir>.run instead of /tmpThomas Miedema2016-06-1859-122/+120
| | | | | | | | | | | | | | | | | | | | As discussed in Phab:D1187, this approach makes it a bit easier to inspect the test directory while working on a new test. The only tests that needed changes are the ones that refer to files in ancestor directories. Those files are now copied directly into the test directory. validate still runs the tests in a temporary directory in /tmp, see `Note [Running tests in /tmp]` in testsuite/driver/runtests.py. Update submodule hpc. Reviewed by: simonmar Differential Revision: https://phabricator.haskell.org/D2333 GHC Trac Issues: #11980
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-156-32/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* make accept for Make simplifyInstanceContexts deterministicBartosz Nitka2016-05-101-2/+2
| | | | | Making it deterministic changed some error messages and I forgot to make accept. Relevant change: b58b0e18a568.
* Kill varSetElemsWellScoped in quantifyTyVarsBartosz Nitka2016-04-261-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | varSetElemsWellScoped introduces unnecessary non-determinism in inferred type signatures. Removing this instance required changing the representation of TcDepVars to use deterministic sets. This is the last occurence of varSetElemsWellScoped, allowing me to finally remove it. Test Plan: ./validate I will update the expected outputs when commiting, some reordering of type variables in types is expected. Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2135 GHC Trac Issues: #4012
* Don't infer CallStacksEric Seidel2016-04-042-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We originally wanted CallStacks to be opt-in, but dealing with let binders complicated things, forcing us to infer CallStacks. It turns out that the inference is actually unnecessary though, we can let the wanted CallStacks bubble up to the outer context by refusing to quantify over them. Eventually they'll be solved from a given CallStack or defaulted to the empty CallStack if they reach the top. So this patch prevents GHC from quantifying over CallStacks, getting us back to the original plan. There's a small ugliness to do with PartialTypeSignatures, if the partial theta contains a CallStack constraint, we *do* want to quantify over the CallStack; the user asked us to! Note that this means that foo :: _ => CallStack foo = getCallStack callStack will be an *empty* CallStack, since we won't infer a CallStack for the hole in the theta. I think this is the right move though, since we want CallStacks to be opt-in. One can always write foo :: (HasCallStack, _) => CallStack foo = getCallStack callStack to get the CallStack and still have GHC infer the rest of the theta. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, hvr, bgamari Reviewed By: simonpj, bgamari Subscribers: bitemyapp, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1912 GHC Trac Issues: #11573
* Simplify: Make generated names more usefulBen Gamari2016-03-127-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | makeTrivial is responsible for concocting names during simplification. Previously, however, it would make no attempt to generate a name that might be useful to later readers of the resulting Core. Here we add a bit of state to SimplEnv: a finite depth stack of binders within which we are currently simplifying. We then derive generated binders from this context. See #11676. Open questions: * Is there a better way to accomplish this? * Is `maxContextDepth` too large/small? Test Plan: Validate, look at Core. Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D1970 GHC Trac Issues: #11676
View Lorry Controller Status