summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* Rename fp_gcc_supports__atomics to fp_cc_supports__atomicsHaochen Tong2021-10-122-6/+6
|
* Move libatomic check into m4/fp_gcc_supports_atomics.m4Haochen Tong2021-10-122-46/+41
|
* Check for libatomic dependency for atomic operationsHaochen Tong2021-10-123-0/+34
| | | | | | | Some platforms (e.g. RISC-V) require linking against libatomic for some (e.g. sub-word-sized) atomic operations. Fixes #19119.
* 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.
* Add GHCi recompilation performance testMatthew Pickering2021-10-123-0/+44
|
* 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.
* gitlab-ci: Bump docker imagesBen Gamari2021-10-121-2/+1
| | | | Bumps bootstrap compiler to GHC 9.0.1.
* testsuite: Clean up dynlib support predicatesBen Gamari2021-10-1218-44/+83
| | | | | | | | | | | | | | | | | | Previously it was unclear whether req_shared_libs should require: * that the platform supports dynamic library loading, * that GHC supports dynamic linking of Haskell code, or * that the dyn way libraries were built Clarify by splitting the predicate into two: * `req_dynamic_lib_support` demands that the platform support dynamic linking * `req_dynamic_hs` demands that the GHC support dynamic linking of Haskell code on the target platform Naturally `req_dynamic_hs` cannot be true unless `req_dynamic_lib_support` is also true.
* testsuite: Fix overzealous command-line manglingBen Gamari2021-10-121-1/+1
| | | | | Previously this attempt at suppressing make's -s flag would mangle otherwise valid arguments.
* testsuite: Move big-obj test from ghci/linking/dyn to ghci/linkingBen Gamari2021-10-127-9/+10
| | | | There was nothing dynamic about this test.
* rts/RtsSymbols: fini arrayBen Gamari2021-10-121-0/+13
|
* rts/RtsSymbols: Declare atexit as a strong symbolBen Gamari2021-10-121-1/+10
|
* rts/linker: Introduce a notion of strong symbolsBen Gamari2021-10-124-26/+51
|
* rts/RtsSymbols: Add environBen Gamari2021-10-121-0/+1
|
* gitlab-ci: Mark more broken tests on AlpineBen Gamari2021-10-121-3/+5
|
* testsuite: Make T12600 more robustBen Gamari2021-10-121-1/+1
| | | | | | Previously we would depend upon `grep ... | head -n1`. In principle this should work, but on Alpine Linux `grep` complains when its stdout stream has been closed.
* testsuite: Make recomp021 less environment-sensitiveBen Gamari2021-10-122-2/+2
| | | | | Suppress output from diff to eliminate unnecessary environmental-dependence.
* documentation: flavours.md static detailsBrian Jaress2021-10-121-2/+4
|
* testsuite: Compile safeInfered tests with -v0Ben Gamari2021-10-1216-57/+14
| | | | | This eliminates some spurious platform-dependence due to static linking (namely in UnsafeInfered02 due to dynamic-too).
* testsuite: Mark T14931 as requiring dynamic linkingBen Gamari2021-10-121-1/+1
|
* testsuite: Mark all ghci/linking/dyn tests as requiring dynamic linkingBen Gamari2021-10-121-0/+2
|
* testsuite: Mark ghcilink00[25] as requiring dynamic linkingBen Gamari2021-10-121-2/+4
|
* testsuite: Mark T13702 as requiring share librariesBen Gamari2021-10-121-1/+1
| | | | | | | | | | | | | It fails on statically-built Alpine with ``` T13702.hs:1:1: error: Could not find module ‘Prelude’ Perhaps you haven't installed the "dyn" libraries for package ‘base-4.15.0.0’? Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 1 | {-# LANGUAGE ForeignFunctionInterface #-} | ^ ```
* rts/linker: Resolve __fini_array_* symbols to NULLGHC GitLab CI2021-10-121-0/+4
| | | | | If the __fini_array_{start,end} symbols are not defined (e.g. as is often the case when linking against musl) then resolve them to NULL.
* rts/linker: Define _DYNAMIC when necessaryBen Gamari2021-10-121-1/+13
| | | | | | Usually the dynamic linker would define _DYNAMIC. However, when dynamic linking is not supported (e.g. on musl) it is safe to define it to be NULL.
* testsuite: Drop :set from ghci scriptsBen Gamari2021-10-128-316/+2
| | | | | | | | The ghci scripts for T9293 and ghci057 used `:set` to print the currently-set options. However, in neither case was this necessary to the correctness of the test and moreover it would introduce spurious platform-dependence (e.g. since `-fexternal-dynamic-refs` is set by default only on platforms that support dynamic linking).
* gitlab-ci: Introduce static Alpine jobBen Gamari2021-10-122-1/+28
|
* hadrian: Introduce `static` flavourBen Gamari2021-10-125-2/+94
|
* 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.
* Change affected tests stderrCarrie Xu2021-10-122-4/+9
|
* Add Hint to "Empty 'do' block" Error Message#20147Carrie Xu2021-10-124-0/+15
|
* rts/Linker: Fix __dso_handle handlingGHC GitLab CI2021-10-121-10/+27
| | | | | | | | | | | | Previously the linker's handling of __dso_handle was quite wrong. Not only did we claim that __dso_handle could be NULL when statically linking (which it can not), we didn't even implement this mislead theory faithfully and instead resolved the symbol to a random pointer. This lead to the failing relocations on AArch64 noted in #20493. Here we try to implement __dso_handle as a dynamic linker would do, choosing an address within the loaded object (specifically its start address) to serve as the object's handle.
* rts/nonmoving: Enable selector optimisation by defaultBen Gamari2021-10-123-12/+1
|
* rts/primops: Fix write barrier in stg_atomicModifyMutVarzuzhBen Gamari2021-10-121-4/+4
| | | | | | | Previously the call to dirty_MUT_VAR in stg_atomicModifyMutVarzuzh was missing its final argument. Fixes #20414.
* rts/nonmoving: Rename mark_* to trace_*Ben Gamari2021-10-121-42/+42
| | | | These functions really do no marking; they merely trace pointers.
* nonmoving: Fix and factor out mark_trec_chunkBen Gamari2021-10-121-22/+17
| | | | | We need to ensure that the TRecChunk itself is marked, in addition to the TRecs it contains.
* 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 }`.
* hadrian: Include Cabal flags in verbose configure outputBen Gamari2021-10-101-4/+4
|
* driver: Fix assertion failure on self-importMatthew Pickering2021-10-105-1/+12
| | | | Fixes #20459
* Reject GADT pattern matches in arrow notationsheaf2021-10-0941-77/+376
| | | | | | | | | | | | 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-0824-37/+453
| | | | | | | | | | | | | | | 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.
View Lorry Controller Status