summaryrefslogtreecommitdiff
path: root/testsuite/tests/ghci/scripts
Commit message (Collapse)AuthorAgeFilesLines
* Overloaded Quotation Brackets (#246)Matthew Pickering2020-01-121-1/+1
| | | | | | | | | | | | | | | | | | This patch implements overloaded quotation brackets which generalise the desugaring of all quotation forms in terms of a new minimal interface. The main change is that a quotation, for example, [e| 5 |], will now have type `Quote m => m Exp` rather than `Q Exp`. The `Quote` typeclass contains a single method for generating new names which is used when desugaring binding structures. The return type of functions from the `Lift` type class, `lift` and `liftTyped` have been restricted to `forall m . Quote m => m Exp` rather than returning a result in a Q monad. More details about the feature can be read in the GHC proposal. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0246-overloaded-bracket.rst
* testsuite: Add test for #17549Ben Gamari2019-12-122-0/+7
|
* Make sameNat and sameSymbol proxy-polymorphicBodigrim2019-12-051-4/+2
|
* Fix #17405 by not checking imported equationsRichard Eisenberg2019-11-101-20/+27
| | | | | | | | | | | | | Previously, we checked all imported type family equations for injectivity. This is very silly. Now, we check only for conflicts. Before I could even imagine doing the fix, I needed to untangle several functions that were (in my opinion) overly complicated. It's still not quite as perfect as I'd like, but it's good enough for now. Test case: typecheck/should_compile/T17405
* Use the right type in :forceSimon Peyton Jones2019-11-094-0/+26
| | | | | | | | A missing prime meant that we were considering the wrong type in the GHCi debugger, when doing :force on multiple arguments (issue #17431). The fix is trivial.
* Testsuite: Introduce req_rts_linkerStefan Schulze Frielinghaus2019-11-081-4/+4
| | | | | Some tests depend on the RTS linker. Introduce a modifier to skip such tests, in case the RTS linker is not available.
* testsuite: skip test requiring RTS linker on PowerPCPeter Trommler2019-11-051-6/+2
| | | | | | | | | | The RTS linker is not available on 64-bit PowerPC. Instead of marking tests that require the RTS linker as broken on PowerPC 64-bit skip the respective tests on all platforms where the RTS linker or a statically linked external interpreter is not available. Fixes #11259
* Parenthesize nullary constraint tuples using sigPrec (#17403)Ryan Scott2019-10-274-0/+12
| | | | | | | | | We were using `appPrec`, not `sigPrec`, as the precedence when determining whether or not to parenthesize `() :: Constraint`, which lead to the parentheses being omitted in function contexts like `(() :: Constraint) => String`. Easily fixed. Fixes #17403.
* Parenthesize GADT return types in pprIfaceConDecl (#17384)Ryan Scott2019-10-244-0/+16
| | | | | | | We were using `pprIfaceAppArgs` instead of `pprParendIfaceAppArgs` in `pprIfaceConDecl`. Oops. Fixes #17384.
* Allow command name resolution for GHCi commands with option `!` #17345Takenobu Tani2019-10-233-0/+12
| | | | | | | | | | | | | | | | | | | | This commit allows command name resolution for GHCi commands with option `!` as follows: ghci> :k! Int Int :: * = Int This commit changes implementation as follows: Before: * Prefix match with full string including the option `!` (e.g. `k!`) After (this patch): * Prefix match without option suffix `!` (e.g. `k`) * in addition, suffix match with option `!` See also #8305 and #8113
* Implement a coverage checker for injectivityRichard Eisenberg2019-10-231-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes #16512. There are lots of parts of this patch: * The main payload is in FamInst. See Note [Coverage condition for injective type families] there for the overview. But it doesn't fix the bug. * We now bump the reduction depth every time we discharge a CFunEqCan. See Note [Flatten when discharging CFunEqCan] in TcInteract. * Exploration of this revealed a new, easy to maintain invariant for CTyEqCans. See Note [Almost function-free] in TcRnTypes. * We also realized that type inference for injectivity was a bit incomplete. This means we exchanged lookupFlattenTyVar for rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new function is monadic while the previous one was pure, necessitating some faff in TcInteract. Nothing too bad. * zonkCt did not maintain invariants on CTyEqCan. It's not worth the bother doing so, so we just transmute CTyEqCans to CNonCanonicals. * The pure unifier was finding the fixpoint of the returned substitution, even when doing one-way matching (in tcUnifyTysWithTFs). Fixed now. Test cases: typecheck/should_fail/T16512{a,b}
* testsuite: Add test for #8305Takenobu Tani2019-10-163-0/+45
| | | | | | | | This is a test for the current algorithm of GHCi command name resolution. I add this test in preparation for updating GHCi command name resolution. For the current algorithm, see https://downloads.haskell.org/ghc/latest/docs/html/users_guide/ghci.html#the-ghci-files
* Add Monad instances to `(,,) a b` and `(,,,) a b c`Fumiaki Kinoshita2019-10-041-0/+2
|
* testsuite: Add minimal test for :doc commandTakenobu Tani2019-09-304-0/+47
| | | | | | | | | | Currently, there are no testcases for GHCi `:doc` command. Perhaps because it was experimental. And it could be changed in the future. But `:doc` command is already useful, so I add a minimal regression test to keep current behavior. See also 85309a3cda for implementation of `:doc` command.
* Make -fbyte-code prevent unboxed tuples/sums from implying object code (#16876)Ryan Scott2019-09-265-0/+32
| | | | | | | | | | | | | | | | | | | | This resolves #16876 by making the explicit use of `-fbyte-code` prevent code that enables `UnboxedTuples` or `UnboxedSums` from automatically compiling to object code. This allows for a nice middle ground where most code that enables `UnboxedTuples`/-`Sums` will still benefit from automatically enabling `-fobject-code`, but allows power users who wish to avoid this behavior in certain corner cases (such as `lens`, whose use case is documented in #16876) to do so. Along the way, I did a little cleanup of the relevant code and documentation: * `enableCodeGenForUnboxedTuples` was only checking for the presence of `UnboxedTuples`, but `UnboxedSums` has the same complications. I fixed this and renamed the function to `enableCodeGenForUnboxedTuplesOrSums`. * I amended the users' guide with a discussion of these issues.
* Standalone kind signatures (#16794)wip/top-level-kind-signaturesVladislav Zavialov2019-09-2549-118/+304
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst With this patch, a type constructor can now be given an explicit standalone kind signature: {-# LANGUAGE StandaloneKindSignatures #-} type Functor :: (Type -> Type) -> Constraint class Functor f where fmap :: (a -> b) -> f a -> f b This is a replacement for CUSKs (complete user-specified kind signatures), which are now scheduled for deprecation. User-facing changes ------------------- * A new extension flag has been added, -XStandaloneKindSignatures, which implies -XNoCUSKs. * There is a new syntactic construct, a standalone kind signature: type <name> :: <kind> Declarations of data types, classes, data families, type families, and type synonyms may be accompanied by a standalone kind signature. * A standalone kind signature enables polymorphic recursion in types, just like a function type signature enables polymorphic recursion in terms. This obviates the need for CUSKs. * TemplateHaskell AST has been extended with 'KiSigD' to represent standalone kind signatures. * GHCi :info command now prints the kind signature of type constructors: ghci> :info Functor type Functor :: (Type -> Type) -> Constraint ... Limitations ----------- * 'forall'-bound type variables of a standalone kind signature do not scope over the declaration body, even if the -XScopedTypeVariables is enabled. See #16635 and #16734. * Wildcards are not allowed in standalone kind signatures, as partial signatures do not allow for polymorphic recursion. * Associated types may not be given an explicit standalone kind signature. Instead, they are assumed to have a CUSK if the parent class has a standalone kind signature and regardless of the -XCUSKs flag. * Standalone kind signatures do not support multiple names at the moment: type T1, T2 :: Type -> Type -- rejected type T1 = Maybe type T2 = Either String See #16754. * Creative use of equality constraints in standalone kind signatures may lead to GHC panics: type C :: forall (a :: Type) -> a ~ Int => Constraint class C a where f :: C a => a -> Int See #16758. Implementation notes -------------------- * The heart of this patch is the 'kcDeclHeader' function, which is used to kind-check a declaration header against its standalone kind signature. It does so in two rounds: 1. check user-written binders 2. instantiate invisible binders a la 'checkExpectedKind' * 'kcTyClGroup' now partitions declarations into declarations with a standalone kind signature or a CUSK (kinded_decls) and declarations without either (kindless_decls): * 'kinded_decls' are kind-checked with 'checkInitialKinds' * 'kindless_decls' are kind-checked with 'getInitialKinds' * DerivInfo has been extended with a new field: di_scoped_tvs :: ![(Name,TyVar)] These variables must be added to the context in case the deriving clause references tcTyConScopedTyVars. See #16731.
* base: Move Ix typeclass to GHC.IxBen Gamari2019-09-251-1/+1
| | | | | The `Ix` class seems rather orthogonal to its original home in `GHC.Arr`.
* Improve error message for out-of-scope variables + VTASimon Peyton Jones2019-09-171-5/+0
| | | | | | | | | | As #13834 and #17150 report, we get a TERRIBLE error message when you have an out of scope variable applied in a visible type application: (outOfScope @Int True) This very simple patch improves matters. See TcExpr Note [VTA for out-of-scope functions]
* Add additional step to T16804Eric Wolf2019-08-316-198/+889
| | | | | | | | | | | | | | | | Add another small test step Use the same identifier name in different scopes and see, if ':uses' handles that. Add another test step to check wether local bindings with the same identifier name might get confused Add easier to understand test output Fix annotated lines from file correctly
* GHCi supports not-necessarily-lifted join pointsRichard Eisenberg2019-08-143-0/+13
| | | | | | | | | | | | | | | | Fixes #16509. See Note [Not-necessarily-lifted join points] in ByteCodeGen, which tells the full story. This commit also adds some comments and cleans some code in the byte-code generator, as I was exploring around trying to understand it. (This commit removes an old test -- this is really a GHCi problem, not a pattern-synonym problem.) test case: ghci/scripts/T16509
* Fix testmniip2019-08-071-1/+1
|
* Explicitly number equations when printing axiom incompatibilitiesmniip2019-08-071-3/+3
|
* Fix testmniip2019-08-071-9/+7
|
* Add a -fprint-axiom-incomps option (#15546)mniip2019-08-073-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Supply branch incomps when building an IfaceClosedSynFamilyTyCon `pprTyThing` now has access to incomps. This also causes them to be written out to .hi files, but that doesn't pose an issue other than a more faithful bijection between `tyThingToIfaceDecl` and `tcIfaceDecl`. The machinery for displaying axiom incomps was already present but not in use. Since this is now a thing that pops up in ghci's :info the format was modified to look like a haskell comment. Documentation and a test for the new feature included. Test Plan: T15546 Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15546 Differential Revision: https://phabricator.haskell.org/D5097
* Make sure to load interfaces when running :instancesXavier Denis2019-07-231-0/+18
|
* rename type parameter in `instance Applicative ((->) a)`, fixing #16928xplorld2019-07-142-2/+2
|
* T16804: adjust src spansEric Wolf2019-07-093-157/+161
|
* Add testcase T16804 for #16804Eric Wolf2019-07-096-0/+415
| | | | | slightly larger testcase for :type-at and :uses so we can see changes, if #16804 is done.
* Add test for #16575Eric Wolf2019-07-024-0/+54
| | | | | just use the test to show the defective behaviour, so we can see the difference, when it gets fixed
* testsuite: Mark ghci058 as broken on WindowsBen Gamari2019-06-251-1/+2
| | | | Due to #16858.
* testsuite: Add test for #16563Ben Gamari2019-06-223-0/+4
|
* ghci: Don't rely on resolution of System.IO to base moduleBen Gamari2019-06-225-16/+10
| | | | | | | | | 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 #16517 by bumping the TcLevel for method sigsRichard Eisenberg2019-06-093-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were actually two bugs fixed here: 1. candidateQTyVarsOfType needs to be careful that it does not try to zap metavariables from an outer scope as "naughty" quantification candidates. This commit adds a simple check to avoid doing so. 2. We weren't bumping the TcLevel in kcHsKindSig, which was used only for class method sigs. This mistake led to the acceptance of class C a where meth :: forall k. Proxy (a :: k) -> () Note that k is *locally* quantified. This patch fixes the problem by using tcClassSigType, which correctly bumps the level. It's a bit inefficient because tcClassSigType does other work, too, but it would be tedious to repeat much of the code there with only a few changes. This version works well and is simple. And, while updating comments, etc., I noticed that tcRnType was missing a pushTcLevel, leading to #16767, which this patch also fixes, by bumping the level. In the refactoring here, I also use solveEqualities. This initially failed ghci/scripts/T15415, but that was fixed by teaching solveEqualities to respect -XPartialTypeSignatures. This patch also cleans up some Notes around error generation that came up in conversation. Test case: typecheck/should_fail/T16517, ghci/scripts/T16767
* Fix #16700: Tiny errors in output of GHCi commands :forward and :infoRoland Senn2019-06-071-1/+2
| | | | | | `: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.
* Add GHCi :instances commandXavier Denis2019-06-044-1/+78
| | | | | | | | | | | This commit adds the `:instances` command to ghci following proosal number 41. This makes it possible to query which instances are available to a given type. The output of this command is all the possible instances with type variables and constraints instantiated.
* Fix bugs and documentation for #13456Roland Senn2019-05-102-2/+2
|
* Make equality constraints in kinds invisibleRyan Scott2019-05-034-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issues #12102 and #15872 revealed something strange about the way GHC handles equality constraints in kinds: it treats them as _visible_ arguments! This causes a litany of strange effects, from strange error messages (https://gitlab.haskell.org/ghc/ghc/issues/12102#note_169035) to bizarre `Eq#`-related things leaking through to GHCi output, even without any special flags enabled. This patch is an attempt to contain some of this strangeness. In particular: * In `TcHsType.etaExpandAlgTyCon`, we propagate through the `AnonArgFlag`s of any `Anon` binders. Previously, we were always hard-coding them to `VisArg`, which meant that invisible binders (like those whose kinds were equality constraint) would mistakenly get flagged as visible. * In `ToIface.toIfaceAppArgsX`, we previously assumed that the argument to a `FunTy` always corresponding to a `Required` argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map `VisArg` to `Required` and `InvisArg` to `Inferred`. As a consequence, the iface pretty-printer correctly recognizes that equality coercions are inferred arguments, and as a result, only displays them in `-fprint-explicit-kinds` is enabled. * Speaking of iface pretty-printing, `Anon InvisArg` binders were previously being pretty-printed like `T (a :: b ~ c)`, as if they were required. This seemed inconsistent with other invisible arguments (that are printed like `T @{d}`), so I decided to switch this to `T @{a :: b ~ c}`. Along the way, I also cleaned up a minor inaccuracy in the users' guide section for constraints in kinds that was spotted in https://gitlab.haskell.org/ghc/ghc/issues/12102#note_136220. Fixes #12102 and #15872.
* Correct off by one error in ghci +cMatthew Pickering2019-04-224-0/+10
| | | | Fixes #16569
* Use funPrec, not topPrec, to parenthesize GADT argument typesRyan Scott2019-04-044-0/+14
| | | | A simple oversight. Fixes #16527.
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-224-3/+4
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Reject nested predicates in impredicativity checkingRyan Scott2019-03-202-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Don't mark T5836 as brokenBen Gamari2019-03-201-3/+1
| | | | I believe removing __mingw_vsnwprintf from RtsSymbols fixed #16387.
* testsuite: Mark T5836 as broken on WindowsBen Gamari2019-03-201-1/+3
| | | | See #16387.
* testsuite: Fix expected output on Windows for various ghci testsBen Gamari2019-03-203-9/+0
| | | | | Broke as -Wimplicit-kind-vars no longer exists. Specifically ghci024, ghci057 and T9293.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-158-8/+8
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Remove the GHCi debugger's panicking isUnliftedType checkRyan Scott2019-03-153-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GHCi debugger has never been that robust in the face of higher-rank types, or even types that are _interally_ higher-rank, such as the types of many class methods (e.g., `fmap`). In GHC 8.2, however, things became even worse, as the debugger would start to _panic_ when a user tries passing the name of a higher-rank thing to `:print`. This all ties back to a strange `isUnliftedType` check in `Debugger` that was mysteriously added 11 years ago (in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no explanation whatsoever. After some experimentation, no one is quite sure what this `isUnliftedType` check is actually accomplishing. The test suite still passes if it's removed, and I am unable to observe any differences in debugger before even with data types that _do_ have fields of unlifted types (e.g., `data T = MkT Int#`). Given that this is actively causing problems (see #14828), the prudent thing to do seems to be just removing this `isUnliftedType` check, and waiting to see if anyone shouts about it. This patch accomplishes just that. Note that this patch fix the underlying issues behind #14828, as the debugger will still print unhelpful info if you try this: ``` λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f f = (_t1::t1) ``` But fixing this will require much more work, so let's start with the simple stuff for now.
* Ignore more version numbers in the testsuiteAlec Theriault2019-03-111-1/+2
| | | | | | | | | Prevents some tests from failing just due to mismatched version numbers. These version numbers shouldn't cause tests to fail, especially since we *expect* them to be regularly incremented. The motivation for this particular set of changes came from the changes that came along with the `base` version bump in 8f19ecc95fbaf2cc977531d721085d8441dc09b7.
* Use captureTopConstraints in TcRnDriver callsSimon Peyton Jones2019-03-084-0/+19
| | | | | | | | | | | | | | | | | Trac #16376 showed the danger of failing to report an error that exists only in the unsolved constraints, if an exception is raised (via failM). Well, the commit 5c1f268e (Fail fast in solveLocalEqualities) did just that -- i.e. it found errors in the constraints, and called failM to avoid a misleading cascade. So we need to be sure to call captureTopConstraints to report those insolubles. This was wrong in TcRnDriver.tcRnExpr and in TcRnDriver.tcRnType. As a result the error messages from test T13466 improved slightly, a happy outcome.
* Fix #16391 by using occCheckExpand in TcValidityRyan Scott2019-03-071-5/+5
| | | | | | | | | | | | | The type-variables-escaping-their-scope-via-kinds check in `TcValidity` was failing to properly expand type synonyms, which led to #16391. This is easily fixed by using `occCheckExpand` before performing the validity check. Along the way, I refactored this check out into its own function, and sprinkled references to Notes to better explain all of the moving parts. Many thanks to @simonpj for the suggestions. Bumps the haddock submodule.
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-274-16/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error.
View Lorry Controller Status