summaryrefslogtreecommitdiff
path: root/compiler/ghci
Commit message (Collapse)AuthorAgeFilesLines
* Ensure that coreView/tcView are able to inlineBen Gamari2019-11-131-1/+1
| | | | | | | | | | | | | | | | | | | | Previously an import cycle between Type and TyCoRep meant that several functions in TyCoRep ended up SOURCE import coreView. This is quite unfortunate as coreView is intended to be fused into a larger pattern match and not incur an extra call. Fix this with a bit of restructuring: * Move the functions in `TyCoRep` which depend upon things in `Type` into `Type` * Fold contents of `Kind` into `Type` and turn `Kind` into a simple wrapper re-exporting kind-ish things from `Type` * Clean up the redundant imports that popped up as a result Closes #17441. Metric Decrease: T4334
* Use the right type in :forceSimon Peyton Jones2019-11-091-3/+5
| | | | | | | | A missing prime meant that we were considering the wrong type in the GHCi debugger, when doing :force on multiple arguments (issue #17431). The fix is trivial.
* Remove redundant -fno-cse optionsÖmer Sinan Ağacan2019-10-261-2/+0
| | | | | These were probably added with some GLOBAL_VARs, but those GLOBAL_VARs are now gone.
* Make dynflag argument for withTiming pure.Andreas Klebinger2019-10-231-2/+2
| | | | | | | | | | | | 19 times out of 20 we already have dynflags in scope. We could just always use `return dflags`. But this is in fact not free. When looking at some STG code I noticed that we always allocate a closure for this expression in the heap. Clearly a waste in these cases. For the other cases we can either just modify the callsite to get dynflags or use the _D variants of withTiming I added which will use getDynFlags under the hood.
* Warn about missing profiled libs when using the Interpreter.Andreas Klebinger2019-10-231-1/+23
| | | | | | | | | | | | | | | When GHC itself, or it's interpreter is profiled we need to load profiled libraries as well. This requirement is not always obvious, especially when TH implicilty uses the interpreter. When the libs were not found we fall back to assuming the are in a DLL. This is usually not the case so now we warn users when we do so. This makes it more obvious what is happening and gives users a way to fix the issue. This fixes #17121.
* Clean up `#include`s in the compilerJohn Ericson2019-10-052-2/+1
| | | | | | | | - Remove unneeded ones - Use <..> for inter-package. Besides general clean up, helps distinguish between the RTS we link against vs the RTS we compile for.
* Refactor bad coercion checking in a few placesÖmer Sinan Ağacan2019-09-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We do bad coercion checking in a few places in the compiler, but they all checked it differently: - CoreToStg.coreToStgArgs: Disallowed lifted-to-unlifted, disallowed changing prim reps even when the sizes are the same. - StgCmmExpr.cgCase: Checked primRepSlot equality. This disallowed Int to Int64 coercions on 64-bit systems (and Int to Int32 on 32-bit) even though those are fine. - CoreLint: Only place where we do this right. Full rules are explained in Note [Bad unsafe coercion]. This patch implements the check explained in Note [Bad unsafe coercion] in CoreLint and uses it in CoreToStg.coreToStgArgs and StgCmmExpr.cgCase. This fixes #16952 and unblocks !1381 (which fixes #16893). This is the most conservative and correct change I came up with that fixes #16952. One remaining problem with coercion checking is that it's currently done in seemingly random places. What's special about CoreToStg.coreToStgArgs and StgCmmExpr.cgCase? My guess is that adding assertions to those places caught bugs before so we left assertions in those places. I think we should remove these assertions and do coercion checking in CoreLint and StgLint only (#17041).
* Module hierarchy: StgToCmm (#13009)Sylvain Henry2019-09-105-8/+8
| | | | | | Add StgToCmm module hierarchy. Platform modules that are used in several other places (NCG, LLVM codegen, Cmm transformations) are put into GHC.Platform.
* GHCi supports not-necessarily-lifted join pointsRichard Eisenberg2019-08-143-32/+117
| | | | | | | | | | | | | | | | Fixes #16509. See Note [Not-necessarily-lifted join points] in ByteCodeGen, which tells the full story. This commit also adds some comments and cleans some code in the byte-code generator, as I was exploring around trying to understand it. (This commit removes an old test -- this is really a GHCi problem, not a pattern-synonym problem.) test case: ghci/scripts/T16509
* Fix #8487: Debugger confuses variablesRoland Senn2019-07-212-4/+6
| | | | | | | | | | To display the free variables for a single breakpoint, GHCi pulls out the information from the fields `modBreaks_breakInfo` and `modBreaks_vars` of the `ModBreaks` data structure. For a specific breakpoint this gives 2 lists of types 'Id` (`Var`) and `OccName`. They are used to create the Id's for the free variables and must be kept in sync: If we remove an element from the Names list, then we also must remove the corresponding element from the OccNames list.
* ghci: Load static objects in batchesBen Gamari2019-06-231-13/+31
| | | | | | | | | | | | Previously in the case where GHC was dynamically linked we would load static objects one-by-one by linking each into its own shared object and dlopen'ing each in order. However, this meant that the link would fail in the event that the objects had cyclic symbol dependencies. Here we fix this by merging each "run" of static objects into a single shared object and loading this. Fixes #13786 for the case where GHC is dynamically linked.
* linker: Disable code unloadingBen Gamari2019-06-211-1/+5
| | | | | | | | | As noted in #16841, there are currently a variety of bugs in the unloading logic. These only affect Windows since code unloading is disabled on Linux, where we build with `GhcDynamic=YES` by default. In the interest of getting the tree green on Windows disable code unloading until the issues are resolved.
* Move 'Platform' to ghc-bootJohn Ericson2019-06-193-3/+3
| | | | | | | ghc-pkg needs to be aware of platforms so it can figure out which subdire within the user package db to use. This is admittedly roundabout, but maybe Cabal could use the same notion of a platform as GHC to good affect too.
* Maintain separate flags for C++ compiler invocationsBen Gamari2019-06-131-1/+1
| | | | | | | Previously we would pass flags intended for the C compiler to the C++ compiler (see #16738). This would cause, for instance, `-std=gnu99` to be passed to the C++ compiler, causing spurious test failures. Fix this by maintaining a separate set of flags for C++ compilation invocations.
* Use DeriveFunctor throughout the codebase (#15654)Krzysztof Gogolewski2019-06-122-8/+4
|
* Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETERAlp Mestanogullari2019-06-111-5/+5
| | | | | | | | | | | | | | | | | As discussed in #16331, the GHCI macro, defined through 'ghci' flags in ghc.cabal.in, ghc-bin.cabal.in and ghci.cabal.in, is supposed to indicate whether GHC is built with support for an internal interpreter, that runs in the same process. It is however overloaded in a few places to mean "there is an interpreter available", regardless of whether it's an internal or external interpreter. For the sake of clarity and with the hope of more easily being able to build stage 1 GHCs with external interpreter support, this patch splits the previous GHCI macro into 3 different ones: - HAVE_INTERNAL_INTERPRETER: GHC is built with an internal interpreter - HAVE_EXTERNAL_INTERPRETER: GHC is built with support for external interpreters - HAVE_INTERPRETER: HAVE_INTERNAL_INTERPRETER || HAVE_EXTERNAL_INTERPRETER
* Remove trailing whitespaceMatthew Pickering2019-06-081-1/+1
| | | | | | [skip ci] This should really be caught by the linters! (#16711)
* Fix space leaks in dynLoadObjs (#16708)Ryan Scott2019-05-311-7/+7
| | | | | | | | | | | When running the test suite on a GHC built with the `quick` build flavour, `-fghci-leak-check` noticed some space leaks. Careful investigation led to `Linker.dynLoadObjs` being the culprit. Pattern-matching on `PeristentLinkerState` and a dash of `$!` were sufficient to fix the issue. (ht to mpickering for his suggestions, which were crucial to discovering a fix) Fixes #16708.
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-1/+1
| | | | | | | | | | After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
* Allow for multiple linker instances. Fixes Haskell portion of #3372.Julian Leviston2019-05-213-95/+181
|
* Update a panic messageÖmer Sinan Ağacan2019-04-111-2/+2
| | | | Point users to the right URL
* Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)Michael Sloan2019-04-012-2/+1
| | | | Also removes a couple unnecessary MagicHash pragmas
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* Improve error recovery in the typecheckerSimon Peyton Jones2019-03-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #16418 showed that we were carrying on too eagerly after a bogus type signature was identified (a bad telescope in fact), leading to a subsequent crash. This led me in to a maze of twisty little passages in the typechecker's error recovery, and I ended up doing some refactoring in TcRnMonad. Some specfifics * TcRnMonad.try_m is now called attemptM. * I switched the order of the result pair in tryTc, to make it consistent with other similar functions. * The actual exception used in the Tc monad is irrelevant so, to avoid polluting type signatures, I made tcTryM, a simple wrapper around tryM, and used it. The more important changes are in * TcSimplify.captureTopConstraints, where we should have been calling simplifyTop rather than reportUnsolved, so that levity defaulting takes place properly. * TcUnify.emitResidualTvConstraint, where we need to set the correct status for a new implication constraint. (Previously we ended up with an Insoluble constraint wrapped in an Unsolved implication, which meant that insolubleWC gave the wrong answer.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-153-6/+6
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Remove the GHCi debugger's panicking isUnliftedType checkRyan Scott2019-03-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GHCi debugger has never been that robust in the face of higher-rank types, or even types that are _interally_ higher-rank, such as the types of many class methods (e.g., `fmap`). In GHC 8.2, however, things became even worse, as the debugger would start to _panic_ when a user tries passing the name of a higher-rank thing to `:print`. This all ties back to a strange `isUnliftedType` check in `Debugger` that was mysteriously added 11 years ago (in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no explanation whatsoever. After some experimentation, no one is quite sure what this `isUnliftedType` check is actually accomplishing. The test suite still passes if it's removed, and I am unable to observe any differences in debugger before even with data types that _do_ have fields of unlifted types (e.g., `data T = MkT Int#`). Given that this is actively causing problems (see #14828), the prudent thing to do seems to be just removing this `isUnliftedType` check, and waiting to see if anyone shouts about it. This patch accomplishes just that. Note that this patch fix the underlying issues behind #14828, as the debugger will still print unhelpful info if you try this: ``` λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f f = (_t1::t1) ``` But fixing this will require much more work, so let's start with the simple stuff for now.
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-232-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263
* Support printing `integer-simple` Integers in GHCiAlec Theriault2019-01-161-1/+31
| | | | | | | | | | This means that `:p` no longer leaks the implementation details of `Integer` with `integer-simple`. The `print037` test case should exercise all possible code paths for GHCi's code around printing `Integer`s (both in `integer-simple` and `integer-gmp`). `ghc` the package now also has a Cabal `integer-simple` flag (like the `integer-gmp` one).
* Check that libs found by GCC aren't foldersAlec Theriault2019-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We use 'gcc -B<base-location> --print-file-name mylib.a' as a way of checking if 'gcc' can discover 'mylib.a' at the given location. However, this can break down if there is a folder caller 'mylib.a' that 'gcc' can discover. We can guard against this by explicitly checking that the path returned by 'gcc' is a file. This may seem like a far-fetched scenario, but since 3d17f1f10fc00540ac052f2fd03182906aa47e35, we look for libraries without any prefix or suffix (ie. 'extra-libraries: softfloat', we look for just 'softfloat' as well as 'softloat.a', 'softfloat.dll.a', etc.) which means that there might actusally be a folder of that name in one of the base locations. Reviewers: Phyx, bgamari, hvr, angerman Reviewed By: Phyx, angerman Subscribers: angerman, rwbarton, carter GHC Trac Issues: #16063 Differential Revision: https://phabricator.haskell.org/D5462
* ghci: Fix unused binder warnings when building with integer-simpleBen Gamari2018-12-171-2/+0
|
* Merge sections in profiling .a to .p_o and use it whenever it existsZejun Wu2018-12-171-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We do this for vanilla way already. Let's also merge sections for profiling way and use it instead of the .a library when it exists. Test Plan: ``` $ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter GHCi, version 8.7.20180921: http://www.haskell.org/ghc/ :? for help Prelude> pid <- System.Posix.Process.getProcessID Prelude> maps <- readFile $ "/proc/" ++ show pid ++ "/maps" Prelude> pid 3807346 Prelude> putStrLn $ unlines $ take 20 $ lines maps 00400000-02103000 r-xp 00000000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02104000-02106000 r--p 01d03000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02106000-02417000 rw-p 01d05000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02417000-0280a000 rw-p 00000000 00:00 0 [heap] 40098000-400b0000 rwxp 000d2000 00:1a 199276023 /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o 400b7000-400d8000 rwxp 00000000 00:00 0 401d1000-401d2000 rwxp 000e9000 00:1a 199276023 /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o 40415000-40419000 rwxp 0000b000 00:1a 199275165 /data/users/watashi/ghc/libraries/deepseq/dist-install/build/HSdeepseq-1.4.4.0.p_o 404f8000-40526000 rwxp 000af000 00:1a 199274234 /data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o ``` Reviewers: simonmar, bgamari, austin, hvr Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5169
* RTS linker: don't crash early when not finding extra-librariesKyrill Briantsev2018-12-111-9/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow GHCi to not crash when no assumed DLL is found in the standard location. E.g. when loading the package built "dyn" way, we may well have the package's DLL around, and it's the system linker which loads necessary dependencies. Why does this (partially) fix #11042? It's because we often (and when having packages built `dyn` way -- almost always) don't need to load anything recorded in the `extra-libraries` stanza, since if the package DLL exists, GHCi linker simply calls the system linker (via `dlopen`/ `LoadLibrary` APIs) to load it and doesn't bother to load package prelinked object file (if any) or package static library. Thus, all "regular" (with no fancy low-level package content manipulation) packages built "dyn" way should be OK after this fix. Reviewers: hvr, bgamari, int-index Reviewed By: bgamari, int-index Subscribers: Phyx, int-index, rwbarton, carter GHC Trac Issues: #11042 Differential Revision: https://phabricator.haskell.org/D5170
* Fix #15953 by consistently using dumpIfSet_dyn to print debug outputChaitanya Koparkar2018-11-291-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In some modules we directly dump the debugging output to STDOUT via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file` is enabled, that output should be written to a file. Easily fixed. Certain tests (T3017, Roles3, T12763 etc.) expect part of the output generated by `-ddump-types` to be in 'PprUser' style. However, generally we want all other debugging output to use 'PprDump' style. `traceTcRn` and `traceTcRnForUser` help us accomplish this. This patch also documents some missing flags in the users guide. Reviewers: RyanGlScott, bgamari, hvr Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15953 Differential Revision: https://phabricator.haskell.org/D5382
* Fix unused-import warningsDavid Eichmann2018-11-222-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312
* Rename literal constructorsSylvain Henry2018-11-222-31/+31
| | | | | | | | | | | | | | | | | | | | | | | | In a previous patch we replaced some built-in literal constructors (MachInt, MachWord, etc.) with a single LitNumber constructor. In this patch we replace the `Mach` prefix of the remaining constructors with `Lit` for consistency (e.g., LitChar, LitLabel, etc.). Sadly the name `LitString` was already taken for a kind of FastString and it would become misleading to have both `LitStr` (literal constructor renamed after `MachStr`) and `LitString` (FastString variant). Hence this patch renames the FastString variant `PtrString` (which is more accurate) and the literal string constructor now uses the least surprising `LitString` name. Both `Literal` and `LitString/PtrString` have recently seen breaking changes so doing this kind of renaming now shouldn't harm much. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4881
* Add Int8# and Word8#Michal Terepeta2018-11-021-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step of implementing: https://github.com/ghc-proposals/ghc-proposals/pull/74 The main highlights/changes: primops.txt.pp gets two new sections for two new primitive types for signed and unsigned 8-bit integers (Int8# and Word8 respectively) along with basic arithmetic and comparison operations. PrimRep/RuntimeRep get two new constructors for them. All of the primops translate into the existing MachOPs. For CmmCalls the codegen will now zero-extend the values at call site (so that they can be moved to the right register) and then truncate them back their original width. x86 native codegen needed some updates, since it wasn't able to deal with the new widths, but all the changes are quite localized. LLVM backend seems to just work. This is the second attempt at merging this, after the first attempt in D4475 had to be backed out due to regressions on i386. Bumps binary submodule. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate (on both x86-{32,64}) Reviewers: bgamari, hvr, goldfire, simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5258
* Fix BLACKHOLE inspection in RtClosureInspectÖmer Sinan Ağacan2018-10-151-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | When inspecing a BLACKHOLE if the BLACKHOLE points to a TSO or a BLOCKING_QUEUE we should return a suspension to the BLACKHOLE itself (instead of returning a suspension to the indirectee). The reason is because in the debugger when we want to evaluate this term we need to enter the BLACKHOLE and not to the TSO or BLOCKING_QUEUE. See the runtime panic caused by this in #8316. Note that while with this patch we do the right thing to evaluate thunks in GHCi, evaluating thunks that are owned by the evaluator thread in a breakpoint will cause a deadlock as we don't release the breakMVar, which is what blocks the evaluator thread from continuing with evaluation. So the GHCi thread will enter the BLACKHOLE, but owner of the BLACKHOLE is also blocked. Reviewers: simonmar, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #8316 Differential Revision: https://phabricator.haskell.org/D5179
* Add RubbishLit for absent bindings of UnliftedRepSebastian Graf2018-10-142-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Trac #9279 reminded us that the worker wrapper transformation copes really badly with absent unlifted boxed bindings. As `Note [Absent errors]` in WwLib.hs points out, we can't just use `absentError` for unlifted bindings because there is no bottom to hide the error in. So instead, we synthesise a new `RubbishLit` of type `forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for any boxed value. We choose `()`, so that there is a good chance that the program crashes instead instead of leading to corrupt data, should absence analysis have been too optimistic (#11126). Reviewers: simonpj, hvr, goldfire, bgamari, simonmar Reviewed By: simonpj Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15627, #9279, #4306, #11126 Differential Revision: https://phabricator.haskell.org/D5153
* Revert "Add Int8# and Word8#"Ben Gamari2018-10-091-11/+6
| | | | | | | | | This unfortunately broke i386 support since it introduced references to byte-sized registers that don't exist on that architecture. Reverts binary submodule This reverts commit 5d5307f943d7581d7013ffe20af22233273fba06.
* Add Int8# and Word8#Michal Terepeta2018-10-071-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step of implementing: https://github.com/ghc-proposals/ghc-proposals/pull/74 The main highlights/changes: - `primops.txt.pp` gets two new sections for two new primitive types for signed and unsigned 8-bit integers (`Int8#` and `Word8` respectively) along with basic arithmetic and comparison operations. `PrimRep`/`RuntimeRep` get two new constructors for them. All of the primops translate into the existing `MachOP`s. - For `CmmCall`s the codegen will now zero-extend the values at call site (so that they can be moved to the right register) and then truncate them back their original width. - x86 native codegen needed some updates, since it wasn't able to deal with the new widths, but all the changes are quite localized. LLVM backend seems to just work. Bumps binary submodule. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate with new tests Reviewers: hvr, goldfire, bgamari, simonmar Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4475
* Coercion Quantificationningning2018-09-151-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corresponds to #15497. According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2, we would like to have coercion quantifications back. This will allow us to migrate (~#) to be homogeneous, instead of its current heterogeneous definition. This patch is (lots of) plumbing only. There should be no user-visible effects. An overview of changes: - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables, but only in *Core*. All relevant functions are updated accordingly. - Small changes that should be irrelevant to the main task: 1. removed dead code `mkTransAppCo` in Coercion 2. removed out-dated Note Computing a coercion kind and roles in Coercion 3. Added `Eq4` in Note Respecting definitional equality in TyCoRep, and updated `mkCastTy` accordingly. 4. Various updates and corrections of notes and typos. - Haddock submodule needs to be changed too. Acknowledgments: This work was completed mostly during Ningning Xie's Google Summer of Code, sponsored by Google. It was advised by Richard Eisenberg, supported by NSF grant 1704041. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar Subscribers: RyanGlScott, monoidal, rwbarton, carter GHC Trac Issues: #15497 Differential Revision: https://phabricator.haskell.org/D5054
* Remove knot-tying bug in TcHsSyn.zonkTyVarOccSimon Peyton Jones2018-08-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | There was a subtle knot-tying bug in TcHsSyn.zonkTyVarOcc, revealed in Trac #15552. I fixed it by * Eliminating the short-circuiting optimisation in zonkTyVarOcc, instead adding a finite map to get sharing of zonked unification variables. See Note [Sharing when zonking to Type] in TcHsSyn * On the way I /added/ the short-circuiting optimisation to TcMType.zonkTcTyVar, which has no such problem. This turned out (based on non-systematic measurements) to be a modest win. See Note [Sharing in zonking] in TcMType On the way I renamed some of the functions in TcHsSyn: * Ones ending in "X" (like zonkTcTypeToTypeX) take a ZonkEnv * Ones that do not end in "x" (like zonkTcTypeToType), don't. Instead they whiz up an empty ZonkEnv.
* Clean up TcHsSyn.zonkEnvSimon Peyton Jones2018-08-241-12/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn. This patch does some minor refactoring * Make ZonkEnv into a record with named fields, and use them. (I'm planning to add a new field, for TyCons, so this prepares the way.) * Replace UnboundTyVarZonker (a higer order function) with the simpler and more self-descriptive ZonkFlexi data type, below. It's just much more perspicuous and direct, and (I suspect) a tiny bit faster too -- no unknown function calls. data ZonkFlexi -- See Note [Un-unified unification variables] = DefaultFlexi -- Default unbound unificaiton variables to Any | SkolemiseFlexi -- Skolemise unbound unification variables -- See Note [Zonking the LHS of a RULE] | RuntimeUnkFlexi -- Used in the GHCi debugger There was one knock-on effect in the GHCi debugger -- the RuntimeUnkFlexi case. Somehow previously, these RuntimeUnk variables were sometimes getting SystemNames (and hence printed as 'a0', 'a1', etc) and sometimes not (and hence printed as 'a', 'b' etc). I'm not sure precisely why, but the new behaviour seems more uniform, so I just accepted the (small) renaming wibbles in some ghci.debugger tests. I had a quick look at perf: any changes are tiny.
* Turn on MonadFail desugaring by defaultHerbert Valerio Riedel2018-08-072-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This contains two commits: ---- Make GHC's code-base compatible w/ `MonadFail` There were a couple of use-sites which implicitly used pattern-matches in `do`-notation even though the underlying `Monad` didn't explicitly support `fail` This refactoring turns those use-sites into explicit case discrimations and adds an `MonadFail` instance for `UniqSM` (`UniqSM` was the worst offender so this has been postponed for a follow-up refactoring) --- Turn on MonadFail desugaring by default This finally implements the phase scheduled for GHC 8.6 according to https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy This also preserves some tests that assumed MonadFail desugaring to be active; all ghc boot libs were already made compatible with this `MonadFail` long ago, so no changes were needed there. Test Plan: Locally performed ./validate --fast Reviewers: bgamari, simonmar, jrtc27, RyanGlScott Reviewed By: bgamari Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D5028
* Stop the linker panicMoritz Angermann2018-08-061-25/+34
| | | | | | | | | | | | | | | | | | | | | | | If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012
* linker: Nub rpathsMoritz Angermann2018-08-011-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling and linking files in `ghci`, we keep adding rpath arguments to the linker command invoation. If those are identical we should `nub` them out. Otherwise we not only risk overflowing the argument limit, but also embed huge amounts of identical rpath values into the dynamic library, eventually leading to the overflow of the load command size limit, due to the number of rpath entries alone. A further improvement could be to pass `-Xlinker -dead_strip_dylibs`; that however might be stipping too aggressively, and potentially lead to missing symbols? For the time being I suggest to only do the nubbing and if need be to provide -Wl,-dead_strip_dylibs when invoking ghci. Test Plan: ./validate Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15446 Differential Revision: https://phabricator.haskell.org/D5021
* Fix endian issues in ghc-heapPeter Trommler2018-07-271-3/+6
| | | | | | | | | | | | | | | | | | | | | | In test heap_all arity and n_args were swapped on big endian systems. Take care of endianness when reading parts of a machine word from a `Word`. This fixes one out of 36 failing tests reported in #15399. Test Plan: validate Reviewers: simonmar, bgamari, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15399 Differential Revision: https://phabricator.haskell.org/D5001
* Support the GHCi debugger with -fexternal-interpreterSimon Marlow2018-07-163-61/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * All the tests in tests/ghci.debugger now pass with -fexternal-interpreter. These tests are now run with the ghci-ext way in addition to the normal way so we won't break it in the future. * I removed all the unsafeCoerce# calls from RtClosureInspect. Yay! The main changes are: * New messages: GetClosure and Seq. GetClosure is a remote interface to GHC.Exts.Heap.getClosureData, which required Binary instances for various datatypes. Fortunately this wasn't too painful thanks to DeriveGeneric. * No cheating by unsafeCoercing values when printing them. Now we have to turn the Closure representation back into the native representation when printing Int, Float, Double, Integer and Char. Of these, Integer was the most painful - we now have a dependency on integer-gmp due to needing access to the representation. * Fixed a bug in rts/Heap.c - it was bogusly returning stack content as pointers for an AP_STACK closure. Test Plan: * `cd testsuite/tests/ghci.debugger && make` * validate Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter GHC Trac Issues: #13184 Differential Revision: https://phabricator.haskell.org/D4955
* Fix space leaksSimon Marlow2018-07-161-14/+19
| | | | | | | | | | | | | | | | | | | | | Summary: All these were detected by -fghci-leak-check when GHC was compiled *without* optimisation (e.g. using the "quick" build flavour). Unfortunately I don't know of a good way to keep this working. I'd like to just disable the -fghci-leak-check flag when the compiler is built without optimisation, but it doesn't look like we have an easy way to do that. And even if we could, it would be fragile anyway, Test Plan: `cd testsuite/tests/ghci; make` Reviewers: bgamari, hvr, erikd, tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15246 Differential Revision: https://phabricator.haskell.org/D4872
* Fix nptr field alignment in RtClosureInspectÖmer Sinan Ağacan2018-07-041-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | `extractSubTerms` (which is extracting pointer and non-pointer fields of a closure) was computing the alignment incorrectly when aligning a 64-bit value (e.g. a Double) on i386 by aligning it to 64-bits instead of to word size (32-bits). This is documented in `mkVirtHeapOffsetsWithPadding`: > Align the start offset (eg, 2-byte value should be 2-byte aligned). > But not more than to a word. Fixes #15061 Test Plan: Validated on both 32-bit and 64-bit. 32-bit fails with various unrelated stat failures, but no actual test failures. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15061 Differential Revision: https://phabricator.haskell.org/D4906
View Lorry Controller Status