summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* GHCi Debugger - Improve RTTIRoland Senn2021-11-251-0/+3
| | | | | | | When processing the heap, use also `APClosures` to create additional type constraints. This adds more equations and therefore improves the unification process to infer the correct type of values at breakpoints. (Fix the `incr` part of #19559)
* drop instance Semigroup InstalledModuleEnvPepe Iborra2021-11-251-1/+4
| | | | Instead, introduce plusInstalledModuleEnv
* Drop instance Semigroup ModuleEnvPepe Iborra2021-11-251-1/+0
| | | | There is more than one possible Semigroup and it is not needed since plusModuleEnv can be used directly
* Monoid instance for InstalledModuleEnvPepe Iborra2021-11-251-0/+3
|
* 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-2512-58/+23
| | | | | | | | | | | | | | | | | | | | | * 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
|
* Compare types of recursive let-bindings in alpha-equivalenceChristiaan Baaij2021-11-256-146/+254
| | | | | | | | | | | | | This commit fixes #20641 by checking the types of recursive let-bindings when performing alpha-equality. The `Eq (DeBruijn CoreExpr)` instance now also compares `BreakPoint`s similarly to `GHC.Core.Utils.eqTickish`, taking bound variables into account. In addition, the `Eq (DeBruijn Type)` instance now correctly compares the kinds of the types when one of them contains a Cast: the instance is modeled after `nonDetCmpTypeX`.
* Ensure new Ct/evidence invariantChristiaan Baaij2021-11-254-31/+80
| | | | | | | | | | The `ctev_pred` field of a `CtEvidence` is a just a cache for the type of the evidence. More precisely: * For Givens, `ctev_pred` = `varType ctev_evar` * For Wanteds, `ctev_pred` = `evDestType ctev_dest` This new invariant is needed because evidence can become part of a type, via `Castty ty kco`.
* Revert "Convert lookupIdSubst panic back to a warning (#20200)"Matthew Pickering2021-11-251-6/+4
| | | | This reverts commit df1d808f26544cbb77d85773d672137c65fd3cc7.
* Correct retypechecking in --make modeMatthew Pickering2021-11-256-128/+290
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note [Hydrating Modules] ~~~~~~~~~~~~~~~~~~~~~~~~ What is hydrating a module? * There are two versions of a module, the ModIface is the on-disk version and the ModDetails is a fleshed-out in-memory version. * We can **hydrate** a ModIface in order to obtain a ModDetails. Hydration happens in three different places * When an interface file is initially loaded from disk, it has to be hydrated. * When a module is finished compiling, we hydrate the ModIface in order to generate the version of ModDetails which exists in memory (see Note) * When dealing with boot files and module loops (see Note [Rehydrating Modules]) Note [Rehydrating Modules] ~~~~~~~~~~~~~~~~~~~~~~~~~~~ If a module has a boot file then it is critical to rehydrate the modules on the path between the two. Suppose we have ("R" for "recursive"): ``` R.hs-boot: module R where data T g :: T -> T A.hs: module A( f, T, g ) where import {-# SOURCE #-} R data S = MkS T f :: T -> S = ...g... R.hs: module R where data T = T1 | T2 S g = ...f... ``` After compiling A.hs we'll have a TypeEnv in which the Id for `f` has a type type uses the AbstractTyCon T; and a TyCon for `S` that also mentions that same AbstractTyCon. (Abstract because it came from R.hs-boot; we know nothing about it.) When compiling R.hs, we build a TyCon for `T`. But that TyCon mentions `S`, and it currently has an AbstractTyCon for `T` inside it. But we want to build a fully cyclic structure, in which `S` refers to `T` and `T` refers to `S`. Solution: **rehydration**. *Before compiling `R.hs`*, rehydrate all the ModIfaces below it that depend on R.hs-boot. To rehydrate a ModIface, call `typecheckIface` to convert it to a ModDetails. It's just a de-serialisation step, no type inference, just lookups. Now `S` will be bound to a thunk that, when forced, will "see" the final binding for `T`; see [Tying the knot](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/tying-the-knot). But note that this must be done *before* compiling R.hs. When compiling R.hs, the knot-tying stuff above will ensure that `f`'s unfolding mentions the `LocalId` for `g`. But when we finish R, we carefully ensure that all those `LocalIds` are turned into completed `GlobalIds`, replete with unfoldings etc. Alas, that will not apply to the occurrences of `g` in `f`'s unfolding. And if we leave matters like that, they will stay that way, and *all* subsequent modules that import A will see a crippled unfolding for `f`. Solution: rehydrate both R and A's ModIface together, right after completing R.hs. We only need rehydrate modules that are * Below R.hs * Above R.hs-boot There might be many unrelated modules (in the home package) that don't need to be rehydrated. This dark corner is the subject of #14092. Suppose we add to our example ``` X.hs module X where import A data XT = MkX T fx = ...g... ``` If in `--make` we compile R.hs-boot, then A.hs, then X.hs, we'll get a `ModDetails` for `X` that has an AbstractTyCon for `T` in the the argument type of `MkX`. So: * Either we should delay compiling X until after R has beeen compiled. * Or we should rehydrate X after compiling R -- because it transitively depends on R.hs-boot. Ticket #20200 has exposed some issues to do with the knot-tying logic in GHC.Make, in `--make` mode. this particular issue starts [here](https://gitlab.haskell.org/ghc/ghc/-/issues/20200#note_385758). The wiki page [Tying the knot](https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/tying-the-knot) is helpful. Also closely related are * #14092 * #14103 Fixes tickets #20200 #20561
* Combine STG free variable traversals (#17978)nineonine2021-11-239-285/+255
| | | | | | | | | | | | | | | | | | | | | Previously we would traverse the STG AST twice looking for free variables. * Once in `annTopBindingsDeps` which considers top level and imported ids free. Its output is used to put bindings in dependency order. The pass happens in STG pipeline. * Once in `annTopBindingsFreeVars` which only considers non-top level ids free. Its output is used by the code generator to compute offsets into closures. This happens in Cmm (CodeGen) pipeline. Now these two traversal operations are merged into one - `FVs.depSortWithAnnotStgPgm`. The pass happens right at the end of STG pipeline. Some type signatures had to be updated due to slight shifts of StgPass boundaries (for example, top-level CodeGen handler now directly works with CodeGen flavoured Stg AST instead of Vanilla). Due to changed order of bindings, a few debugger type reconstruction bugs have resurfaced again (see tests break018, break021) - work item #18004 tracks this investigation. authors: simonpj, nineonine
* Add a warning for GADT match + NoMonoLocalBinds (#20485)Krzysztof Gogolewski2021-11-235-12/+39
| | | | | | | | | Previously, it was an error to pattern match on a GADT without GADTs or TypeFamilies. This is now allowed. Instead, we check the flag MonoLocalBinds; if it is not enabled, we issue a warning, controlled by -Wgadt-mono-local-binds. Also fixes #20485: pattern synonyms are now checked too.
* CmmSink: Be more aggressive in removing no-op assignments.Andreas Klebinger2021-11-231-3/+57
| | | | | | | | | | No-op assignments like R1 = R1 are not only wasteful. They can also inhibit other optimizations like inlining assignments that read from R1. We now check for assignments being a no-op before and after we simplify the RHS in Cmm sink which should eliminate most of these no-ops.
* Better wrapper activation calculationSimon Peyton Jones2021-11-222-34/+80
| | | | | | | | | | | | | As #20709 showed, GHC could prioritise a wrapper over a SPEC rule, which is potentially very bad. This patch fixes that problem. The fix is is described in Note [Wrapper activation], especially item 4, 4a, and Conclusion. For now, it has a temporary hack (replicating what was there before to make sure that wrappers inline no earlier than phase 2. But it should be temporary; see #19001.
* Include "not more specific" info in overlap msgsheaf2021-11-202-46/+152
| | | | | | | | | 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
* Use 'NonEmpty' for the fields in an 'HsProjection' (#20389)Zubin Duggal2021-11-2010-17/+57
| | | | | | | | | | | | T12545 is very inconsistently affected by this change for some reason. There is a decrease in allocations on most configurations, but an increase on validate-x86_64-linux-deb9-unreg-hadrian. Accepting it as it seems unrelated to this patch. Metric Decrease: T12545 Metric Increase: T12545
* More support for optional home-unitSylvain Henry2021-11-2015-133/+170
| | | | | | | | | This is a preliminary refactoring for #14335 (supporting plugins in cross-compilers). In many places the home-unit must be optional because there won't be one available in the plugin environment (we won't be compiling anything in this environment). Hence we replace "HomeUnit" with "Maybe HomeUnit" in a few places and we avoid the use of "hsc_home_unit" (which is partial) in some few others.
* Remove unused module import syntax from .bkp modeMatthew Pickering2021-11-203-27/+7
| | | | | | | | | | | | | | | .bkp mode had this unused feature where you could write module A and it would go looking for A.hs on the file system and use that rather than provide the definition inline. This isn't use anywhere in the testsuite and the code to find the module A looks dubious. Therefore to reduce .bkp complexity I propose to remove it. Fixes #20701
* Add one line of comments (c.f. !5706)Simon Peyton Jones2021-11-181-0/+1
| | | | | | | Ticket #19815 suggested changing coToMCo to use isReflexiveCo rather than isReflCo. But perf results weren't encouraging. This patch just adds a comment to point to the data, such as it is.
* Improve handling of import statements in GHCi (#20473)Morrow2021-11-171-4/+10
| | | | | | | | | | | | | | | | 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).
* Pmc: Don't case split on wildcard matches (#20642)Sebastian Graf2021-11-172-41/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 8.10, when formatting a pattern match warning, we'd case split on a wildcard match such as ```hs foo :: [a] -> [a] foo [] = [] foo xs = ys where (_, ys@(_:_)) = splitAt 0 xs -- Pattern match(es) are non-exhaustive -- In a pattern binding: -- Patterns not matched: -- ([], []) -- ((_:_), []) ``` But that's quite verbose and distracts from which part of the pattern was actually the inexhaustive one. We'd prefer a wildcard for the first pair component here, like it used to be in GHC 8.8. On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the different constructors we could've matched on: ```hs f :: Bool -> () f x = case x of {} -- Pattern match(es) are non-exhaustive -- In a pattern binding: -- Patterns not matched: -- False -- True ``` The solution is to communicate that we want a top-level case split to `generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what this patch arranges. Details in `Note [Case split inhabiting patterns]`. Fixes #20642.
* Increase type sharingBen Gamari2021-11-1723-265/+453
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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%.
* Make: Get rid of `BUILD_.*_INCLUDE_DIRS`John Ericson2021-11-161-10/+2
| | | | | | | | | | | | | | | First, we improve some of the rules around -I include dirs, and CPP opts. Then, we just specify the RTS's include dirs normally (locally per the package and in the package conf), and then everything should work normally. The primops.txt.pp rule needs no extra include dirs at all, as it no longer bakes in a target platfom. Reverts some of the extra stage arguments I added in 05419e55cab272ed39790695f448b311f22669f7, as they are no longer needed.
* Fix windres invocationSylvain Henry2021-11-151-6/+5
| | | | | I've already fixed this 7 months ago in the comments of #16780 but it never got merged. Now we need this for #20657 too.
* Delete dead code knobs for building GHC itselfJohn Ericson2021-11-152-83/+0
| | | | | As GHC has become target agnostic, we've left behind some now-useless logic in both build systems.
* Make: Get rid of GHC_INCLUDE_DIRSJohn Ericson2021-11-151-5/+4
| | | | | | These dirs should not be included in all stages. Instead make the per-stage `BUILD_*_INCLUDE_DIR` "plural" to insert `rts/include` in the right place.
* Instantiate field types properly in stock-derived instancesRyan Scott2021-11-157-244/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the `deriving` machinery was very loosey-goosey about how it used the types of data constructor fields when generating code. It would usually just consult `dataConOrigArgTys`, which returns the _uninstantiated_ field types of each data constructor. Usually, you can get away with this, but issues #20375 and #20387 revealed circumstances where this approach fails. Instead, when generated code for a stock-derived instance `C (T arg_1 ... arg_n)`, one must take care to instantiate the field types of each data constructor with `arg_1 ... arg_n`. The particulars of how this is accomplished is described in the new `Note [Instantiating field types in stock deriving]` in `GHC.Tc.Deriv.Generate`. Some highlights: * `DerivInstTys` now has a new `dit_dc_inst_arg_env :: DataConEnv [Type]` field that caches the instantiated field types of each data constructor. Whenever we need to consult the field types somewhere in `GHC.Tc.Deriv.*` we avoid using `dataConOrigArgTys` and instead look it up in `dit_dc_inst_arg_env`. * Because `DerivInstTys` now stores the instantiated field types of each constructor, some of the details of the `GHC.Tc.Deriv.Generics.mkBindsRep` function were able to be simplified. In particular, we no longer need to apply a substitution to instantiate the field types in a `Rep(1)` instance, as that is already done for us by `DerivInstTys`. We still need a substitution to implement the "wrinkle" section of `Note [Generating a correctly typed Rep instance]`, but the code is nevertheless much simpler than before. * The `tyConInstArgTys` function has been removed in favor of the new `GHC.Core.DataCon.dataConInstUnivs` function, which is really the proper tool for the job. `dataConInstUnivs` is much like `tyConInstArgTys` except that it takes a data constructor, not a type constructor, as an argument, and it adds extra universal type variables from that data constructor at the end of the returned list if need be. `dataConInstUnivs` takes care to instantiate the kinds of the universal type variables at the end, thereby avoiding a bug in `tyConInstArgTys` discovered in https://gitlab.haskell.org/ghc/ghc/-/issues/20387#note_377037. Fixes #20375. Fixes #20387.
* Refactoring: Move DataConEnv to GHC.Core.DataConRyan Scott2021-11-152-2/+5
| | | | | `DataConEnv` will prove to be useful in another place besides `GHC.Core.Opt.SpecConstr` in a follow-up commit.
* Refactoring: Consolidate some arguments with DerivInstTysRyan Scott2021-11-155-141/+135
| | | | | | | | | | | Various functions in GHC.Tc.Deriv.* were passing around `TyCon`s and `[Type]`s that ultimately come from the same `DerivInstTys`. This patch moves the definition of `DerivInstTys` to `GHC.Tc.Deriv.Generate` so that all of these `TyCon` and `[Type]` arguments can be consolidated into a single `DerivInstTys`. Not only does this make the code easier to read (in my opinion), this will also be important in a subsequent commit where we need to add another field to `DerivInstTys` that will also be used from `GHC.Tc.Deriv.Generate` and friends.
* Remove bit about size_t in ghc-llvm-version.hJohn Ericson2021-11-121-2/+0
| | | | | This shouldn't be here. It wasn't causing a problem because this header was only used from Haskell, but still.
* Delete compiler/MachDeps.hJohn Ericson2021-11-121-119/+0
| | | | | | | This was accidentally added back in 28334b475a109bdeb8d53d58c48adb1690e2c9b4 after it is was no longer needed by the compiler proper in 20956e5784fe43781d156dd7ab02f0bff4ab41fb.
* Get the in-scope set right in simplArgSimon Peyton Jones2021-11-121-2/+5
| | | | | This was a simple (but long standing) error in simplArg, revealed by #20639
* Implement -Wforall-identifier (#20609)Vladislav Zavialov2021-11-1211-8/+60
| | | | | | | | | | In accordance with GHC Proposal #281 "Visible forall in types of terms": For three releases before this change takes place, include a new warning -Wforall-identifier in -Wdefault. This warning will be triggered at definition sites (but not use sites) of forall as an identifier. Updates the haddock submodule.
* Use local instances with least superclass depthRichard Eisenberg2021-11-127-82/+180
| | | | | | | | | | See new Note [Use only the best local instance] in GHC.Tc.Solver.Interact. This commit also refactors the InstSC/OtherSC mechanism slightly. Close #20582.
* Improve redundant-constraints warningRichard Eisenberg2021-11-128-93/+158
| | | | | | | | | | | | | | Previously, we reported things wrong with f :: (Eq a, Ord a) => a -> Bool f x = x == x saying that Eq a was redundant. This is fixed now, along with some simplification in Note [Replacement vs keeping]. There's a tiny bit of extra complexity in setImplicationStatus, but it's explained in Note [Tracking redundant constraints]. Close #20602
* Make: Do not generate ghc.* headers in stage0John Ericson2021-11-121-1/+1
| | | | | GHC should get everything it needs from the RTS, which for stage0 is the "old" RTS that comes from the bootstrap compiler.
* Turn GHC.Data.Graph.Base.Graph into a newtypeSimon Jakobi2021-11-121-1/+1
|
* Only pass -pie, -no-pie when linkingMatthew Bauer2021-11-112-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, these flags were passed when both compiling and linking code. However, `-pie` and `-no-pie` are link-time-only options. Usually, this does not cause issues, but when using Clang with `-Werror` set results in errors: clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument] This is unused by Clang because this flag has no effect at compile time (it’s called `-nopie` internally by Clang but called `-no-pie` in GHC for compatibility with GCC). Just passing these flags at linking time resolves this. Additionally, update #15319 hack to look for `-pgml` instead. Because of the main change, the value of `-pgmc` does not matter when checking for the workaround of #15319. However, `-pgml` *does* still matter as not all `-pgml` values support `-no-pie`. To cover all potential values, we assume that no custom `-pgml` values support `-no-pie`. This means that we run the risk of not using `-no-pie` when it is otherwise necessary for in auto-hardened toolchains! This could be a problem at some point, but this workaround was already introduced in 8d008b71 and we might as well continue supporting it. Likewise, mark `-pgmc-supports-no-pie` as deprecated and create a new `-pgml-supports-no-pie`.
* driver: Use shared transitive dependency calculation in hptModulesBelowMatthew Pickering2021-11-111-23/+10
| | | | | | | | | | This saves a lot of repeated work on big dependency graphs. ------------------------- Metric Decrease: MultiLayerModules T13719 -------------------------
* driver: Cache the transitive dependency calculation in ModuleGraphMatthew Pickering2021-11-113-106/+135
| | | | | | | | Two reasons for this change: 1. Avoid computing the transitive dependencies when compiling each module, this can save a lot of repeated work. 2. More robust to forthcoming changes to support multiple home units.
* Fix Note [Function types]Richard Eisenberg2021-11-101-37/+29
| | | | Close #19938.
* Flesh out Note [The stupid context] and reference itRyan Scott2021-11-0913-40/+78
| | | | | | `Note [The stupid context]` in `GHC.Core.DataCon` talks about stupid contexts from `DatatypeContexts`, but prior to this commit, it was rather outdated. This commit spruces it up and references it from places where it is relevant.
* deriving: infer DatatypeContexts from data constructors, not type constructorRyan Scott2021-11-091-13/+24
| | | | | | | | | | | | | | Previously, derived instances that use `deriving` clauses would infer `DatatypeContexts` by using `tyConStupidTheta`. But this sometimes causes redundant constraints to be included in the derived instance contexts, as the constraints that appear in the `tyConStupidTheta` may not actually appear in the types of the data constructors (i.e., the `dataConStupidTheta`s). For instance, in `data Show a => T a = MkT deriving Eq`, the type of `MkT` does not require `Show`, so the derived `Eq` instance should not require `Show` either. This patch makes it so with some small tweaks to `inferConstraintsStock`. Fixes #20501.
* SpecConstr - Attach evaldUnfolding to known evaluated arguments.Andreas Klebinger2021-11-091-31/+153
|
* Default kind vars in tyfams with -XNoPolyKindssheaf2021-11-089-108/+319
| | | | | | | | | | | | | | | We should still default kind variables in type families in the presence of -XNoPolyKinds, to avoid suggesting enabling -XPolyKinds just because the function arrow introduced kind variables, e.g. type family F (t :: Type) :: Type where F (a -> b) = b With -XNoPolyKinds, we should still default `r :: RuntimeRep` in `a :: TYPE r`. Fixes #20584
* Pmc: Do inhabitation test for unlifted vars (#20631)Sebastian Graf2021-11-072-17/+30
| | | | | | | | | | | Although I thought we were already set to handle unlifted datatypes correctly, it appears we weren't. #20631 showed that it's wrong to assume `vi_bot=IsNotBot` for `VarInfo`s of unlifted types from their inception if we don't follow up with an inhabitation test to see if there are any habitable constructors left. We can't trigger the test from `emptyVarInfo`, so now we instead fail early in `addBotCt` for variables of unlifted types. Fixed #20631.
* Print the Type kind qualified when ambiguous (#20627)Vladislav Zavialov2021-11-073-18/+52
| | | | | | | | | | | | | | | 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
* Don't undersaturate join points through eta-reduction.Andreas Klebinger2021-11-072-2/+13
| | | | | | | | In #20599 I ran into an issue where the unfolding for a join point was eta-reduced removing the required lambdas. This patch adds guards that should prevent this from happening going forward.
* Refactor HdkM using deriving viaVladislav Zavialov2021-11-061-27/+14
| | | | | | * No more need for InlineHdkM, mkHdkM * unHdkM is now just a record selector * Update comments
View Lorry Controller Status