summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Experiment: Split [GlobalRdrElt] into also-unqualified and only-qualifiedwip/joachim/split-GlobalRdrEltsJoachim Breitner2021-10-1610-77/+119
| | | | crude refactoring so far.
* Move comment to test fileJoachim Breitner2021-10-164-19/+10
| | | | | and remove the comment; it’s rather stale and things are better explained elsewhere. Fixes #925.
* User’s guide entryJoachim Breitner2021-10-161-0/+39
|
* Hide shadowed names from `:show bindings`Joachim Breitner2021-10-164-4/+111
| | | | | | | | | | | | | | | Since the previous commit, all names ever defined in GHCi are in `ic_tythings`. This is important, because they are all reachable, although maybe in qualified form. But for `:show bindings` it seems to be more ergonomic to only list those bindings that are not shadowed. Or, 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.
* Ghci environment: Do not remove shadowed idsJoachim Breitner2021-10-165-20/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | previously defined names 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 work 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.
* InteractiveContext: Smarter caching when rebuilding the ic_rn_gbl_envJoachim Breitner2021-10-165-37/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 11%; caching isn’t free. Oh well. Metric Decrease: T14052Type Metric Increase: T14052
* hadrian: Document lint targetsMatthew Pickering2021-10-151-0/+14
| | | | Fixes #20508
* shadowNames: Use OccEnv a, not [OccName]Joachim Breitner2021-10-155-18/+34
| | | | | | | | | | | | | | this allows us to use a smarter implementation based on `Data.IntSet.differenceWith`, which should do less work. Also, it will unblock improvements to !6703. The `OccEnv a` really denotes a set of `OccName`s. We are not using `OccSet`, though, because that is an `OccEnv OccName`, and we in !6703 we want to use this with differently-valued `OccEnv`s. But `OccSet`s are readily and safely coerced into `OccEnv`s. There is no other use of `delLocalRdrEnvList` remaining, so removing that.
* Hadrian: display command line above errors (#20490)Sylvain Henry2021-10-154-18/+127
|
* Null eventlog writerOleg Grenrus2021-10-158-0/+56
|
* GHC.Builtin.Uniques: Remove unused codeJoachim Breitner2021-10-153-32/+7
| | | | | | | | | | | | | | a number of functions exported by this module are (no longer) used, so let’s remove them. In particular, it no longer seems to be the case that type variables have tag `'t'`, so removed the special handling when showing them. * the use of `initTyVarUnique` was removed in 7babb1 (with the notable commit message of "Before merging to HEAD we need to tidy up and write a proper commit message.") * `mkPseudoUniqueD`and `mkPseudoUniqueH` were added in 423d477, but never ever used? * `mkCoVarUnique` was added in 674654, but never ever used?
* Insert warnings in the documentation of dangerous functionsTom Sydney Kerckhove2021-10-158-2/+76
|
* Some extra strictness in annotation fieldsMatthew Pickering2021-10-141-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Locations can be quite long-lived so it's important that things which live in locations, such as annotations are forced promptly. Otherwise they end up retaining the entire PState, as evidenced by this retainer trace: ``` PState 0x4277ce6cd8 0x4277ce6d00 0x7f61f12d37d8 0x7f61f12d37d8 0x7f61f135ef78 0x4277ce6d48 0x4277ce6d58 0x4277ce6d70 0x4277ce6d58 0x4277ce6d88 0x4277ce6da0 0x7f61f29782f0 0x7f61cd16b440 0x7f61cd16b440 0x7f61d00f8d18 0x7f61f296d290 0x7f61cd16b440 0x7f61d00f8d18 0x7f61cd16b4a8 0x7f61f135ef78 0x4277ce6db8 0x4277ce6dd0 0x7f61f134f358 0 3 <PState:GHC.Parser.Lexer:_build-ipe/stage1/compiler/build/GHC/Parser/Lexer.hs:3779:46> _thunk( ) 0x4277ce6280 0x4277ce68a0 <([LEpaComment], [LEpaComment]):GHC.Parser.Lexer:> _thunk( ) 0x4277ce6568 <EpAnnComments:GHC.Parser.Lexer:compiler/GHC/Parser/Lexer.x:2306:19-40> _thunk( ) 0x4277ce62b0 0x4277ce62c0 0x4277ce6280 0x7f61f287fc58 <EpAnn AnnList:GHC.Parser:_build-ipe/stage1/compiler/build/GHC/Parser.hs:12664:13-32> SrcSpanAnn 0x4277ce6060 0x4277ce6048 <SrcSpanAnn':GHC.Parser:_build-ipe/stage1/compiler/build/GHC/Parser.hs:12664:3-35> L 0x4277ce4e70 0x428f8c9158 <GenLocated:GHC.Data.BooleanFormula:compiler/GHC/Data/BooleanFormula.hs:40:23-29> 0x428f8c8318 : 0x428f8c8300 <[]:GHC.Base:libraries/base/GHC/Base.hs:1316:16-29> Or 0x428f8c7890 <BooleanFormula:GHC.Data.BooleanFormula:compiler/GHC/Data/BooleanFormula.hs:40:23-29> IfConcreteClass 0x7f61cd16b440 0x7f61cd16b440 0x428f8c7018 0x428f8c7030 <IfaceClassBody:GHC.Iface.Make:compiler/GHC/Iface/Make.hs:(640,12)-(645,13)> ``` Making these few places strict is sufficient for now but there are perhaps more places which will need strictifying in future. ------------------------- Metric Increase: parsing001 -------------------------
* EPA: Preserve semicolon order in annotationsAlan Zimmerman2021-10-149-75/+2236
| | | | | | | | | 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-1410-19/+25
| | | | | | 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-148-12/+22
| | | | | | | | | | 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.
* Make sure paths are quoted in install MakefileMatthew Pickering2021-10-141-1/+1
| | | | | | | | | | | | | | | Previously it would fail with this error: ``` if [ -L wrappers/ghc ]; then echo "ghc is a symlink"; fi ghc is a symlink cp: target 'dir/bin/ghc' is not a directory make: *** [Makefile:197: install_wrappers] Error 1 ``` which is because the install path contains a space. Fixes #20506
* Set logger flags in --backpack modesheaf2021-10-134-2/+33
| | | | | | | | | | 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
* distrib/configure: Add AC_CONFIG_MACRO_DIRSBen Gamari2021-10-131-0/+2
| | | | | Sadly, autoconf cannot warn when it encounters an undefined macro and therefore this bug went unnoticed for altogether far too long.
* testsuite: strip windows line endings for haddockZubin Duggal2021-10-131-0/+0
| | | | | | | | | | | haddock: deterministic SCC Updates haddock submodule Metric Increase: haddock.Cabal haddock.base haddock.compiler
* testsuite: remove 'req_smp' from testwsdequeZubin Duggal2021-10-131-1/+0
|
* hadrian: avoid building check-{exact,ppr} and count-deps when the tests ↵Zubin Duggal2021-10-134-167/+185
| | | | | | don't need them hadrian: build optional dependencies with test compiler
* ci: test in-tree compiler in hadrianZubin Duggal2021-10-138-37/+52
|
* testsuite: Run haddock tests on out of tree compilerZubin Duggal2021-10-131-4/+4
|
* hadrian: Fix location for haddocks in installed pkgconfsZubin Duggal2021-10-131-1/+1
|
* hadrian, testsuite: Teach Hadrian to query the testsuite driver for dependenciesZubin Duggal2021-10-138-20/+96
| | | | Issues #19072, #17728, #20176
* ci: build validate-x86_64-linux-deb9-debug with hyperlinked source (#20067)Zubin Duggal2021-10-131-0/+1
|
* 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
|
View Lorry Controller Status