summaryrefslogtreecommitdiff
path: root/testsuite/tests/ghci/scripts
Commit message (Collapse)AuthorAgeFilesLines
* Use interactive flags when printing expressions in GHCiMatthew Pickering2022-01-113-0/+5
| | | | | | | | | The documentation states that the interactive flags should be use for any interactive expressions. The interactive flags are used when typechecking these expressions but not when printing. The session flags (modified by :set) are only used when loading a module. Fixes #20909
* Add regression test (#13997)nineonine2022-01-053-0/+17
|
* Multiple Home UnitsMatthew Pickering2021-12-285-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Multiple home units allows you to load different packages which may depend on each other into one GHC session. This will allow both GHCi and HLS to support multi component projects more naturally. Public Interface ~~~~~~~~~~~~~~~~ In order to specify multiple units, the -unit @⟨filename⟩ flag is given multiple times with a response file containing the arguments for each unit. The response file contains a newline separated list of arguments. ``` ghc -unit @unitLibCore -unit @unitLib ``` where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode. ``` -this-unit-id lib-core-0.1.0.0 -i -isrc LibCore.Utils LibCore.Types ``` The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core. ``` -this-unit-id lib-0.1.0.0 -package-id lib-core-0.1.0.0 -i -isrc Lib.Parse Lib.Render ``` Then when the compiler starts in --make mode it will compile both units lib and lib-core. There is also very basic support for multiple home units in GHCi, at the moment you can start a GHCi session with multiple units but only the :reload is supported. Most commands in GHCi assume a single home unit, and so it is additional work to work out how to modify the interface to support multiple loaded home units. Options used when working with Multiple Home Units There are a few extra flags which have been introduced specifically for working with multiple home units. The flags allow a home unit to pretend it’s more like an installed package, for example, specifying the package name, module visibility and reexported modules. -working-dir ⟨dir⟩ It is common to assume that a package is compiled in the directory where its cabal file resides. Thus, all paths used in the compiler are assumed to be relative to this directory. When there are multiple home units the compiler is often not operating in the standard directory and instead where the cabal.project file is located. In this case the -working-dir option can be passed which specifies the path from the current directory to the directory the unit assumes to be it’s root, normally the directory which contains the cabal file. When the flag is passed, any relative paths used by the compiler are offset by the working directory. Notably this includes -i and -I⟨dir⟩ flags. -this-package-name ⟨name⟩ This flag papers over the awkward interaction of the PackageImports and multiple home units. When using PackageImports you can specify the name of the package in an import to disambiguate between modules which appear in multiple packages with the same name. This flag allows a home unit to be given a package name so that you can also disambiguate between multiple home units which provide modules with the same name. -hidden-module ⟨module name⟩ This flag can be supplied multiple times in order to specify which modules in a home unit should not be visible outside of the unit it belongs to. The main use of this flag is to be able to recreate the difference between an exposed and hidden module for installed packages. -reexported-module ⟨module name⟩ This flag can be supplied multiple times in order to specify which modules are not defined in a unit but should be reexported. The effect is that other units will see this module as if it was defined in this unit. The use of this flag is to be able to replicate the reexported modules feature of packages with multiple home units. Offsetting Paths in Template Haskell splices ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When using Template Haskell to embed files into your program, traditionally the paths have been interpreted relative to the directory where the .cabal file resides. This causes problems for multiple home units as we are compiling many different libraries at once which have .cabal files in different directories. For this purpose we have introduced a way to query the value of the -working-dir flag to the Template Haskell API. By using this function we can implement a makeRelativeToProject function which offsets a path which is relative to the original project root by the value of -working-dir. ``` import Language.Haskell.TH.Syntax ( makeRelativeToProject ) foo = $(makeRelativeToProject "./relative/path" >>= embedFile) ``` > If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units. A similar function already exists in the file-embed library. The function in template-haskell implements this function in a more robust manner by honouring the -working-dir flag rather than searching the file system. Closure Property for Home Units ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For tools or libraries using the API there is one very important closure property which must be adhered to: > Any dependency which is not a home unit must not (transitively) depend on a home unit. For example, if you have three packages p, q and r, then if p depends on q which depends on r then it is illegal to load both p and r as home units but not q, because q is a dependency of the home unit p which depends on another home unit r. If you are using GHC by the command line then this property is checked, but if you are using the API then you need to check this property yourself. If you get it wrong you will probably get some very confusing errors about overlapping instances. Limitations of Multiple Home Units ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are a few limitations of the initial implementation which will be smoothed out on user demand. * Package thinning/renaming syntax is not supported * More complicated reexports/renaming are not yet supported. * It’s more common to run into existing linker bugs when loading a large number of packages in a session (for example #20674, #20689) * Backpack is not yet supported when using multiple home units. * Dependency chasing can be quite slow with a large number of modules and packages. * Loading wired-in packages as home units is currently not supported (this only really affects GHC developers attempting to load template-haskell). * Barely any normal GHCi features are supported, it would be good to support enough for ghcid to work correctly. Despite these limitations, the implementation works already for nearly all packages. It has been testing on large dependency closures, including the whole of head.hackage which is a total of 4784 modules from 452 packages. Internal Changes ~~~~~~~~~~~~~~~~ * The biggest change is that the HomePackageTable is replaced with the HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv, which contains information specific to each home unit. * The HomeUnitEnv contains: - A unit state, each home unit can have different package db flags - A set of dynflags, each home unit can have different flags - A HomePackageTable * LinkNode: A new node type is added to the ModuleGraph, this is used to place the linking step into the build plan so linking can proceed in parralel with other packages being built. * New invariant: Dependencies of a ModuleGraphNode can be completely determined by looking at the value of the node. In order to achieve this, downsweep now performs a more complete job of downsweeping and then the dependenices are recorded forever in the node rather than being computed again from the ModSummary. * Some transitive module calculations are rewritten to use the ModuleGraph which is more efficient. * There is always an active home unit, which simplifies modifying a lot of the existing API code which is unit agnostic (for example, in the driver). The road may be bumpy for a little while after this change but the basics are well-tested. One small metric increase, which we accept and also submodule update to haddock which removes ExtendedModSummary. Closes #10827 ------------------------- Metric Increase: MultiLayerModules ------------------------- Co-authored-by: Fendor <power.walross@gmail.com>
* testsuite: Remove reqlib modifierMatthew Pickering2021-12-221-5/+2
| | | | | | | | | | | | | | | | | | | | The reqlib modifer was supposed to indicate that a test needed a certain library in order to work. If the library happened to be installed then the test would run as normal. However, CI has never run these tests as the packages have not been installed and we don't want out tests to depend on things which might get externally broken by updating the compiler. The new strategy is to run these tests in head.hackage, where the tests have been cabalised as well as possible. Some tests couldn't be transferred into the normal style testsuite but it's better than never running any of the reqlib tests. https://gitlab.haskell.org/ghc/head.hackage/-/merge_requests/169 A few submodules also had reqlib tests and have been updated to remove it. Closes #16264 #20032 #17764 #16561
* Ghci environment: Do not remove shadowed idsJoachim Breitner2021-12-1410-5/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Names defined earier but shadowed need to be kept around, e.g. for type signatures: ``` ghci> data T = T ghci> let t = T ghci> data T = T ghci> :t t t :: Ghci1.T ``` and indeed they can be used: ``` ghci> let t2 = Ghci1.T :: Ghci1.T ghci> :t t2 t2 :: Ghci1.T ``` However, previously this did not happen for ids (non-types), although they are still around under the qualified name internally: ``` ghci> let t = "other t" ghci> t' <interactive>:8:1: error: • Variable not in scope: t' • Perhaps you meant one of these: ‘Ghci2.t’ (imported from Ghci2), ‘t’ (line 7), ‘t2’ (line 5) ghci> Ghci2.t <interactive>:9:1: error: • GHC internal error: ‘Ghci2.t’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the expression: Ghci2.t In an equation for ‘it’: it = Ghci2.t ``` This fixes the problem by simply removing the code that tries to remove shadowed ids from the environment. Now you can refer to shadowed ids using `Ghci2.t`, just like you can do for data and type constructors. This simplifies the code, makes terms and types more similar, and also fixes #20455. Now all names ever defined in GHCi are in `ic_tythings`, which is printed by `:show bindings`. But for that commands, it seems to be more ergonomic to only list those bindings that are not shadowed. Or, even if it is not more ergonomic, it’s the current behavour. So let's restore that by filtering in `icInScopeTTs`. Of course a single `TyThing` can be associated with many names. We keep it it in the bindings if _any_ of its names are still visible unqualifiedly. It's a judgement call. This commit also turns a rather old comment into a test files. The comment is is rather stale and things are better explained elsewhere. Fixes #925. Two test cases are regressing: T14052(ghci) ghc/alloc 2749444288.0 12192109912.0 +343.4% BAD T14052Type(ghci) ghc/alloc 7365784616.0 10767078344.0 +46.2% BAD This is not unexpected; the `ic_tythings list grows` a lot more if we don’t remove shadowed Ids. I tried to alleviate it a bit with earlier MRs, but couldn’t make up for it completely. Metric Increase: T14052 T14052Type
* Use HasCallStack and error in GHC.List and .NonEmptyOleg Grenrus2021-12-121-0/+5
| | | | | | | | | | | | | | | | | In addition to providing stack traces, the scary HasCallStack will hopefully make people think whether they want to use these functions, i.e. act as a documentation hint that something weird might happen. A single metric increased, which doesn't visibly use any method with `HasCallStack`. ------------------------- Metric Decrease: T9630 Metric Decrease: T19695 T9630 -------------------------
* Revert "Data.List specialization to []"Matthew Pickering2021-12-035-7/+7
| | | | | | | | | | This reverts commit bddecda1a4c96da21e3f5211743ce5e4c78793a2. This implements the first step in the plan formulated in #20025 to improve the communication and migration strategy for the proposed changes to Data.List. Requires changing the haddock submodule to update the test output.
* Include "not more specific" info in overlap msgsheaf2021-11-202-7/+5
| | | | | | | | | When instances overlap, we now include additional information about why we weren't able to select an instance: perhaps one instance overlapped another but was not strictly more specific, so we aren't able to directly choose it. Fixes #20542
* Improve handling of import statements in GHCi (#20473)Morrow2021-11-179-3/+17
| | | | | | | | | | | | | | | | Currently in GHCi, when given a line of user input we: 1. Attempt to parse and handle it as a statement 2. Otherwise, attempt to parse and handle a single import 3. Otherwise, check if there are imports present (and if so display an error message) 4. Otherwise, attempt to parse a module and only handle the declarations This patch simplifies the process to: Attempt to parse and handle it as a statement Otherwise, attempt to parse a module and handle the imports and declarations This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).
* Increase type sharingBen Gamari2021-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #20541 by making mkTyConApp do more sharing of types. In particular, replace * BoxedRep Lifted ==> LiftedRep * BoxedRep Unlifted ==> UnliftedRep * TupleRep '[] ==> ZeroBitRep * TYPE ZeroBitRep ==> ZeroBitType In each case, the thing on the right is a type synonym for the thing on the left, declared in ghc-prim:GHC.Types. See Note [Using synonyms to compress types] in GHC.Core.Type. The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely in the same spirit as the other ones. (These synonyms are mainly for internal use, though the programmer can use them too.) I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be compatible with the "zero-bit" nomenclature above. See discussion on !6806. There is a tricky wrinkle: see GHC.Core.Types Note [Care using synonyms to compress types] Compiler allocation decreases by up to 0.8%.
* Print the Type kind qualified when ambiguous (#20627)Vladislav Zavialov2021-11-073-0/+31
| | | | | | | | | | | | | | | The Type kind is printed unqualified: ghci> :set -XNoStarIsType ghci> :k (->) (->) :: Type -> Type -> Type This is the desired behavior unless the user has defined their own Type: ghci> data Type Then we want to resolve the ambiguity by qualification: ghci> :k (->) (->) :: GHC.Types.Type -> GHC.Types.Type -> GHC.Types.Type
* Allow CApi FFI calls in GHCiMatthew Pickering2021-11-054-0/+10
| | | | | | | | At some point in the past this started working. I noticed this when working on multiple home units and couldn't load GHC's dependencies into the interpreter. Fixes #7388
* undefined: Neater CallStack in error messageJoachim Breitner2021-10-243-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Users of `undefined` don’t want to see ``` files.hs: Prelude.undefined: CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at file.hs:151:19 in main:Main ``` but want to see ``` files.hs: Prelude.undefined: CallStack (from HasCallStack): undefined, called at file.hs:151:19 in main:Main ``` so let’s make that so. The function for that is `withFrozenCallStack`, but that is not usable here (module dependencies, and also not representation-polymorphic). And even if it were, it could confuse GHC’s strictness analyzer, leading to big regressions in some perf tests (T10421 in particular). So after shuffling modules and definitions around, I eventually noticed that the easiest way is to just not call `error` here. Fixes #19886
* Fix #19884: add warning to tags command, drop T10989Emily Martins2021-10-194-24/+0
|
* ghci: Explicitly store and restore interface file cacheMatthew Pickering2021-10-176-0/+15
| | | | | | | | | | | | | | | | | | | | | In the old days the old HPT was used as an interface file cache when using ghci. The HPT is a `ModuleEnv HomeModInfo` and so if you were using hs-boot files then the interface file from compiling the .hs file would be present in the cache but not the hi-boot file. This used to be ok, because the .hi file used to just be a better version of the .hi-boot file, with more information so it was fine to reuse it. Now the source hash of a module is kept track of in the interface file and the source hash for the .hs and .hs-boot file are correspondingly different so it's no longer safe to reuse an interface file. I took the decision to move the cache management of interface files to GHCi itself, and provide an API where `load` can be provided with a list of interface files which can be used as a cache. An alternative would be to manage this cache somewhere in the HscEnv but it seemed that an API user should be responsible for populating and suppling the cache rather than having it managed implicitly. Fixes #20217
* fuzzyLookup: More deterministic orderJoachim Breitner2021-10-142-5/+5
| | | | | | else the output may depend on the input order, which seems it may depend on the concrete Uniques, which is causing headaches when including test cases about that.
* testsuite: Drop :set from ghci scriptsBen Gamari2021-10-128-316/+2
| | | | | | | | The ghci scripts for T9293 and ghci057 used `:set` to print the currently-set options. However, in neither case was this necessary to the correctness of the test and moreover it would introduce spurious platform-dependence (e.g. since `-fexternal-dynamic-refs` is set by default only on platforms that support dynamic linking).
* Recover test case for T11547Joachim Breitner2021-10-074-0/+19
| | | | | | | | | commit 98c7749 has reverted commit 59d7ee53, including the test that that file added. That test case is still valuable, so I am re-adding it. I add it with it’s current (broken) behavior so that whoever fixes it intentionally or accidentially will notice and then commit the actual desired behavior (which is kinda unspecified, see https://gitlab.haskell.org/ghc/ghc/-/issues/20455#note_382030)
* Improve overlap error for polykinded constraintssheaf2021-10-062-3/+3
| | | | | | | | | | | | | | There were two problems around `mkDictErr`: 1. An outdated call to `flattenTys` meant that we missed out on some instances. As we no longer flatten type-family applications, the logic is obsolete and can be removed. 2. We reported "out of scope" errors in a poly-kinded situation because `BoxedRep` and `Lifted` were considered out of scope. We fix this by using `pretendNameIsInScope`. fixes #20465
* Improve error messages involving operators from Data.Type.OrdChristiaan Baaij2021-09-171-15/+17
| | | | Fixes #20009
* Convert diagnostics in GHC.Tc.Validity to proper TcRnMessage.hainq2021-09-012-2/+2
| | | | | | | | | | | | | | | | | | | | - Add 19 new messages. Update test outputs accordingly. - Pretty print suggest-extensions hints: remove space before interspersed commas. - Refactor Rank's MonoType constructors. Each MonoType constructor should represent a specific case. With the Doc suggestion belonging to the TcRnMessage diagnostics instead. - Move Rank from Validity to its own `GHC.Tc.Types.Rank` module. - Remove the outdated `check_irred_pred` check. - Remove the outdated duplication check in `check_valid_theta`, which was subsumed by `redundant-constraints`. - Add missing test cases for quantified-constraints/T16474 & th/T12387a.
* ghci: Fix rec statements in interactive promptMatthew Pickering2021-08-173-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | We desugar a recursive Stmt to somethign like (a,_,c) <- mfix (\(a,b,_) -> do { ... ; return (a,b,c) }) ...stuff after the rec... The knot-tied tuple must contain * All the variables that are used before they are bound in the `rec` block * All the variables that are used after the entire `rec` block In the case of GHCi, however, we don't know what variables will be used after the `rec` (#20206). For example, we might have ghci> rec { x <- e1; y <- e2 } ghci> print x ghci> print y So we have to assume that *all* the variables bound in the `rec` are used afterwards. We use `Nothing` in the argument to segmentRecStmts to signal that all the variables are used. Fixes #20206
* Fix GHCi completion (#20101)Zubin Duggal2021-08-045-4/+18
| | | | Updates haskeline submodule
* Correctly unload libs on GHCi with external iservTito Sacchi2021-08-031-2/+1
| | | | | | | | | Fix #17669 `hostIsDynamic` is basically a compile-time constant embedded in the RTS. Therefore, GHCi didn't unload object files properly when used with an external interpreter built in a different way.
* Add Generically (generic Semigroup, Monoid instances) and Generically1 ↵Baldur Blöndal2021-08-021-0/+4
| | | | (generic Functor, Applicative, Alternative, Eq1, Ord1 instances) to GHC.Generics.
* ghci: Add test for #18330Matthew Pickering2021-06-255-0/+23
| | | | | | This test was fixed by 25977ab542a30df4ae71d9699d015bcdd1ab7cfb Fixes #18330
* ghci: Correct free variable calculation in StgToByteCodeMatthew Pickering2021-06-232-0/+2
| | | | Fixes #20019
* Port HsToCore messages to new infrastructureAlfredo Di Napoli2021-06-032-3/+4
| | | | | | | | | | | This commit converts a bunch of HsToCore (Ds) messages to use the new GHC's diagnostic message infrastructure. In particular the DsMessage type has been expanded with a lot of type constructors, each encapsulating a particular error and warning emitted during desugaring. Due to the fact that levity polymorphism checking can happen both at the Ds and at the TcRn level, a new `TcLevityCheckDsMessage` constructor has been added to the `TcRnMessage` type.
* Driver Rework PatchMatthew Pickering2021-06-039-26/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch comprises of four different but closely related ideas. The net result is fixing a large number of open issues with the driver whilst making it simpler to understand. 1. Use the hash of the source file to determine whether the source file has changed or not. This makes the recompilation checking more robust to modern build systems which are liable to copy files around changing their modification times. 2. Remove the concept of a "stable module", a stable module was one where the object file was older than the source file, and all transitive dependencies were also stable. Now we don't rely on the modification time of the source file, the notion of stability is moot. 3. Fix TH/plugin recompilation after the removal of stable modules. The TH recompilation check used to rely on stable modules. Now there is a uniform and simple way, we directly track the linkables which were loaded into the interpreter whilst compiling a module. This is an over-approximation but more robust wrt package dependencies changing. 4. Fix recompilation checking for dynamic object files. Now we actually check if the dynamic object file exists when compiling with -dynamic-too Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093
* ghci: Enable -fkeep-going by defaultMatthew Pickering2021-05-296-0/+14
| | | | | | | | | | | This also demotes the error message about -fkeep-going to a trace message which matches the behaviour of other build systems (such as cabal-install and nix) which don't print any message like this on a failure. We want to remove the stable module check in a future patch, which is an approximation of `-fkeep-going`. At the moment this change shouldn't do very much.
* Use pprSigmaType to print GHCi debugger Suspension Terms (Fix #19355)Roland Senn2021-05-201-12/+8
| | | | | | | | In the GHCi debugger use the function `pprSigmaType` to print out Suspension Terms. The function `pprSigmaType` respect the flag `-f(no-)print-explicit-foralls` and so it fixes #19355. Switch back output of existing tests to default mode (no explicit foralls).
* Implement :info for record pattern synonyms (#19462)nineonine2021-05-193-0/+21
|
* Tweak function `quantifyType` to fix #12449Roland Senn2021-05-041-8/+10
| | | | | | | | | | | In function `compiler/GHC/Runtime/Heap/Inspect.hs:quantifyType` replace `tcSplitForAllInvisTyVars` by `tcSplitNestedSigmaTys`. This will properly split off the nested foralls in examples like `:print fmap`. Do not remove the `forall`s from the `snd` part of the tuple returned by `quantifyType`. It's not necessary and the reason for the bug in #12449. Some code simplifications at the calling sites of `quantifyTypes`.
* pe: enable code unloading for WindowsTamar Christina2021-05-031-3/+3
|
* Redesign withDict (formerly magicDict)Ryan Scott2021-04-291-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gives a more precise type signature to `magicDict` as proposed in #16646. In addition, this replaces the constant-folding rule for `magicDict` in `GHC.Core.Opt.ConstantFold` with a special case in the desugarer in `GHC.HsToCore.Expr.dsHsWrapped`. I have also renamed `magicDict` to `withDict` in light of the discussion in https://mail.haskell.org/pipermail/ghc-devs/2021-April/019833.html. All of this has the following benefits: * `withDict` is now more type safe than before. Moreover, if a user applies `withDict` at an incorrect type, the special-casing in `dsHsWrapped` will now throw an error message indicating what the user did incorrectly. * `withDict` can now work with classes that have multiple type arguments, such as `Typeable @k a`. This means that `Data.Typeable.Internal.withTypeable` can now be implemented in terms of `withDict`. * Since the special-casing for `withDict` no longer needs to match on the structure of the expression passed as an argument to `withDict`, it no longer cares about the presence or absence of `Tick`s. In effect, this obsoletes the fix for #19667. The new `T16646` test case demonstrates the new version of `withDict` in action, both in terms of `base` functions defined in terms of `withDict` as well as in terms of functions from the `reflection` and `singletons` libraries. The `T16646Fail` test case demonstrates the error message that GHC throws when `withDict` is applied incorrectly. This fixes #16646. By adding more tests for `withDict`, this also fixes #19673 as a side effect.
* Only load package environment file once when starting GHCiMatthew Pickering2021-04-184-0/+14
| | | | | | | | | | | | | | | Since d880d6b2e48268f5ed4d3eb751fe24cc833e9221 the parsing of the environment files was moved to `parseDynamicFlags`, under the assumption it was typically only called once. It turns out not to be true in GHCi and this led to continually reparsing the environment file whenever a new option was set, the options were appended to the package state and hence all packages reloaded, as it looked like the options were changed. The simplest fix seems to be a clearer specification: > Package environment files are only loaded in GHCi during initialisation. Fixes #19650
* Always generate ModDetails from ModIfaceMatthew Pickering2021-04-145-9/+9
| | | | | | | | | | | | | | | | | | This vastly reduces memory usage when compiling with `--make` mode, from about 900M when compiling Cabal to about 300M. As a matter of uniformity, it also ensures that reading from an interface performs the same as using the in-memory cache. We can also delete all the horrible knot-tying in updateIdInfos. Goes some way to fixing #13586 Accept new output of tests fixing some bugs along the way ------------------------- Metric Decrease: T12545 -------------------------
* Add {lifted,unlifted}DataConKey to pretendNameIsInScope's list of NamesRyan Scott2021-04-138-0/+44
| | | | Fixes #19688.
* Fix magicDict in ghci (and in the presence of other ticks)Matthew Pickering2021-04-104-1/+33
| | | | | | | | | | | The problem was that ghci inserts some ticks around the crucial bit of the expression. Just like in some of the other rules we now strip the ticks so that the rule fires more reliably. It was possible to defeat magicDict by using -fhpc as well, so not just an issue in ghci. Fixes #19667 and related to #19673
* Revert "[ci/arm/darwin/testsuite] Forwards ports from GHC-8.10"Ben Gamari2021-04-051-0/+1
| | | | This reverts commit 0cbdba2768d84a0f6832ae5cf9ea1e98efd739da.
* Correct warning for deprecated and unrecognised flagsAlfredo Di Napoli2021-04-051-1/+1
| | | | | | | | | | Fixes #19616. This commit changes the `GHC.Driver.Errors.handleFlagWarnings` function to rely on the newly introduced `DiagnosticReason`. This allows us to correctly pretty-print the flags which triggered some warnings and in turn remove the cruft around this function (like the extra filtering and the `shouldPrintWarning` function.
* Data.List specialization to []Oleg Grenrus2021-04-012-6/+4
| | | | | | | - Remove GHC.OldList - Remove Data.OldList - compat-unqualified-imports is no-op - update haddock submodule
* [ci/arm/darwin/testsuite] Forwards ports from GHC-8.10Moritz Angermann2021-03-211-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a set of forward ports (cherry-picks) from 8.10 - a7d22795ed [ci] Add support for building on aarch64-darwin - 5109e87e13 [testlib/driver] denoise - 307d34945b [ci] default value for CONFIGURE_ARGS - 10a18cb4e0 [testsuite] mark ghci056 as fragile - 16c13d5acf [ci] Default value for MAKE_ARGS - ab571457b9 [ci/build] Copy config.sub around - 251892b98f [ci/darwin] bump nixpkgs rev - 5a6c36ecb4 [testsuite/darwin] fix conc059 - aae95ef0c9 [ci] add timing info - 3592d1104c [Aarch64] No div-by-zero; disable test. - 57671071ad [Darwin] mark stdc++ tests as broken - 33c4d49754 [testsuite] filter out superfluous dylib warnings - 4bea83afec [ci/nix-shell] Add Foundation and Security - 6345530062 [testsuite/json2] Fix failure with LLVM backends - c3944bc89d [ci/nix-shell] [Darwin] Stop the ld warnings about libiconv. - b821fcc714 [testsuite] static001 is not broken anymore. - f7062e1b0c [testsuite/arm64] fix section_alignment - 820b076698 [darwin] stop the DYLD_LIBRARY_PATH madness - 07b1af0362 [ci/nix-shell] uniquify NIX_LDFLAGS{_FOR_TARGET} As well as a few additional fixups needed to make this block compile: - Fixup all.T - Set CROSS_TARGET, BROKEN_TESTS, XZ, RUNTEST_ARGS, default value. - [ci] shell.nix bump happy
* Built-in type families: CharToNat, NatToChar (#19535)Vladislav Zavialov2021-03-171-0/+4
| | | | | Co-authored-by: Daniel Rogozin <daniel.rogozin@serokell.io> Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io>
* testsuite: Update Win32 test output for GHC2021GHC GitLab CI2021-03-113-26/+4
| | | | Fixes the Windows CI jobs. Requires update of the Win32 submodule.
* Use GHC2021 as default languageJoachim Breitner2021-03-1040-82/+80
|
* Bump bytestring submodule to 0.11.1.0Ben Gamari2021-03-101-2/+1
|
* Implement BoxedRep proposalwip/boxed-repBen Gamari2021-03-078-37/+4
| | | | | | | | | | | | | | | | | | | | | | | This implements the BoxedRep proposal, refactoring the `RuntimeRep` hierarchy from: ```haskell data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ... ``` to ```haskell data RuntimeRep = BoxedRep Levity | ... data Levity = Lifted | Unlifted ``` Updates binary, haddock submodules. Closes #17526. Metric Increase: T12545
* Add cmpNat, cmpSymbol, and cmpCharDaniel Winograd-Cort2021-03-031-15/+37
| | | | | | | Add Data.Type.Ord Add and update tests Metric Increase: MultiLayerModules
* Unify result type earlier to improve error messagesSimon Peyton Jones2021-03-011-9/+6
| | | | | | | | | | | | | | | | | | | | | | Ticket #19364 helpfully points out that we do not currently take advantage of pushing the result type of an application into the arguments. This makes error messages notably less good. The fix is rather easy: move the result-type unification step earlier. It's even a bit more efficient; in the the checking case we now do one less zonk. See Note [Unify with expected type before typechecking arguments] in GHC.Tc.Gen.App This change generally improves error messages, but it made one worse: typecheck/should_fail/T16204c. That led me to the realisation that a good error can be replaced by a less-good one, which provoked me to change GHC.Tc.Solver.Interact.inertsCanDischarge. It's explained in the new Note [Combining equalities] One other refactoring: I discovered that KindEqOrigin didn't need a Maybe in its type -- a nice simplification.
View Lorry Controller Status