summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* EPA: Preserve semicolon order in annotationsAlan Zimmerman2021-10-144-70/+111
| | | | | | | | | Ensure the AddSemiAnn items appear in increasing order, so that if they are converted to delta format they are still in the correct order. Prior to this the exact printer sorted by Span, which is meaningless for EpaDelta locations.
* fuzzyLookup: More deterministic orderJoachim Breitner2021-10-141-4/+10
| | | | | | 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.
* Suggest -dynamic-too in failNonStd when applicableZiyang Liu2021-10-141-12/+26
| | | | | | | | | | | | | | | | | | I encountered an error that says ``` Cannot load -dynamic objects when GHC is built the normal way To fix this, either: (1) Use -fexternal-interpreter, or (2) Build the program twice: once the normal way, and then with -dynamic using -osuf to set a different object file suffix. ``` Or it could say ``` (2) Use -dynamic-too ```
* Move BreakInfo into own moduleJoachim Breitner2021-10-146-10/+18
| | | | | | | | | | while working on GHCi stuff, e.g. `GHC.Runtime.Eval.Types`, I observed a fair amount of modules being recompiled that I didn’t expect to depend on this, from byte code interpreters to linkers. Turns out that the rather simple `BreakInfo` type is all these modules need from the `GHC.Runtime.Eval.*` hierarchy, so by moving that into its own file we make the dependency tree wider and shallower, which is probably worth it.
* Set logger flags in --backpack modesheaf2021-10-131-2/+3
| | | | | | | | | | Backpack used to initialise the logger before obtaining the DynFlags. This meant that logging options (such as dump flags) were not set. Initialising the logger after the session flags have been set fixes the issue. fixes #20396
* Define and export Outputable instance for StgOpNorman Ramsey2021-10-131-0/+3
|
* shadowNames: Accept an OccName, not a GreNameJoachim Breitner2021-10-133-22/+13
| | | | | | | | | | | | | | | | | | | | | | | | previously, the `shadowNames` function would take `[GreName]`. This has confused me for two reasons: * Why `GreName` and not `Name`? Does the difference between a normal name and a field name matter? The code of `shadowNames` shows that it does not, but really its better if the type signatures says so. * Why `Name` and not `OccName`? The point of `shadowNames` is to shadow _unqualified names_, at least in the two use cases I am aware of (names defined on the GHCI prompt or in TH splices). The code of `shadowNames` used to have cases that peek at the module of the given name and do something if that module appears in the `GlobalRdrElt`, but I think these cases are dead code, I don’t see how they could occur in the above use cases. Also, I replaced them with `errors` and GHC would still validate. Hence removing this code (yay!) This change also allows `shadowNames` to accept an `OccSet` instead, which allows for a faster implemenation; I’ll try that separately. This in stead might help with !6703.
* Force name_exe field to avoid retaining entire UnitEnv (including whole HPT)Matthew Pickering2021-10-121-2/+2
| | | | | Not forcing this one place will result in GHCi using 2x memory on a reload.
* driver: Filter out HPT modules **before** typecheck loopMatthew Pickering2021-10-121-3/+5
| | | | | | It's better to remove the modules first before performing the typecheckLoop as otherwise you can end up with thunks which reference stale HomeModInfo which are difficult to force due to the knot-tie.
* More strictness around HomePackageTableMatthew Pickering2021-10-123-10/+20
| | | | | | | | | This patch makes some operations to do with HomePackageTable stricter * Adding a new entry into the HPT would not allow the old HomeModInfo to be collected because the function used by insertWith wouldn't be forced. * We're careful to force the new MVar value before it's inserted into the global MVar as otherwise we retain references to old entries.
* Make the fields of MakeEnv strictMatthew Pickering2021-10-121-5/+5
| | | | | There's no reason for them to be lazy, and in particular we would like to make sure the old_hpt field is evaluated.
* Make fields of Linkable strictMatthew Pickering2021-10-121-2/+2
| | | | | The Module field can end up retaining part of a large structure and is always calculated by projection.
* driver: Pass hsc_env with empty HPT into upsweepMatthew Pickering2021-10-121-0/+1
| | | | Otherwise you end up retaining the whole old HPT when reloading in GHCi.
* Be more careful about retaining KnotVarsMatthew Pickering2021-10-124-5/+51
| | | | | | | | | | | | | | | | | | | | | 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)
* Make the OccName field of NotOrphan strictMatthew Pickering2021-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | In GHCi, by default the ModIface is not written to disk, this can leave a thunk which retains a TyCon which ends up retaining a great deal more on the heap. For example, here is the retainer trace from ghc-debug. ``` ... many other closures ... <TyCon:GHC.Core.TyCon:compiler/GHC/Core/TyCon.hs:1755:34-97> Just 0x423162aaa8 <Maybe:GHC.Core.TyCon:compiler/GHC/Core/TyCon.hs:(1936,11)-(1949,13)> FamilyTyCon 0x4231628318 0x4210e06260 0x4231628328 0x4231628340 0x421730a398 0x4231628358 0x4231628380 0x4231628390 0x7f0f5a171d18 0x7f0f7b1d7850 0x42316283a8 0x7f0f7b1d7830 <TyCon:GHC.Core.TyCon:compiler/GHC/Cor e/TyCon.hs:1948:30-32> _thunk( ) 0x4231624000 <OccName:GHC.Iface.Make:compiler/GHC/Iface/Make.hs:724:22-43> NotOrphan 0x42357d8ed8 <IsOrphan:GHC.Iface.Make:compiler/GHC/Iface/Make.hs:724:12-43> IfaceFamInst 0x4210e06260 0x42359aed10 0x4210e0c6b8 0x42359aed28 <IfaceFamInst:GHC.Iface.Make:> ``` Making the field strict squashes this retainer leak when using GHCi.
* Make ms_ghc_prim_import field strictMatthew Pickering2021-10-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | If you don't promptly force this field then it ends up retaining a lot of data structures related to parsing. For example, the following retaining chain can be observed when using GHCi. ``` PState 0x4289365ca0 0x4289385d68 0x4289385db0 0x7f81b37a7838 0x7f81b3832fd8 0x4289365cc8 0x4289365cd8 0x4289365cf0 0x4289365cd8 0x4289365d08 0x4289385e48 0x7f81b4e4c290 0x7f818f63f440 0x7f818f63f440 0x7f81925ccd18 0x7f81b4e41230 0x7f818f63f440 0x7f81925ccd18 0x7f818f63f4a8 0x7f81b3832fd8 0x7f81b3832fd8 0x4289365d20 0x7f81b38233b8 0 19 <PState:GHC.Parser.Lexer:_build-ipe/stage1/compiler/build/GHC/Parser/Lexer.hs:3779:46> _thunk( ) 0x4289384230 0x4289384160 <([LEpaComment], [LEpaComment]):GHC.Parser.Lexer:> _thunk( ) 0x4289383250 <EpAnnComments:GHC.Parser.Lexer:compiler/GHC/Parser/Lexer.x:2306:19-40> _thunk( ) 0x4289399850 0x7f818f63f440 0x4289399868 <SrcSpanAnnA:GHC.Parser:_build-ipe/stage1/compiler/build/GHC/Parser.hs:12527:13-30> L 0x4289397600 0x42893975a8 <GenLocated:GHC.Parser:_build-ipe/stage1/compiler/build/GHC/Parser.hs:12527:32> 0x4289c4e8c8 : 0x4289c4e8b0 <[]:GHC.Parser.Header:compiler/GHC/Parser/Header.hs:104:36-54> (0x4289c4da70,0x7f818f63f440) <(,):GHC.Parser.Header:compiler/GHC/Parser/Header.hs:104:36-54> _thunk( ) 0x4289c4d030 <Bool:GHC.Parser.Header:compiler/GHC/Parser/Header.hs:(112,22)-(115,27)> ExtendedModSummary 0x422e9c8998 0x7f81b617be78 0x422e9c89b0 0x4289c4c0c0 0x7f81925ccd18 0x7f81925ccd18 0x7f81925ccd18 0x7f81925ccd18 0x7f818f63f440 0x4289c4c0d8 0x4289c4c0f0 0x7f81925ccd18 0x422e9c8a20 0x4289c4c108 0x4289c4c730 0x7f818f63f440 <ExtendedModSummary:GHC.Driver.Make:compiler/GHC/Driver/Make.hs:2041:30-38> ModuleNode 0x4289c4b850 <ModuleGraphNode:GHC.Unit.Module.Graph:compiler/GHC/Unit/Module/Graph.hs:139:14-36> 0x4289c4b590 : 0x4289c4b578 <[]:GHC.Unit.Module.Graph:compiler/GHC/Unit/Module/Graph.hs:139:31-36> ModuleGraph 0x4289c4b2f8 0x4289c4b310 0x4289c4b340 0x7f818f63f4a0 <ModuleGraph:GHC.Driver.Make:compiler/GHC/Driver/Make.hs:(242,19)-(244,40)> HscEnv 0x4289d9a4a8 0x4289d9aad0 0x4289d9aae8 0x4217062a88 0x4217060b38 0x4217060b58 0x4217060b68 0x7f81b38a7ce0 0x4217060b78 0x7f818f63f440 0x7f818f63f440 0x4217062af8 0x4289d9ab10 0x7f81b3907b60 0x4217060c00 114 <HscEnv:GHC.Runtime.Eval:compiler/GHC/Runtime/Eval.hs:790:31-44> ```
* driver: Share the graph of dependenciesZubin Duggal2021-10-121-3/+5
| | | | We want to share the graph instead of recomputing it for each key.
* Add Hint to "Empty 'do' block" Error Message#20147Carrie Xu2021-10-121-0/+3
|
* Derive Eq instance for the HieTypeFix typeZejun Wu2021-10-121-0/+1
| | | | | | | We have `instance Eq a => Eq (HieType a)` already. This instance can be handy when we want to impement a function to find all `fromIntegral :: a -> a` using `case ty of { Roll (HFunTy _ a b) -> a == b; _ -> False }`.
* driver: Fix assertion failure on self-importMatthew Pickering2021-10-101-1/+1
| | | | Fixes #20459
* Reject GADT pattern matches in arrow notationsheaf2021-10-0913-58/+146
| | | | | | | | | | | | 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-086-26/+117
| | | | | | | | | | | | | | | 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.
* code gen: Disable dead code elimination when -finfo-table-map is enabledMatthew Pickering2021-10-083-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's important that when -finfo-table-map is enabled that we generate IPE entries just for those info tables which are actually used. To this end, the info tables which are used are collected just before code generation starts and entries only created for those tables. Not accounted for in this scheme was the dead code elimination in the native code generator. When compiling GHC this optimisation removed an info table which had an IPE entry which resulting in the following kind of linker error: ``` /home/matt/ghc-with-debug/_build/stage1/lib/../lib/x86_64-linux-ghc-9.3.20210928/libHSCabal-3.5.0.0-ghc9.3.20210928.so: error: undefined reference to '.Lc5sS_info' /home/matt/ghc-with-debug/_build/stage1/lib/../lib/x86_64-linux-ghc-9.3.20210928/libHSCabal-3.5.0.0-ghc9.3.20210928.so: error: undefined reference to '.Lc5sH_info' /home/matt/ghc-with-debug/_build/stage1/lib/../lib/x86_64-linux-ghc-9.3.20210928/libHSCabal-3.5.0.0-ghc9.3.20210928.so: error: undefined reference to '.Lc5sm_info' collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) Development.Shake.cmd, system command failed ``` Unfortunately, by the time this optimisation happens the structure of the CmmInfoTable has been lost, we only have the generated code for the info table to play with so we can no longer just collect all the used info tables and generate the IPE map. This leaves us with two options: 1. Return a list of the names of the discarded info tables and then remove them from the map. This is awkward because we need to do code generation for the map as well. 2. Just disable this small code size optimisation when -finfo-table-map is enabled. The option produces very big object files anyway. Option 2 is much easier to implement and means we don't have to thread information around awkwardly. It's at the cost of slightly larger object files (as dead code is not eliminated). Disabling this optimisation allows an IPE build of GHC to complete successfully. Fixes #20428
* Fix -E -fno-code undesirable interactions #20439CarrieMY2021-10-081-2/+4
|
* Don't link plugins' units with target code (#20218)Sylvain Henry2021-10-082-2/+14
| | | | | | | | | | | | | | Before this patch, plugin units were linked with the target code even when the unit was passed via `-plugin-package`. This is an issue to support plugins in cross-compilers (plugins are definitely not ABI compatible with target code). We now clearly separate unit dependencies for plugins and unit dependencies for target code and only link the latter ones. We've also added a test to ensure that plugin units passed via `-package` are linked with target code so that `thNameToGhcName` can still be used in plugins that need it (see T20218b).
* Bignum: remove outdated commentSylvain Henry2021-10-071-8/+0
|
* Bignum: allow naturalToWordClamp/Negate/Signum to inline (#20361)Sylvain Henry2021-10-072-29/+3
| | | | | We don't need built-in rules now that bignum literals (e.g. 123 :: Natural) match with their constructors (e.g. NS 123##).
* Bignum: allow inlining of naturalEq/Ne/Gt/Lt/Ge/Le/Compare (#20361)Sylvain Henry2021-10-072-64/+19
| | | | | | | | | | Perform constant folding on bigNatCompare instead. Some functions of the Enum class for Natural now need to be inlined explicitly to be specialized at call sites (because `x > lim` for Natural is inlined and the resulting function is a little too big to inline). If we don't do this, T17499 runtime allocations regresses by 16%.
* Bignum: allow naturalEq#/Ne# to inline (#20361)Sylvain Henry2021-10-072-12/+17
| | | | We now perform constant folding on bigNatEq# instead.
* EPA: Add comments to EpaDeltaAlan Zimmerman2021-10-073-20/+25
| | | | | | | | | The EpaDelta variant of EpaLocation cannot be sorted by location. So we capture any comments that need to be printed between the prior output and this location, when creating an EpaDelta offset in ghc-exactprint. And make the EpaLocation fields strict.
* Removed left-over comment from `nonDetEltsUFM`-removal in `seqEltsUFM`.Benjamin Maurer2021-10-071-3/+0
|
* Improve overlap error for polykinded constraintssheaf2021-10-063-28/+37
| | | | | | | | | | | | | | 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
* Disable -dynamic-too if -dynamic is also passedMatthew Pickering2021-10-061-0/+6
| | | | | | | | | | | Before if you passed both options then you would generate two identical hi/dyn_hi and o/dyn_o files, both in the dynamic way. It's better to warn this is happening rather than duplicating the work and causing potential confusion. -dynamic-too should only be used with -static. Fixes #20436
* Remove the Maybe in primRepName's typeRyan Scott2021-10-061-8/+9
| | | | | | | There's no need for this `Maybe`, as it will always be instantiated to `Just` in practice. Fixes #20482.
* EPA: Remove duplicate AnnOpenP/AnnCloseP in DataDeclAlan Zimmerman2021-10-061-16/+13
| | | | | | | The parens EPAs were added in the tyvars where they belong, but also at the top level of the declaration. Closes #20452
* Constant folding for (.&.) maxBound (#20448)Sylvain Henry2021-10-051-0/+6
|
* Ensure top-level binders in scope in SetLevelsSimon Peyton Jones2021-10-051-30/+37
| | | | | | | | | | | | | | | | | Ticket #20200 (the Agda failure) showed another case in which lookupIdSubst would fail to find a local Id in the InScopeSet. This time it was because SetLevels was given a program in which the top-level bindings were not in dependency order. The Simplifier (see Note [Glomming] in GHC.Core.Opt.Occuranal) and the specialiser (see Note [Top level scope] in GHC.Core.Opt.Specialise) may both produce top-level bindings where an early binding refers to a later one. One solution would be to run the occurrence analyser again to put them all in the right order. But a simpler one is to make SetLevels OK with this input by bringing all top-level binders into scope at the start. That's what this patch does.
* Eradicate TcRnUnknownMessage from GHC.Tc.DerivAlfredo Di Napoli2021-10-058-322/+921
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-054-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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@.
* CprAnal: Activate Sum CPR for local bindingsSebastian Graf2021-10-051-64/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've had Sum CPR (#5075) for top-level bindings for a couple of years now. That begs the question why we didn't also activate it for local bindings, and the reasons for that are described in `Note [CPR for sum types]`. Only that it didn't make sense! The Note said that Sum CPR would destroy let-no-escapes, but that should be a non-issue since we have syntactic join points in Core now and we don't WW for them (`Note [Don't w/w join points for CPR]`). So I simply activated CPR for all bindings of sum type, thus fixing #5075 and \#16570. NoFib approves: ``` -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- comp_lab_zift -0.0% +0.7% fluid +1.7% +0.7% reptile +0.1% +0.1% -------------------------------------------------------------------------------- Min -0.0% -0.2% Max +1.7% +0.7% Geometric Mean +0.0% +0.0% ``` There were quite a few metric decreases on the order of 1-4%, but T6048 seems to regress significantly, by 26.1%. WW'ing for a `Just` constructor and the nested data type meant additional Simplifier iterations and a 30% increase in term sizes as well as a 200-300% in type sizes due to unboxed 9-tuples. There's not much we can do about it, I'm afraid: We're just doing much more work there. Metric Decrease: T12425 T18698a T18698b T20049 T9020 WWRec Metric Increase: T6048
* Simplifier: Get rid of demand zapping based on Note [Arity decrease]Sebastian Graf2021-10-051-32/+3
| | | | | | | | The examples in the Note were inaccurate (`$s$dm` has arity 1 and that seems OK) and the code didn't actually nuke the demand *signature* anyway. Specialise has to nuke it, but it starts from a clean IdInfo anyway (in `newSpecIdM`). So I just deleted the code. Fixes #20450.
* WorkWrap: Nuke CPR signatures of join points (#18824)Sebastian Graf2021-10-051-23/+29
| | | | | | | | | | | | In #18824 we saw that the Simplifier didn't nuke a CPR signature of a join point when it pushed a continuation into it when it better should have. But join points are local, mostly non-exported bindings. We don't use their CPR signature anyway and would discard it at the end of the Core pipeline. Their main purpose is to propagate CPR info during CPR analysis and by the time worker/wrapper runs the signature will have served its purpose. So we zap it! Fixes #18824.
* 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
* Bespoke TokenLocation data typeVladislav Zavialov2021-10-044-12/+36
| | | | | | | | | | | | The EpaAnnCO we were using contained an Anchor instead of EpaLocation, making it harder to work with. At the same time, using EpaLocation by itself isn't possible either, as we may have tokens without location information. Hence the new data type: data TokenLocation = NoTokenLoc | TokenLoc !EpaLocation
* compiler: Fix racy ticker counter registrationBen Gamari2021-10-043-25/+47
| | | | | | | | | Previously registration of ticky entry counters was racy, performing a read-modify-write to add the new counter to the ticky_entry_ctrs list. This could result in the list becoming cyclic if multiple threads entered the same closure simultaneously. Fixes #20451.
* compiler: Improve Haddocks of atomic MachOpsBen Gamari2021-10-041-2/+4
|
* Clean up HiePass constraintsVladislav Zavialov2021-10-042-54/+26
|
* Constant folding for negate (#20347)Sylvain Henry2021-10-041-16/+49
| | | | Only for small integral types for now.
View Lorry Controller Status