summaryrefslogtreecommitdiff
path: root/ghc
Commit message (Collapse)AuthorAgeFilesLines
* Module hierarchy: ByteCode and Runtime (cf #13009)Sylvain Henry2020-02-123-8/+8
| | | | Update haddock submodule
* Fix GhcThreaded settingBen Gamari2020-02-081-0/+6
| | | | | | | | | | | | | | This adopts a patch from NetBSD's packaging fixing the `GhcThreaded` option of the make build system. In addition we introduce a `ghcThreaded` option in hadrian's `Flavour` type. Also fix Hadrian's treatment of the `Use Threaded` entry in `settings`. Previously it would incorrectly claim `Use Threaded = True` if we were building the `threaded` runtime way. However, this is inconsistent with the `make` build system, which defines it to be whether the `ghc` executable is linked against the threaded runtime. Fixes #17692.
* compiler: Qualify imports of Data.ListBen Gamari2020-02-081-1/+1
|
* Introduce IsPass; refactor wrappers.Richard Eisenberg2020-02-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two main payloads of this patch: 1. This introduces IsPass, which allows e.g. printing code to ask what pass it is running in (Renamed vs Typechecked) and thus print extension fields. See Note [IsPass] in Hs.Extension 2. This moves the HsWrap constructor into an extension field, where it rightly belongs. This is done for HsExpr and HsCmd, but not for HsPat, which is left as an exercise for the reader. There is also some refactoring around SyntaxExprs, but this is really just incidental. This patch subsumes !1721 (sorry @chreekat). Along the way, there is a bit of refactoring in GHC.Hs.Extension, including the removal of NameOrRdrName in favor of NoGhcTc. This meant that we had no real need for GHC.Hs.PlaceHolder, so I got rid of it. Updates haddock submodule. ------------------------- Metric Decrease: haddock.compiler -------------------------
* Fix more typos, via an improved Levenshtein-style correctorBrian Wignall2020-01-122-4/+4
|
* Module hierarchy: Iface (cf #13009)Sylvain Henry2020-01-062-3/+3
|
* Remove HasSrcSpan (#17494)Vladislav Zavialov2019-11-301-7/+7
| | | | | Metric Decrease: haddock.compiler
* Fix typosBrian Wignall2019-11-231-1/+1
|
* Bump Haskeline and add exceptions as boot libraryBen Gamari2019-11-132-16/+49
| | | | Haskeline now depends upon exceptions. See #16752.
* Remove redundant -fno-cse optionsÖmer Sinan Ağacan2019-10-262-5/+1
| | | | | These were probably added with some GLOBAL_VARs, but those GLOBAL_VARs are now gone.
* Fix #14690 - :steplocal panics after break-on-errorRoland Senn2019-10-261-0/+4
| | | | | | | | | | | | | | `:steplocal` enables only breakpoints in the current top-level binding. When a normal breakpoint is hit, then the module name and the break id from the `BRK_FUN` byte code allow us to access the corresponding entry in a ModBreak table. From this entry we then get the SrcSpan (see compiler/main/InteractiveEval.hs:bindLocalsAtBreakpoint). With this source-span we can then determine the current top-level binding, needed for the steplocal command. However, if we break at an exception or at an error, we don't have an BRK_FUN byte-code, so we don't have any source information. The function `bindLocalsAtBreakpoint` creates an `UnhelpfulSpan`, which doesn't allow us to determine the current top-level binding. To avoid a `panic`, we have to check for `UnhelpfulSpan` in the function `ghc/GHCi/UI.hs:stepLocalCmd`. Hence a :steplocal command after a break-on-exception or a break-on-error is not possible.
* Allow command name resolution for GHCi commands with option `!` #17345Takenobu Tani2019-10-231-5/+14
| | | | | | | | | | | | | | | | | | | | This commit allows command name resolution for GHCi commands with option `!` as follows: ghci> :k! Int Int :: * = Int This commit changes implementation as follows: Before: * Prefix match with full string including the option `!` (e.g. `k!`) After (this patch): * Prefix match without option suffix `!` (e.g. `k`) * in addition, suffix match with option `!` See also #8305 and #8113
* Compiling with -S and -fno-code no longer panics (fixes #17143)adithyaov2019-10-161-0/+4
|
* Add GHCi help message for :def! and :: commandsTakenobu Tani2019-10-131-1/+3
|
* Refactor, document, and optimize LLVM configuration loadingBen Gamari2019-10-071-6/+2
| | | | | | | | | | | | As described in the new Note [LLVM Configuration] in SysTools, we now load llvm-targets and llvm-passes lazily to avoid the overhead of doing so when -fllvm isn't used (also known as "the common case"). Noticed in #17003. Metric Decrease: T12234 T12150
* Always enable the external interpreterJohn Ericson2019-10-042-25/+31
| | | | | | You can always just not use or even build `iserv`. I don't think the maintenance cost of the CPP is worth...I can't even tell what the benefit is.
* Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.hJohn Ericson2019-10-041-5/+0
| | | | | | | | | | | | | | | | | | The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
* Add help message for GHCi :instances commandTakenobu Tani2019-09-301-0/+1
| | | | This commit updates GHCi's help message for GHC 8.10.
* Refactor iface file generation:Ömer Sinan Ağacan2019-09-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit refactors interface file generation to allow information from the later passed (NCG, STG) to be stored in interface files. We achieve this by splitting interface file generation into two parts: * Partial interfaces, built based on the result of the core pipeline * A fully instantiated interface, which also contains the final fingerprints and can optionally contain information produced by the backend. This change is required by !1304 and !1530. -dynamic-too handling is refactored too: previously when generating code we'd branch on -dynamic-too *before* code generation, but now we do it after. (Original code written by @AndreasK in !1530) Performance ~~~~~~~~~~~ Before this patch interface files where created and immediately flushed to disk which made space leaks impossible. With this change we instead use NFData to force all iface related data structures to avoid space leaks. In the process of refactoring it was discovered that the code in the ToIface Module allocated a lot of thunks which were immediately forced when writing/forcing the interface file. So we made this module more strict to avoid creating many of those thunks. Bottom line is that allocations go down by about ~0.1% compared to master. Residency is not meaningfully different after this patch. Runtime was not benchmarked. Co-Authored-By: Andreas Klebinger <klebinger.andreas@gmx.at> Co-Authored-By: Ömer Sinan Ağacan <omer@well-typed.com>
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-202-4/+4
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* Use lazyness for FastString's z-encoding memoizationDaniel Gröber2019-09-091-1/+1
| | | | | | | | | | | | | | | | | | | Having an IORef in FastString to memoize the z-encoded version is unecessary because there is this amazing thing Haskell can do natively, it's called "lazyness" :) We simply remove the UNPACK and strictness annotations from the constructor field corresponding to the z-encoding, making it lazy, and store the (pure) z-encoded string there. The only complication here is 'hasZEncoding' which allows cheking if a z-encoding was computed for a given string. Since this is only used for compiler performance statistics though it's not actually necessary to have the current per-string granularity. Instead I add a global IORef counter to the FastStringTable and use unsafePerformIO to increment the counter whenever a lazy z-encoding is forced.
* Use an empty data type in TTG extension constructors (#15247)Ryan Scott2019-07-091-3/+3
| | | | | | | | | | | | | | | To avoid having to `panic` any time a TTG extension constructor is consumed, this MR introduces an uninhabited 'NoExtCon' type and uses that in every extension constructor's type family instance where it is appropriate. This also introduces a 'noExtCon' function which eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates a 'Void'. I also renamed the existing `NoExt` type to `NoExtField` to better distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of code churn resulting from this. Bumps the Haddock submodule. Fixes #15247.
* Fix stage 1 warningsÖmer Sinan Ağacan2019-07-021-1/+4
|
* ghci: Don't rely on resolution of System.IO to base moduleBen Gamari2019-06-221-14/+25
| | | | | | | | | Previously we would hackily evaluate a textual code snippet to compute actions to disable I/O buffering and flush the stdout/stderr handles. This broke in a number of ways (#15336, #16563). Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing the needed actions. We can then easily refer to these via `Orig` names.
* Move 'Platform' to ghc-bootJohn Ericson2019-06-191-1/+1
| | | | | | | 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.
* Fix #1620: ModBreaks.modBreaks_array not initialisedRoland Senn2019-06-191-7/+11
| | | | | | | | | After a :cd command and after setting some package flags, GHCi unloads all loaded modules by resetting the list of targets. This patch deletes eventually defined debugger breakpoints, before GHCi resets the target list. The common code is factored out into the new function clearAllTargets.
* Use DeriveFunctor throughout the codebase (#15654)Krzysztof Gogolewski2019-06-121-4/+2
|
* Refine the GHCI macro into HAVE[_{INTERNAL, EXTERNAL}]_INTERPRETERAlp Mestanogullari2019-06-112-7/+18
| | | | | | | | | | | | | | | | | 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
* Add disable/enable commands to ghci debugger #2215Roland Senn2019-06-092-32/+101
| | | | | | | | | | | | | | | | | | | | This patch adds two new commands `:enable` and `:disable` to the GHCi debugger. Opposite to `:set stop <n> :continue` a breakpoint disabled with `:disable` will not loose its previously set stop command. A new field breakEnabled is added to the BreakLocation data structure to track the enable/disable state. When a breakpoint is disabled with a `:disable` command, the following happens: The corresponding BreakLocation data element is searched dictionary of the `breaks` field of the GHCiStateMonad. If the break point is found and not already in the disabled state, the breakpoint is removed from bytecode. The BreakLocation data structure is kept in the breaks list and the new breakEnabled field is set to false. The `:enable` command works similar. The breaks field in the GHCiStateMonad was changed from an association list to int `IntMap`.
* Fix #16700: Tiny errors in output of GHCi commands :forward and :infoRoland Senn2019-06-071-1/+1
| | | | | | `:info Coercible` now outputs the correct section number of the GHCi User's guide together with the secion title. `:forward x` gives the correct syntax hint.
* make: Fix bindist installationBen Gamari2019-06-041-5/+2
| | | | | This fixes a few vestigial references to `settings` left over from !655. Fixes #16715.
* Add GHCi :instances commandXavier Denis2019-06-041-1/+15
| | | | | | | | | | | This commit adds the `:instances` command to ghci following proosal number 41. This makes it possible to query which instances are available to a given type. The output of this command is all the possible instances with type variables and constraints instantiated.
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-2/+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-211-2/+4
|
* Fix bugs and documentation for #13456Roland Senn2019-05-101-29/+37
|
* Implement ImportQualifiedPostShayne Fletcher2019-05-081-1/+1
|
* Generate settings by make/hadrian instead of configureJohn Ericson2019-04-301-0/+3
| | | | This allows it to eventually become stage-specific
* Correct off by one error in ghci +cMatthew Pickering2019-04-222-2/+9
| | | | Fixes #16569
* GHCi: add 'local-config' settingFraser Tweedale2019-04-151-2/+16
| | | | | | | | | | | | Add the ':set local-config { source | ignore }' setting to control whether .ghci file in current directory will be sourced or not. The directive can be set in global config or $HOME/.ghci, which are processed before local .ghci files. The default is "source", preserving current behaviour. Related: https://gitlab.haskell.org/ghc/ghc/issues/6017 Related: https://gitlab.haskell.org/ghc/ghc/issues/14250
* GHCi: fix load order of .ghci filesFraser Tweedale2019-04-152-9/+46
| | | | | | | | | | | | | | | Directives in .ghci files in the current directory ("local .ghci") can be overridden by global files. Change the order in which the configs are loaded: global and $HOME/.ghci first, then local. Also introduce a new field to GHCiState to control whether local .ghci gets sourced or ignored. This commit does not add a way to set this value (a subsequent commit will add this), but the .ghci sourcing routine respects its value. Fixes: https://gitlab.haskell.org/ghc/ghc/issues/14689 Related: https://gitlab.haskell.org/ghc/ghc/issues/6017 Related: https://gitlab.haskell.org/ghc/ghc/issues/14250
* Use ghc-prim < 0.7, not <= 0.6.1, as upper version boundsRyan Scott2019-04-091-1/+1
| | | | | | | Using `ghc-prim <= 0.6.1` is somewhat dodgy from a PVP point of view, as it makes it awkward to support new minor releases of `ghc-prim`. Let's instead use `< 0.7`, which is the idiomatic way of expressing PVP-compliant upper version bounds.
* Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)Michael Sloan2019-04-011-1/+1
| | | | Also removes a couple unnecessary MagicHash pragmas
* Bump ghc-prim's version where neededAlexandre2019-04-011-1/+1
|
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-252-4/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-03-221-1/+0
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Extract out use of UnboxedTuples from GHCi.LeakMichael Sloan2019-03-173-5/+20
| | | | | | See #13101 + #15454 for motivation. This change reduces the number of modules that need to be compiled to object code when loading GHC into GHCi.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-152-7/+7
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Fix #16392: revertCAFs in external interpreter when necessaryPhuong Trinh2019-03-071-3/+2
| | | | | | | | | We revert CAFs when loading/adding modules in ghci (presumably to refresh execution states and to allow for object code to be unloaded from the runtime). However, with `-fexternal-interpreter` enabled, we are only doing it in the ghci process instead of the external interpreter process where the cafs are allocated and computed. This makes sure that revertCAFs is done in the appropriate process no matter if that flag is present or not.
* Move reifyGHCi function into GhciMonad type classZejun Wu2019-03-061-13/+3
| | | | This was the suggested change in !176 but missed the batch merge (!263).
* Rip out object splittingBen Gamari2019-03-051-6/+0
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
View Lorry Controller Status