summaryrefslogtreecommitdiff
path: root/compiler/GHC/Tc
Commit message (Collapse)AuthorAgeFilesLines
* HsToken for let/in (#19623)Vladislav Zavialov2021-11-024-9/+9
| | | | One more step towards the new design of EPA.
* Show family TyCons in mk_dict_error in the case of a single matchZiyang Liu2021-10-291-2/+26
|
* Change CaseAlt and LambdaExpr to FunRhs in deriving Foldable and Traversable ↵Artyom Kuznetsov2021-10-261-3/+8
| | | | (#20496)
* Don't default type variables in type familiessheaf2021-10-266-32/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the following defaulting of type variables in type and data families: - type variables of kind RuntimeRep defaulting to LiftedRep - type variables of kind Levity defaulting to Lifted - type variables of kind Multiplicity defaulting to Many It does this by passing "defaulting options" to the `defaultTyVars` function; when calling from `tcTyFamInstEqnGuts` or `tcDataFamInstHeader` we pass options that avoid defaulting. This avoids wildcards being defaulted, which caused type families to unexpectedly fail to reduce. Note that kind defaulting, applicable only with -XNoPolyKinds, is not changed by this patch. Fixes #17536 ------------------------- Metric Increase: T12227 -------------------------
* EPA: Use LocatedA for ModuleNameAlan Zimmerman2021-10-241-2/+2
| | | | | This allows us to use an Anchor with a DeltaPos in it when exact printing.
* Refactor package importsSylvain Henry2021-10-223-50/+31
| | | | | | | | | Use an (Raw)PkgQual datatype instead of `Maybe FastString` to represent package imports. Factorize the code that renames RawPkgQual into PkgQual in function `rnPkgQual`. Renaming consists in checking if the FastString is the magic "this" keyword, the home-unit unit-id or something else. Bump haddock submodule
* Remove IndefiniteSylvain Henry2021-10-221-2/+2
| | | | We no longer need it after previous IndefUnitId refactoring.
* Use tcEqType in GHC.Core.Unify.uVarsheaf2021-10-221-0/+4
| | | | | | | | | | | | | | | | | Because uVar used eqType instead of tcEqType, it was possible to accumulate a substitution that unified Type and Constraint. For example, a call to `tc_unify_tys` with arguments tys1 = [ k, k ] tys2 = [ Type, Constraint ] would first add `k = Type` to the substitution. That's fine, but then the second call to `uVar` would claim that the substitution also unifies `k` with `Constraint`. This could then be used to cause trouble, as per #20521. Fixes #20521
* Make fields of GlobalRdrElt strictMatthew Pickering2021-10-201-1/+6
| | | | | | | | In order to do this I thought it was prudent to change the list type to a bag type to avoid doing a lot of premature work in plusGRE because of ++. Fixes #19201
* Care about specificity in pattern type argsRichard Eisenberg2021-10-191-4/+6
| | | | Close #20443.
* InteractiveContext: Smarter caching when rebuilding the ic_rn_gbl_envJoachim Breitner2021-10-191-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The GlobalRdrEnv of a GHCI session changes in odd ways: New bindings are not just added "to the end", but also "in the middle", namely when changing the set of imports: These are treated as if they happened before all bindings from the prompt, even those that happened earlier. Previously, this meant that the `ic_rn_gbl_env` is recalculated from the `ic_tythings`. But this wasteful if `ic_tythings` has many entries that define the same unqualified name. By separately keeping track of a `GlobalRdrEnv` of all the locally defined things we can speed this operation up significantly. This change improves `T14052Type` by 60% (It used to be 70%, but it looks that !6723 already reaped some of the rewards). But more importantly, it hopefully unblocks #20455, becaues with this smarter caching, the change needed to fix that issue will no longer make `T14052` explode. I hope. It does regress `T14052` by 30%; caching isn’t free. Oh well. Metric Decrease: T14052Type Metric Increase: T14052
* Introduce Concrete# for representation polymorphism checkssheaf2021-10-1732-411/+1816
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | PHASE 1: we never rewrite Concrete# evidence. This patch migrates all the representation polymorphism checks to the typechecker, using a new constraint form Concrete# :: forall k. k -> TupleRep '[] Whenever a type `ty` must be representation-polymorphic (e.g. it is the type of an argument to a function), we emit a new `Concrete# ty` Wanted constraint. If this constraint goes unsolved, we report a representation-polymorphism error to the user. The 'FRROrigin' datatype keeps track of the context of the representation-polymorphism check, for more informative error messages. This paves the way for further improvements, such as allowing type families in RuntimeReps and improving the soundness of typed Template Haskell. This is left as future work (PHASE 2). fixes #17907 #20277 #20330 #20423 #20426 updates haddock submodule ------------------------- Metric Decrease: T5642 -------------------------
* Be more careful about retaining KnotVarsMatthew Pickering2021-10-122-2/+2
| | | | | | | | | | | | | | | | | | | | | It is quite easy to end up accidently retaining a KnotVars, which contains pointers to a stale TypeEnv because they are placed in the HscEnv. One place in particular we have to be careful is when loading a module into the EPS in `--make` mode, we have to remove the reference to KnotVars as otherwise the interface loading thunks will forever retain reference to the KnotVars which are live at the time the interface was loaded. These changes do not go as far as to enforce the invariant described in Note [KnotVar invariants] * At the end of upsweep, there should be no live KnotVars but at least improve the situation. This is left for future work (#20491)
* Reject GADT pattern matches in arrow notationsheaf2021-10-094-35/+76
| | | | | | | | | | | | Tickets #20469 and #20470 showed that the current implementation of arrows is not at all up to the task of supporting GADTs: GHC produces ill-scoped Core programs because it doesn't propagate the evidence introduced by a GADT pattern match. For the time being, we reject GADT pattern matches in arrow notation. Hopefully we are able to add proper support for GADTs in arrows in the future.
* Add defaulting plugins.Andrei Barbu2021-10-085-26/+108
| | | | | | | | | | | | | | | Like the built-in type defaulting rules these plugins can propose candidates to resolve ambiguous type variables. Machine learning and other large APIs like those for game engines introduce new numeric types and other complex typed APIs. The built-in defaulting mechanism isn't powerful enough to resolve ambiguous types in these cases forcing users to specify minutia that they might not even know how to do. There is an example defaulting plugin linked in the documentation. Applications include defaulting the device a computation executes on, if a gradient should be computed for a tensor, or the size of a tensor. See https://github.com/ghc-proposals/ghc-proposals/pull/396 for details.
* Improve overlap error for polykinded constraintssheaf2021-10-061-19/+6
| | | | | | | | | | | | | | 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
* Eradicate TcRnUnknownMessage from GHC.Tc.DerivAlfredo Di Napoli2021-10-055-318/+870
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This (big) commit finishes porting the GHC.Tc.Deriv module to support the new diagnostic infrastructure (#18516) by getting rid of the legacy calls to `TcRnUnknownMessage`. This work ended up being quite pervasive and touched not only the Tc.Deriv module but also the Tc.Deriv.Utils and Tc.Deriv.Generics module, which needed to be adapted to use the new infrastructure. This also required generalising `Validity`. More specifically, this is a breakdown of the work done: * Add and use the TcRnUselessTypeable data constructor * Add and use TcRnDerivingDefaults data constructor * Add and use the TcRnNonUnaryTypeclassConstraint data constructor * Add and use TcRnPartialTypeSignatures * Add T13324_compile2 test to test another part of the TcRnPartialTypeSignatures diagnostic * Add and use TcRnCannotDeriveInstance data constructor, which introduces a new data constructor to TcRnMessage called TcRnCannotDeriveInstance, which is further sub-divided to carry a `DeriveInstanceErrReason` which explains the reason why we couldn't derive a typeclass instance. * Add DerivErrSafeHaskellGenericInst data constructor to DeriveInstanceErrReason * Add DerivErrDerivingViaWrongKind and DerivErrNoEtaReduce * Introduce the SuggestExtensionInOrderTo Hint, which adds (and use) a new constructor to the hint type `LanguageExtensionHint` called `SuggestExtensionInOrderTo`, which can be used to give a bit more "firm" recommendations when it's obvious what the required extension is, like in the case for the `DerivingStrategies`, which automatically follows from having enabled both `DeriveAnyClass` and `GeneralizedNewtypeDeriving`. * Wildcard-free pattern matching in mk_eqn_stock, which removes `_` in favour of pattern matching explicitly on `CanDeriveAnyClass` and `NonDerivableClass`, because that determine whether or not we can suggest to the user `DeriveAnyClass` or not.
* Make GHC.Utils.Error.Validity type polymorphicAlfredo Di Napoli2021-10-053-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes the `Validity` type polymorphic: ``` data Validity' a = IsValid -- ^ Everything is fine | NotValid a -- ^ A problem, and some indication of why -- | Monomorphic version of @Validity'@ specialised for 'SDoc's. type Validity = Validity' SDoc ``` The type has been (provisionally) renamed to Validity' to not break existing code, as the monomorphic `Validity` type is quite pervasive in a lot of signatures in GHC. Why having a polymorphic Validity? Because it carries the evidence of "what went wrong", but the old type carried an `SDoc`, which clashed with the new GHC diagnostic infrastructure (#18516). Having it polymorphic it means we can carry an arbitrary, richer diagnostic type, and this is very important for things like the `checkOriginativeSideConditions` function, which needs to report the actual diagnostic error back to `GHC.Tc.Deriv`. It also generalises Validity-related functions to be polymorphic in @a@.
* Reject type family equation with wrong name (#20260)Krzysztof Gogolewski2021-10-051-25/+24
| | | | | | We should reject "type family Foo where Bar = ()". This check was done in kcTyFamInstEqn but not in tcTyFamInstEqn. I factored out arity checking, which was duplicated.
* Speed up valid hole-fits by adding early abort and checks.Matthías Páll Gissurarson2021-10-053-61/+108
| | | | | | | | | | | | | | By adding an early abort flag in `TcSEnv`, we can fail fast in the presence of insoluble constraints. This helps us avoid a lot of work in valid hole-fits, and we geta massive speed-up by avoiding a lot of useless work solving constraints that never come into play. Additionally, we add a simple check for degenerate hole types, such as when the type of the hole is an immutable type variable (as is the case when the hole is completely unconstrained). Then the only valid fits are the locals, so we can ignore the global candidates. This fixes #16875
* Bump TcLevel of failing kind equality implicationsheaf2021-10-041-8/+28
| | | | | | | | Not bumping the TcLevel meant that we could end up trying to add evidence terms for the implication constraint created to wrap failing kind equalities (to avoid their deferral). fixes #20043
* Use eqType, not tcEqType, in metavar kind checkRichard Eisenberg2021-10-024-41/+10
| | | | | | | | | | | | Close #20356. See addendum to Note [coreView vs tcView] in GHC.Core.Type for the details. Also killed old Note about metaTyVarUpdateOK, which has been gone for some time. test case: typecheck/should_fail/T20356
* Convert Diagnostics GHC.Tc.Gen.* (Part 3)Aaron Allen2021-10-013-107/+266
| | | | | | Converts all diagnostics in the `GHC.Tc.Gen.Expr` module. (#20116)
* Trees That Grow refactor for HsTick and HsBinTickAndrea Condoluci2021-09-302-4/+0
| | | | | | Move HsTick and HsBinTick to XExpr, the extension tree of HsExpr. Part of #16830 .
* compiler: occEnvElts -> nonDetOccEnvEltsBen Gamari2021-09-291-2/+2
|
* compiler: Rename nameEnvElts -> nonDetNameEnvEltsBen Gamari2021-09-293-5/+5
|
* compiler: Rewrite all eltsUFM occurrences to nonDetEltsUFMBen Gamari2021-09-291-1/+1
| | | | And remove the former.
* TH stage restriction check for constructors, selectors, and class methodsAndrea Condoluci2021-09-297-28/+61
| | | | Closes ticket #17820.
* Compare FunTys as if they were TyConApps.Richard Eisenberg2021-09-294-38/+70
| | | | | | | | | | | See Note [Equality on FunTys] in TyCoRep. Close #17675. Close #17655, about documentation improvements included in this patch. Close #19677, about a further mistake around FunTy. test cases: typecheck/should_compile/T19677
* Remove NoGhcTc usage from HsMatchContextArtyom Kuznetsov2021-09-287-29/+54
| | | | | | NoGhcTc is removed from HsMatchContext. As a result of this, HsMatchContext GhcTc is now a valid type that has Id in it, instead of Name and tcMatchesFun now takes Id instead of Name.
* Convert Diagnostics in GHC.Tc.Gen.* (Part 2)Aaron Allen2021-09-224-114/+330
| | | | | | Converts diagnostics in: (#20116) - GHC.Tc.Gen.Default - GHC.Tc.Gen.Export
* deriving: Always use module prefix in dataTypeNameMatthew Pickering2021-09-181-1/+6
| | | | | | | | | | | This fixes a long standard bug where the module prefix was omitted from the data type name supplied by Data.Typeable instances. Instead of reusing the Outputable instance for TyCon, we now take matters into our own hands and explicitly print the module followed by the type constructor name. Fixes #20371
* Refactor module dependencies codeSylvain Henry2021-09-171-72/+2
| | | | | | * moved deps related code into GHC.Unit.Module.Deps * refactored Deps module to not export Dependencies constructor to help maintaining invariants
* EPA: correctly capture comments between 'where' and bindsAlan Zimmerman2021-09-171-1/+1
| | | | | | | | | | | | In the following foo = x where -- do stuff doStuff = do stuff The "-- do stuff" comment is captured in the HsValBinds. Closes #20297
* Emit warning if bang is applied to unlifted typesTito Sacchi2021-09-173-3/+29
| | | | | | | | | | | | | | | | GHC will trigger a warning similar to the following when a strictness flag is applied to an unlifted type (primitive or defined with the Unlifted* extensions) in the definition of a data constructor. Test.hs:7:13: warning: [-Wredundant-strictness-flags] • Strictness flag has no effect on unlifted type ‘Int#’ • In the definition of data constructor ‘TestCon’ In the data type declaration for ‘Test’ | 7 | data Test = TestCon !Int# | ^^^^^^^^^^^^^ Fixes #20187
* Improve pretty-printer defaulting logic (#19361)Krzysztof Gogolewski2021-09-171-0/+4
| | | | | | When determining whether to default a RuntimeRep or Multiplicity variable, use isMetaTyVar to distinguish between metavariables (which can be hidden) and skolems (which cannot).
* Canonicalize bignum literalsSylvain Henry2021-09-112-2/+9
| | | | | | | | | | | | | | | | | | Before this patch Integer and Natural literals were desugared into "real" Core in Core prep. Now we desugar them directly into their final ConApp form in HsToCore. We only keep the double representation for BigNat# (literals larger than a machine Word/Int) which are still desugared in Core prep. Using the final form directly allows case-of-known-constructor to fire for bignum literals, fixing #20245. Slight increase (+2.3) in T4801 which is a pathological case with Integer literals. Metric Increase: T4801 T11545
* Add and use new constructors to TcRnMessageAlfredo Di Napoli2021-09-076-117/+291
| | | | | | | | | | | | | This commit adds the following constructors to the TcRnMessage type and uses them to replace sdoc-based diagnostics in some parts of GHC (e.g. TcRnUnknownMessage). It includes: * Add TcRnMonomorphicBindings diagnostic * Convert TcRnUnknownMessage in Tc.Solver.Interact * Add and use the TcRnOrphanInstance constructor to TcRnMessage * Add TcRnFunDepConflict and TcRnDupInstanceDecls constructors to TcRnMessage * Add and use TcRnConflictingFamInstDecls constructor to TcRnMessage * Get rid of TcRnUnknownMessage from GHC.Tc.Instance.Family
* Convert diagnostics in GHC.Tc.Validity to proper TcRnMessage.hainq2021-09-015-227/+533
| | | | | | | | | | | | | | | | | | | | - 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.
* Convert IFace Rename Errors (#19927)Aaron Allen2021-08-272-0/+36
| | | | | | Converts uses of TcRnUnknownMessage in GHC.Iface.Rename. Closes #19927
* GHC.Tc.Gen Diagnostics Conversion (Part 1)Aaron Allen2021-08-278-78/+319
| | | | | | | | Converts uses of `TcRnUnknownMessage` in these modules: - compiler/GHC/Tc/Gen/Annotation.hs - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Gen/Arrow.hs - compiler/GHC/Tc/Gen/Bind.hs
* TcPlugins: solve and report contras simultaneouslysheaf2021-08-232-24/+55
| | | | | | | | | | | | This changes the TcPlugin datatype to allow type-checking plugins to report insoluble constraints while at the same time solve some other constraints. This allows better error messages, as the plugin can still simplify constraints, even when it wishes to report a contradiction. Pattern synonyms TcPluginContradiction and TcPluginOk are provided for backwards compatibility: existing type-checking plugins should continue to work without modification.
* Make Int64#/Word64# unconditionally availableJohn Ericson2021-08-191-3/+0
| | | | | | | | This prepares us to actually use them when the native size is 64 bits too. I more than saitisfied my curiosity finding they were gated since 47774449c9d66b768a70851fe82c5222c1f60689.
* Don't look for TypeError in type family argumentssheaf2021-08-181-9/+17
| | | | | | | | | | | | | | | | | | | Changes checkUserTypeError to no longer look for custom type errors inside type family arguments. This means that a program such as foo :: F xyz (TypeError (Text "blah")) -> bar does not throw a type error at definition site. This means that more programs can be accepted, as the custom type error might disappear upon reducing the above type family F. This applies only to user-written type signatures, which are checked within checkValidType. Custom type errors in type family arguments continue to be reported when they occur in unsolved Wanted constraints. Fixes #20241
* Driver rework pt3: the upsweepMatthew Pickering2021-08-183-22/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch specifies and simplifies the module cycle compilation in upsweep. How things work are described in the Note [Upsweep] Note [Upsweep] ~~~~~~~~~~~~~~ Upsweep takes a 'ModuleGraph' as input, computes a build plan and then executes the plan in order to compile the project. The first step is computing the build plan from a 'ModuleGraph'. The output of this step is a `[BuildPlan]`, which is a topologically sorted plan for how to build all the modules. ``` data BuildPlan = SingleModule ModuleGraphNode -- A simple, single module all alone but *might* have an hs-boot file which isn't part of a cycle | ResolvedCycle [ModuleGraphNode] -- A resolved cycle, linearised by hs-boot files | UnresolvedCycle [ModuleGraphNode] -- An actual cycle, which wasn't resolved by hs-boot files ``` The plan is computed in two steps: Step 1: Topologically sort the module graph without hs-boot files. This returns a [SCC ModuleGraphNode] which contains cycles. Step 2: For each cycle, topologically sort the modules in the cycle *with* the relevant hs-boot files. This should result in an acyclic build plan if the hs-boot files are sufficient to resolve the cycle. The `[BuildPlan]` is then interpreted by the `interpretBuildPlan` function. * `SingleModule nodes` are compiled normally by either the upsweep_inst or upsweep_mod functions. * `ResolvedCycles` need to compiled "together" so that the information which ends up in the interface files at the end is accurate (and doesn't contain temporary information from the hs-boot files.) - During the initial compilation, a `KnotVars` is created which stores an IORef TypeEnv for each module of the loop. These IORefs are gradually updated as the loop completes and provide the required laziness to typecheck the module loop. - At the end of typechecking, all the interface files are typechecked again in the retypecheck loop. This time, the knot-tying is done by the normal laziness based tying, so the environment is run without the KnotVars. * UnresolvedCycles are indicative of a proper cycle, unresolved by hs-boot files and are reported as an error to the user. The main trickiness of `interpretBuildPlan` is deciding which version of a dependency is visible from each module. For modules which are not in a cycle, there is just one version of a module, so that is always used. For modules in a cycle, there are two versions of 'HomeModInfo'. 1. Internal to loop: The version created whilst compiling the loop by upsweep_mod. 2. External to loop: The knot-tied version created by typecheckLoop. Whilst compiling a module inside the loop, we need to use the (1). For a module which is outside of the loop which depends on something from in the loop, the (2) version is used. As the plan is interpreted, which version of a HomeModInfo is visible is updated by updating a map held in a state monad. So after a loop has finished being compiled, the visible module is the one created by typecheckLoop and the internal version is not used again. This plan also ensures the most important invariant to do with module loops: > If you depend on anything within a module loop, before you can use the dependency, the whole loop has to finish compiling. The end result of `interpretBuildPlan` is a `[MakeAction]`, which are pairs of `IO a` actions and a `MVar (Maybe a)`, somewhere to put the result of running the action. This list is topologically sorted, so can be run in order to compute the whole graph. As well as this `interpretBuildPlan` also outputs an `IO [Maybe (Maybe HomeModInfo)]` which can be queried at the end to get the result of all modules at the end, with their proper visibility. For example, if any module in a loop fails then all modules in that loop will report as failed because the visible node at the end will be the result of retypechecking those modules together. Along the way we also fix a number of other bugs in the driver: * Unify upsweep and parUpsweep. * Fix #19937 (static points, ghci and -j) * Adds lots of module loop tests due to Divam. Also related to #20030 Co-authored-by: Divam Narula <dfordivam@gmail.com> ------------------------- Metric Decrease: T10370 -------------------------
* TypeError is OK on the RHS of a type synonymwip/T20181Simon Peyton Jones2021-08-151-3/+8
| | | | | | | | | | We should not complain about TypeError in type T = TypeError blah This fixes #20181 The error message for T13271 changes, because that test did indeed have a type synonym with TypeError on the RHS
* Detect TypeError when checking for insolubilitysheaf2021-08-154-16/+116
| | | | | | | | | | | | | | | We detect insoluble Givens by making getInertInsols take into account TypeError constraints, on top of insoluble equalities such as Int ~ Bool (which it already took into account). This allows pattern matches with insoluble contexts to be reported as redundant (tyOracle calls tcCheckGivens which calls getInertInsols). As a bonus, we get to remove a workaround in Data.Typeable.Internal: we can directly use a NotApplication type family, as opposed to needing to cook up an insoluble equality constraint. Fixes #11503 #14141 #16377 #20180
* Add rewriting to typechecking pluginssheaf2021-08-137-135/+287
| | | | | | | | | | | | | | | | | | | | | | | | | | | Type-checking plugins can now directly rewrite type-families. The TcPlugin record is given a new field, tcPluginRewrite. The plugin specifies how to rewrite certain type-families with a value of type `UniqFM TyCon TcPluginRewriter`, where: type TcPluginRewriter = RewriteEnv -- Rewriter environment -> [Ct] -- Givens -> [TcType] -- type family arguments -> TcPluginM TcPluginRewriteResult data TcPluginRewriteResult = TcPluginNoRewrite | TcPluginRewriteTo { tcPluginRewriteTo :: Reduction , tcRewriterNewWanteds :: [Ct] } When rewriting an exactly-saturated type-family application, GHC will first query type-checking plugins for possible rewritings before proceeding. Includes some changes to the TcPlugin API, e.g. removal of the EvBindsVar parameter to the TcPluginM monad.
* Refactoring module dependenciesSylvain Henry2021-08-132-6/+6
| | | | | | | | | | | | | | * Make mkDependencies pure * Use Sets instead of sorted lists Notable perf changes: MultiLayerModules(normal) ghc/alloc 4130851520.0 2981473072.0 -27.8% T13719(normal) ghc/alloc 4313296052.0 4151647512.0 -3.7% Metric Decrease: MultiLayerModules T13719
* Move `ol_witness` to `OverLitTc`Dr. ERDI Gergo2021-08-133-20/+18
| | | | | | | | We also add a new `ol_from_fun` field to renamed (but not yet typechecked) OverLits. This has the nice knock-on effect of making total some typechecker functions that used to be partial. Fixes #20151
View Lorry Controller Status