summaryrefslogtreecommitdiff
path: root/compiler/GHC/Tc
Commit message (Collapse)AuthorAgeFilesLines
* Tag inference work.Andreas Klebinger2022-02-124-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does three major things: * Enforce the invariant that all strict fields must contain tagged pointers. * Try to predict the tag on bindings in order to omit tag checks. * Allows functions to pass arguments unlifted (call-by-value). The former is "simply" achieved by wrapping any constructor allocations with a case which will evaluate the respective strict bindings. The prediction is done by a new data flow analysis based on the STG representation of a program. This also helps us to avoid generating redudant cases for the above invariant. StrictWorkers are created by W/W directly and SpecConstr indirectly. See the Note [Strict Worker Ids] Other minor changes: * Add StgUtil module containing a few functions needed by, but not specific to the tag analysis. ------------------------- Metric Decrease: T12545 T18698b T18140 T18923 LargeRecord Metric Increase: LargeRecord ManyAlternatives ManyConstructors T10421 T12425 T12707 T13035 T13056 T13253 T13253-spj T13379 T15164 T18282 T18304 T18698a T1969 T20049 T3294 T4801 T5321FD T5321Fun T783 T9233 T9675 T9961 T19695 WWRec -------------------------
* Refine tcSemigroupWarnings to work in ghc-primMatthew Pickering2022-02-101-4/+7
| | | | | | | | | | | | | ghc-prim doesn't depend on base so can't have any Monoid or Semigroup instances. However, attempting to load these definitions ran into issues when the interface for `GHC.Base` did exist as that would try and load the interface for `GHC.Types` (which is the module we are trying to compile and has no interface). The fix is to just not do this check when we are compiling a module in ghc-prim. Fixes #21069
* Look through untyped TH splices in tcInferAppHead_maybeRyan Scott2022-02-092-13/+26
| | | | | | | | | | | Previously, surrounding a head expression with a TH splice would defeat `tcInferAppHead_maybe`, preventing some expressions from typechecking that used to typecheck in previous GHC versions (see #21038 for examples). This is simple enough to fix: just look through `HsSpliceE`s in `tcInferAppHead_maybe`. I've added some additional prose to `Note [Application chains and heads]` in `GHC.Tc.Gen.App` to accompany this change. Fixes #21038.
* Fix some notesMatthew Pickering2022-02-0812-16/+16
|
* Relax TyEq:N: allow out-of-scope newtype DataConsheaf2022-02-081-8/+20
| | | | | | | | | | The 'bad_newtype' assertion in GHC.Tc.Solver.Canonical.canEqCanLHSFinish failed to account for the possibility that the newtype constructor might not be in scope, in which case we don't provide any guarantees about canonicalising away a newtype on the RHS of a representational equality. Fixes #21010
* Allow HasField in quantified constraintssheaf2022-02-081-0/+4
| | | | | | | | | | | | | | | | | | | | We perform validity checking on user-written HasField instances, for example to disallow: data Foo a = Foo { fld :: Int } instance HasField "fld" (Foo a) Bool However, these checks were also being made on quantified constraints, e.g. data Bar where Bar :: (forall a. HasField s (Foo a) Int) => Proxy s -> Bar This patch simply skips validity checking for quantified constraints, in line with what we already do for equality constraints such as Coercible. Fixes #20989
* Make implication tidying agree with Note [Tidying multiple names at once]Matthew Pickering2022-02-051-2/+2
| | | | | | | | | | | Note [Tidying multiple names at once] indicates that if multiple variables have the same name then we shouldn't prioritise one of them and instead rename them all to a1, a2, a3... etc This patch implements that change, some error message changes as expected. Closes #20932
* Improve errors for non-existent labelsSimon Peyton Jones2022-02-043-11/+3
| | | | | | | | | | | | | | | | This patch fixes #17469, by improving matters when you use non-existent field names in a record construction: data T = MkT { x :: Int } f v = MkT { y = 3 } The check is now made in the renamer, in GHC.Rename.Env.lookupRecFieldOcc. That in turn led to a spurious error in T9975a, which is fixed by making GHC.Rename.Names.extendGlobalRdrEnvRn fail fast if it finds duplicate bindings. See Note [Fail fast on duplicate definitions] in that module for more details. This patch was originated and worked on by Alex D (@nineonine)
* Add a missing restoreLclEnvSimon Peyton Jones2022-02-041-2/+2
| | | | | | | | | | | | | | The commit commit 18df4013f6eaee0e1de8ebd533f7e96c4ee0ff04 Date: Sat Jan 22 01:12:30 2022 +0000 Define and use restoreLclEnv omitted to change one setLclEnv to restoreLclEnv, namely the one in GHC.Tc.Errors.warnRedundantConstraints. This new commit fixes the omission.
* compiler: Introduce and use RoughMap for instance environmentsBen Gamari2022-02-047-34/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here we introduce a new data structure, RoughMap, inspired by the previous `RoughTc` matching mechanism for checking instance matches. This allows [Fam]InstEnv to be implemented as a trie indexed by these RoughTc signatures, reducing the complexity of instance lookup and FamInstEnv merging (done during the family instance conflict test) from O(n) to O(log n). The critical performance improvement currently realised by this patch is in instance matching. In particular the RoughMap mechanism allows us to discount many potential instances which will never match for constraints involving type variables (see Note [Matching a RoughMap]). In realistic code bases matchInstEnv was accounting for 50% of typechecker time due to redundant work checking instances when simplifying instance contexts when deriving instances. With this patch the cost is significantly reduced. The larger constants in InstEnv creation do mean that a few small tests regress in allocations slightly. However, the runtime of T19703 is reduced by a factor of 4. Moreover, the compilation time of the Cabal library is slightly improved. A couple of test cases are included which demonstrate significant improvements in compile time with this patch. This unfortunately does not fix the testcase provided in #19703 but does fix #20933 ------------------------- Metric Decrease: T12425 Metric Increase: T13719 T9872a T9872d hard_hole_fits ------------------------- Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
* Refactor the escaping kind check for data constructorsSimon Peyton Jones2022-02-022-58/+64
| | | | | | | | | | | | | | As #20929 pointed out, we were in-elegantly checking for escaping kinds in `checkValidType`, even though that check was guaranteed to succeed for type signatures -- it's part of kind-checking a type. But for /data constructors/ we kind-check the pieces separately, so we still need the check. This MR is a pure refactor, moving the test from `checkValidType` to `checkValidDataCon`. No new tests; external behaviour doesn't change.
* Fix a few Note inconsistenciesBen Gamari2022-02-017-9/+10
|
* Consistently upper-case "Note ["Ben Gamari2022-02-018-10/+10
| | | | | | This was achieved with git ls-tree --name-only HEAD -r | xargs sed -i -e 's/note \[/Note \[/g'
* Make typechecker trace less strictSimon Peyton Jones2022-01-311-2/+4
| | | | Fixes #21011
* Rework the handling of SkolemInfoMatthew Pickering2022-01-2932-1267/+1771
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main purpose of this patch is to attach a SkolemInfo directly to each SkolemTv. This fixes the large number of bugs which have accumulated over the years where we failed to report errors due to having "no skolem info" for particular type variables. Now the origin of each type varible is stored on the type variable we can always report accurately where it cames from. Fixes #20969 #20732 #20680 #19482 #20232 #19752 #10946 #19760 #20063 #13499 #14040 The main changes of this patch are: * SkolemTv now contains a SkolemInfo field which tells us how the SkolemTv was created. Used when reporting errors. * Enforce invariants relating the SkolemInfoAnon and level of an implication (ic_info, ic_tclvl) to the SkolemInfo and level of the type variables in ic_skols. * All ic_skols are TcTyVars -- Check is currently disabled * All ic_skols are SkolemTv * The tv_lvl of the ic_skols agrees with the ic_tclvl * The ic_info agrees with the SkolInfo of the implication. These invariants are checked by a debug compiler by checkImplicationInvariants. * Completely refactor kcCheckDeclHeader_sig which kept doing my head in. Plus, it wasn't right because it wasn't skolemising the binders as it decomposed the kind signature. The new story is described in Note [kcCheckDeclHeader_sig]. The code is considerably shorter than before (roughly 240 lines turns into 150 lines). It still has the same awkward complexity around computing arity as before, but that is a language design issue. See Note [Arity inference in kcCheckDeclHeader_sig] * I added new type synonyms MonoTcTyCon and PolyTcTyCon, and used them to be clear which TcTyCons have "finished" kinds etc, and which are monomorphic. See Note [TcTyCon, MonoTcTyCon, and PolyTcTyCon] * I renamed etaExpandAlgTyCon to splitTyConKind, becuase that's a better name, and it is very useful in kcCheckDeclHeader_sig, where eta-expansion isn't an issue. * Kill off the nasty `ClassScopedTvEnv` entirely. Co-authored-by: Simon Peyton Jones <simon.peytonjones@gmail.com>
* Set the TcLclEnv when solving a ForAll constraintSimon Peyton Jones2022-01-272-1/+11
| | | | | | | Fix a simple omission in GHC.Tc.Solver.Canonical.solveForAll, where we ended up with the wrong TcLclEnv captured in an implication. Result: unhelpful error message (#21006)
* Fix getHasGivenEqsSimon Peyton Jones2022-01-271-4/+7
| | | | | | | | | The second component is supposed to be "insoluble equalities arising from givens". But we were getting wanteds too; and that led to an outright duplication of constraints. It's not harmful, but it's not right either. I came across this when debugging something else. Easily fixed.
* Define and use restoreLclEnvSimon Peyton Jones2022-01-275-100/+130
| | | | | | | | | This fixes #20981. See Note [restoreLclEnv vs setLclEnv] in GHC.Tc.Utils.Monad. I also use updLclEnv rather than get/set when I can, because it's then much clearer that it's an update rather than an entirely new TcLclEnv coming from who-knows-where.
* Expand type synonyms in markNominalRyan Scott2022-01-271-0/+2
| | | | | | | | | | | | | | | | | | `markNominal` is repsonsible for setting the roles of type variables that appear underneath an `AppTy` to be nominal. However, `markNominal` previously did not expand type synonyms, so in a data type like this: ```hs data M f a = MkM (f (T a)) type T a = Int ``` The `a` in `M f a` would be marked nominal, even though `T a` would simply expand to `Int`. The fix is simple: call `coreView` as appropriate in `markNominal`. This is much like the fix for #14101, but in a different spot. Fixes #20999.
* Improve partial signaturesSimon Peyton Jones2022-01-272-18/+83
| | | | | | | | | | | As #20921 showed, with partial signatures, it is helpful to use the same algorithm (namely findInferredDiff) for * picking the constraints to retain for the /group/ in Solver.decideQuantification * picking the contraints to retain for the /individual function/ in Bind.chooseInferredQuantifiers This is still regrettably declicate, but it's a step forward.
* Make RULE matching insensitive to eta-expansionSimon Peyton Jones2022-01-261-3/+4
| | | | | | | | | | This patch fixes #19790 by making the rule matcher do on-the-fly eta reduction. See Note [Eta reduction the target] in GHC.Core.Rules I found I also had to careful about casts when matching; see Note [Casts in the target] and Note [Casts in the template] Lots more comments and Notes in the rule matcher
* Fix haddock markup in GHC.Tc.Errors.Typessheaf2022-01-261-13/+12
|
* Remove redundant SOURCE import in FitTypessheaf2022-01-261-1/+1
| | | | Fixes #20995
* Levity-polymorphic arrays and mutable variablessheaf2022-01-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the following types levity-polymorphic in their last argument: - Array# a, SmallArray# a, Weak# b, StablePtr# a, StableName# a - MutableArray# s a, SmallMutableArray# s a, MutVar# s a, TVar# s a, MVar# s a, IOPort# s a The corresponding primops are also made levity-polymorphic, e.g. `newArray#`, `readArray#`, `writeMutVar#`, `writeIOPort#`, etc. Additionally, exception handling functions such as `catch#`, `raise#`, `maskAsyncExceptions#`,... are made levity/representation-polymorphic. Now that Array# and MutableArray# also work with unlifted types, we can simply re-define ArrayArray# and MutableArrayArray# in terms of them. This means that ArrayArray# and MutableArrayArray# are no longer primitive types, but simply unlifted newtypes around Array# and MutableArrayArray#. This completes the implementation of the Pointer Rep proposal https://github.com/ghc-proposals/ghc-proposals/pull/203 Fixes #20911 ------------------------- Metric Increase: T12545 ------------------------- ------------------------- Metric Decrease: T12545 -------------------------
* DeriveGeneric: look up datacon fixities using getDataConFixityFunRyan Scott2022-01-252-19/+21
| | | | | | | | | | | | Previously, `DeriveGeneric` would look up the fixity of a data constructor using `getFixityEnv`, but this is subtly incorrect for data constructors defined in external modules. This sort of situation can happen with `StandaloneDeriving`, as noticed in #20994. In fact, the same bug has occurred in the past in #9830, and while that bug was fixed for `deriving Read` and `deriving Show`, the fix was never extended to `DeriveGeneric` due to an oversight. This patch corrects that oversight. Fixes #20994.
* Correct type of static forms in hsExprTypeMatthew Pickering2022-01-182-3/+5
| | | | | | | | | | | | | | | | The simplest way to do this seemed to be to persist the whole type in the extension field from the typechecker so that the few relevant places * Desugaring can work out the return type by splitting this type rather than calling `dsExpr` (slightly more efficient). * hsExprType can just return the correct type. * Zonking has to now zonk the type as well The other option we considered was wiring in StaticPtr but that is actually quite tricky because StaticPtr refers to StaticPtrInfo which has field selectors (which we can't easily wire in). Fixes #20150
* Use diagnostic infrastructure in GHC.Tc.Errorssheaf2022-01-1717-1699/+2654
|
* Untangled GHC.Types.Id.Make from the driverSylvain Henry2022-01-121-0/+1
|
* Abstract BangOptsSylvain Henry2022-01-122-16/+18
| | | | | | | | Avoid requiring to pass DynFlags to mkDataConRep/buildDataCon. When we load an interface file, these functions don't use the flags. This is preliminary work to decouple the loader from the type-checker for #14335.
* warnPprTrace: pass separately the reasonKrzysztof Gogolewski2022-01-113-3/+3
| | | | This makes it more similar to pprTrace, pprPanic etc.
* TcPlugins: `newWanted` uses the provided `CtLoc`sheaf2022-01-112-10/+19
| | | | | | | | | | | | | | | | | | The `GHC.Tc.Plugin.newWanted` function takes a `CtLoc` as an argument, but it used to discard the location information, keeping only the `CtOrigin`. It would then retrieve the source location from the `TcM` environment using `getCtLocM`. This patch changes this so that `GHC.Tc.Plugin.newWanted` passes on the full `CtLoc`. This means that authors of type-checking plugins no longer need to manually set the `CtLoc` environment in the `TcM` monad if they want to create a new Wanted constraint with the given `CtLoc` (in particular, for setting the `SrcSpan` of an emitted constraint). This makes the `newWanted` function consistent with `newGiven`, which always used the full `CtLoc` instead of using the environment. Fixes #20895
* Fix parsing & printing of unboxed sumssheaf2022-01-113-14/+31
| | | | | | | | | | | | | | | | | The pretty-printing of partially applied unboxed sums was incorrect, as we incorrectly dropped the first half of the arguments, even for a partial application such as (# | #) @IntRep @DoubleRep Int# which lead to the nonsensical (# DoubleRep | Int# #). This patch also allows users to write unboxed sum type constructors such as (# | #) :: TYPE r1 -> TYPE r2 -> TYPE (SumRep '[r1,r2]). Fixes #20858 and #20859.
* Kind TyCons: require KindSignatures, not DataKindssheaf2022-01-113-26/+17
| | | | | | | | | | | | | | | | | | Uses of a TyCon in a kind signature required users to enable DataKinds, which didn't make much sense, e.g. in type U = Type type MyMaybe (a :: U) = MyNothing | MyJust a Now the DataKinds error is restricted to data constructors; the use of kind-level type constructors is instead gated behind -XKindSignatures. This patch also adds a convenience pattern synonym for patching on both a TyCon or a TcTyCon stored in a TcTyThing, used in tcTyVar and tc_infer_id. fixes #20873
* Remove dangling references to Note [Type-checking overloaded labels]Joachim Breitner2022-01-071-6/+4
| | | | that note was removed in 4196969c53c55191e644d9eb258c14c2bc8467da
* Use primOpIds cache more often (#20857)Sylvain Henry2022-01-061-1/+1
| | | | | | | | Use primOpId instead of mkPrimOpId in a few places to benefit from Id caching. I had to mess a little bit with the module hierarchy to fix cycles and to avoid adding too many new dependencies to count-deps tests.
* Check quoted TH names are in the correct namespacesheaf2022-01-043-13/+56
| | | | | | | | | | | | When quoting (using a TH single or double quote) a built-in name such as the list constructor (:), we didn't always check that the resulting 'Name' was in the correct namespace. This patch adds a check in GHC.Rename.Splice to ensure we get a Name that is in the term-level/type-level namespace, when using a single/double tick, respectively. Fixes #20884.
* Skip computing superclass origins for equalitiesRichard Eisenberg2021-12-281-4/+13
| | | | This yields a small, but measurable, performance improvement.
* Multiple Home UnitsMatthew Pickering2021-12-289-72/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix typosKrzysztof Gogolewski2021-12-257-12/+12
|
* Give plugins a better interface (#17957)Sylvain Henry2021-12-212-6/+6
| | | | | | | | | | | | Plugins were directly fetched from HscEnv (hsc_static_plugins and hsc_plugins). The tight coupling of plugins and of HscEnv is undesirable and it's better to store them in a new Plugins datatype and to use it in the plugins' API (e.g. withPlugins, mapPlugins...). In the process, the interactive context (used by GHCi) got proper support for different static plugins than those used for loaded modules. Bump haddock submodule
* Change isUnliftedTyCon to marshalablePrimTyCon (#20401)Krzysztof Gogolewski2021-12-172-22/+18
| | | | | | | | | | | | | | | | | | | | | | | | isUnliftedTyCon was used in three places: Ticky, Template Haskell and FFI checks. It was straightforward to remove it from Ticky and Template Haskell. It is now used in FFI only and renamed to marshalablePrimTyCon. Previously, it was fetching information from a field in PrimTyCon called is_unlifted. Instead, I've changed the code to compute liftedness based on the kind. isFFITy and legalFFITyCon are removed. They were only referred from an old comment that I removed. There were three functions to define a PrimTyCon, but the only difference was that they were setting is_unlifted to True or False. Everything is now done in mkPrimTyCon. I also added missing integer types in Ticky.hs, I think it was an oversight. Fixes #20401
* Ghci environment: Do not remove shadowed idsJoachim Breitner2021-12-141-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add PromotedInfixT/PromotedUInfixT to THJakob Brünker2021-12-111-27/+29
| | | | | | | | | | | | Previously, it was not possible to refer to a data constructor using InfixT with a dynamically bound name (i.e. a name with NameFlavour `NameS` or `NameQ`) if a type constructor of the same name exists. This commit adds promoted counterparts to InfixT and UInfixT, analogously to how PromotedT is the promoted counterpart to ConT. Closes #20773
* package imports: Take into account package visibility when renamingMatthew Pickering2021-12-091-2/+2
| | | | | | | | | | | | In 806e49ae the package imports refactoring code was modified to rename package imports. There was a small oversight which meant the code didn't account for module visibility. This patch fixes that oversight. In general the "lookupPackageName" function is unsafe to use as it doesn't account for package visiblity/thinning/renaming etc, there is just one use in the compiler which would be good to audit. Fixes #20779
* Perf: remove an indirection when fetching the unique maskSylvain Henry2021-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Slight decrease but still noticeable on CI: Baseline Test Metric value New value Change ----------------------------------------------------------------------------- ManyAlternatives(normal) ghc/alloc 747607676.0 747458936.0 -0.0% ManyConstructors(normal) ghc/alloc 4003722296.0 4003530032.0 -0.0% MultiLayerModules(normal) ghc/alloc 3064539560.0 3063984552.0 -0.0% MultiLayerModulesRecomp(normal) ghc/alloc 894700016.0 894700624.0 +0.0% PmSeriesG(normal) ghc/alloc 48410952.0 48262496.0 -0.3% PmSeriesS(normal) ghc/alloc 61561848.0 61415768.0 -0.2% PmSeriesT(normal) ghc/alloc 90975784.0 90829360.0 -0.2% PmSeriesV(normal) ghc/alloc 60405424.0 60259008.0 -0.2% T10421(normal) ghc/alloc 113275928.0 113137168.0 -0.1% T10421a(normal) ghc/alloc 79195676.0 79050112.0 -0.2% T10547(normal) ghc/alloc 28720176.0 28710008.0 -0.0% T10858(normal) ghc/alloc 180992412.0 180857400.0 -0.1% T11195(normal) ghc/alloc 283452220.0 283293832.0 -0.1% T11276(normal) ghc/alloc 137882128.0 137745840.0 -0.1% T11303b(normal) ghc/alloc 44453956.0 44309184.0 -0.3% T11374(normal) ghc/alloc 248118668.0 247979880.0 -0.1% T11545(normal) ghc/alloc 971994728.0 971852696.0 -0.0% T11822(normal) ghc/alloc 131544864.0 131399024.0 -0.1% T12150(optasm) ghc/alloc 79336468.0 79191888.0 -0.2% T12227(normal) ghc/alloc 495064180.0 494943040.0 -0.0% T12234(optasm) ghc/alloc 57198468.0 57053568.0 -0.3% T12425(optasm) ghc/alloc 90928696.0 90793440.0 -0.1% T12545(normal) ghc/alloc 1695417772.0 1695275744.0 -0.0% T12707(normal) ghc/alloc 956258984.0 956138864.0 -0.0% T13035(normal) ghc/alloc 102279484.0 102132616.0 -0.1% T13056(optasm) ghc/alloc 367196556.0 367066408.0 -0.0% T13253(normal) ghc/alloc 334365844.0 334255264.0 -0.0% T13253-spj(normal) ghc/alloc 125474884.0 125328672.0 -0.1% T13379(normal) ghc/alloc 359185604.0 359036960.0 -0.0% T13701(normal) ghc/alloc 2403026480.0 2402677464.0 -0.0% T13719(normal) ghc/alloc 4192234752.0 4192039448.0 -0.0% T14052(ghci) ghc/alloc 2745868552.0 2747706176.0 +0.1% T14052Type(ghci) ghc/alloc 7335937964.0 7336283280.0 +0.0% T14683(normal) ghc/alloc 2992557736.0 2992436872.0 -0.0% T14697(normal) ghc/alloc 363391248.0 363222920.0 -0.0% T15164(normal) ghc/alloc 1292578008.0 1292434240.0 -0.0% T15304(normal) ghc/alloc 1279603472.0 1279465944.0 -0.0% T15630(normal) ghc/alloc 161707776.0 161602632.0 -0.1% T16190(normal) ghc/alloc 276904644.0 276555264.0 -0.1% T16577(normal) ghc/alloc 7573033016.0 7572982752.0 -0.0% T16875(normal) ghc/alloc 34937980.0 34796592.0 -0.4% T17096(normal) ghc/alloc 287436348.0 287299368.0 -0.0% T17516(normal) ghc/alloc 1714727484.0 1714617664.0 -0.0% T17836(normal) ghc/alloc 1091095748.0 1090958168.0 -0.0% T17836b(normal) ghc/alloc 52467912.0 52321296.0 -0.3% T17977(normal) ghc/alloc 44971660.0 44826480.0 -0.3% T17977b(normal) ghc/alloc 40941128.0 40793160.0 -0.4% T18140(normal) ghc/alloc 82363124.0 82213056.0 -0.2% T18223(normal) ghc/alloc 1168448128.0 1168333624.0 -0.0% T18282(normal) ghc/alloc 131577844.0 131440400.0 -0.1% T18304(normal) ghc/alloc 86988664.0 86844432.0 -0.2% T18478(normal) ghc/alloc 742992400.0 742871136.0 -0.0% T18698a(normal) ghc/alloc 337654412.0 337526792.0 -0.0% T18698b(normal) ghc/alloc 398840772.0 398716472.0 -0.0% T18923(normal) ghc/alloc 68964992.0 68818768.0 -0.2% T1969(normal) ghc/alloc 764285884.0 764156168.0 -0.0% T19695(normal) ghc/alloc 1395577984.0 1395552552.0 -0.0% T20049(normal) ghc/alloc 89159032.0 89012952.0 -0.2% T3064(normal) ghc/alloc 191194856.0 191051816.0 -0.1% T3294(normal) ghc/alloc 1604762016.0 1604656488.0 -0.0% T4801(normal) ghc/alloc 296829368.0 296687824.0 -0.0% T5030(normal) ghc/alloc 364720540.0 364580152.0 -0.0% T5321FD(normal) ghc/alloc 271090004.0 270950824.0 -0.1% T5321Fun(normal) ghc/alloc 301244320.0 301102960.0 -0.0% T5631(normal) ghc/alloc 576154548.0 576022904.0 -0.0% T5642(normal) ghc/alloc 471105876.0 470967552.0 -0.0% T5837(normal) ghc/alloc 36328620.0 36186720.0 -0.4% T6048(optasm) ghc/alloc 103125988.0 102981024.0 -0.1% T783(normal) ghc/alloc 386945556.0 386795984.0 -0.0% T9020(optasm) ghc/alloc 247835012.0 247696704.0 -0.1% T9198(normal) ghc/alloc 47556208.0 47413784.0 -0.3% T9233(normal) ghc/alloc 682210596.0 682069960.0 -0.0% T9630(normal) ghc/alloc 1429689648.0 1429581168.0 -0.0% T9675(optasm) ghc/alloc 431092812.0 430943192.0 -0.0% T9872a(normal) ghc/alloc 1705052592.0 1705042064.0 -0.0% T9872b(normal) ghc/alloc 2180406760.0 2180395784.0 -0.0% T9872c(normal) ghc/alloc 1760508464.0 1760497936.0 -0.0% T9872d(normal) ghc/alloc 501517968.0 501309464.0 -0.0% T9961(normal) ghc/alloc 354037204.0 353891576.0 -0.0% TcPlugin_RewritePerf(normal) ghc/alloc 2381708520.0 2381550824.0 -0.0% WWRec(normal) ghc/alloc 589553520.0 589407216.0 -0.0% hard_hole_fits(normal) ghc/alloc 492122188.0 492470648.0 +0.1% hie002(normal) ghc/alloc 9336434800.0 9336443496.0 +0.0% parsing001(normal) ghc/alloc 537680944.0 537659824.0 -0.0% geo. mean -0.1%
* TTG: replace Void/NoExtCon with DataConCantHappenKrzysztof Gogolewski2021-11-291-1/+1
| | | | | | | | There were two ways to indicate that a TTG constructor is unused in a phase: `NoExtCon` and `Void`. This unifies the code, and uses the name 'DataConCantHappen', following the discussion at MR 7041. Updates haddock submodule
* Allow boring class declarations in hs-boot filessheaf2021-11-251-1/+9
| | | | | | | | | | | | | | | | | | | | | | | There are two different ways of declaring a class in an hs-boot file: - a full declaration, where everything is written as it is in the .hs file, - an abstract declaration, where class methods and superclasses are left out. However, a declaration with no methods and a trivial superclass, such as: class () => C a was erroneously considered to be an abstract declaration, because the superclass is trivial. This is remedied by a one line fix in GHC.Tc.TyCl.tcClassDecl1. This patch also further clarifies the documentation around class declarations in hs-boot files. Fixes #20661, #20588.
* Don't use implicit lifting when deriving LiftMatthew Pickering2021-11-251-8/+20
| | | | | | | | | | | | | | | | It isn't much more complicated to be more precise when deriving Lift so we now generate ``` data Foo = Foo Int Bool instance Lift Foo where lift (Foo a b) = [| Foo $(lift a) $(lift b) |] liftTyped (Foo a b) = [|| Foo $$(lift a) $$(lift b) |] ``` This fixes #20688 which complained about using implicit lifting in the derived code.
* Misc cleanupKrzysztof Gogolewski2021-11-254-11/+9
| | | | | | | | | | | | | | | | | | | | | * Remove `getTag_RDR` (unused), `tidyKind` and `tidyOpenKind` (already available as `tidyType` and `tidyOpenType`) * Remove Note [Explicit Case Statement for Specificity]. Since 0a709dd9876e40 we require GHC 8.10 for bootstrapping. * Change the warning to `cmpAltCon` to a panic. This shouldn't happen. If it ever does, the code was wrong anyway: it shouldn't always return `LT`, but rather `LT` in one case and `GT` in the other case. * Rename `verifyLinearConstructors` to `verifyLinearFields` * Fix `Note [Local record selectors]` which was not referenced * Remove vestiges of `type +v` * Minor fixes to StaticPointers documentation, part of #15603
* Enable UnboxedTuples in `genInst`, Fixes #20524CarrieMY2021-11-251-0/+3
|
View Lorry Controller Status