summaryrefslogtreecommitdiff
path: root/compiler/main
Commit message (Collapse)AuthorAgeFilesLines
* Enable external interpreter when TH is requested but no internal interpreter ↵cherry-pick-e172a6d1Alp Mestanogullari2019-06-031-2/+9
| | | | | is available (cherry picked from commit e172a6d127a65b945b31306ff7b6c43320debfb4)
* base: Remove `Monad(fail)` method and reexport `MonadFail(fail)` insteadHerbert Valerio Riedel2019-04-051-6/+6
| | | | | | As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail Coauthored-by: Ben Gamari <ben@well-typed.com>
* Fix #16219: TemplateHaskell causes indefinite package build errorcherry-pick-d6d735c1Edward Z. Yang2019-04-012-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | It should work to write an indefinite package using TemplateHaskell, so long as all of the actual TH code lives outside of the package. However, cleverness we had to build TH code even when building with -fno-code meant that we attempted to build object code for modules in an indefinite package, even when the signatures were not instantiated. This patch disables said logic in the event that an indefinite package is being typechecked. Signed-off-by: Edward Z. Yang <ezyang@fb.com> Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #16219 Differential Revision: https://phabricator.haskell.org/D5475 (cherry picked from commit d6d735c1114082b9e9cc1ba7da87c49f52891320)
* HIE: Save module name and module exportsMatthew Pickering2019-02-201-2/+3
| | | | (cherry picked from commit 69ebf5cb4592b4c89e268937ef7eb96f7c9d4532)
* GhcPlugins: Fix lookup of TH namesBen Gamari2019-02-201-3/+3
| | | | | | | | | | | Previously `thNameToGhcName` was calling `lookupOrigNameCache` directly, which failed to handle the case that the name wasn't already in the name cache. This happens, for instance, when the name was in scope in a plugin being used during compilation but not in scope in the module being compiled. In this case we the interface file containing the name won't be loaded and `lookupOrigNameCache` fails. This was the cause of #16104. The solution is simple: use the nicely packaged `lookupOrigIO` instead.
* A few typofixesGabor Greif2019-02-201-1/+1
|
* Add support for ASM foreign files (.s) in TH (#16180)Sylvain Henry2019-02-201-4/+5
|
* Prepare source-tree for base-4.13 MFP bumpHerbert Valerio Riedel2019-01-181-1/+1
|
* Change comments as requested by code review. #10857Roland Senn2019-01-161-1/+1
|
* GHCi ignores cmd line flags XMonomorphismRestr.. XNoExtendedDef..#10857Roland Senn2019-01-161-0/+17
|
* Refactor GHCi UI to fix #11606, #12091, #15721, #16096Ömer Sinan Ağacan2019-01-134-26/+62
| | | | | | | | | | | | | Instead of parsing and executing a statement or declaration directly we now parse them first and then execute in a separate step. This gives us the flexibility to inspect the parsed declaration before execution. Using this we now inspect parsed declarations, and if it's a single declaration of form `x = y` we execute it as `let x = y` instead, fixing a ton of problems caused by poor declaration support in GHCi. To avoid any users of the modules I left `execStmt` and `runDecls` unchanged and added `execStmt'` and `runDecls'` which work on parsed statements/declarations.
* Add -Wmissing-deriving-strategieschessai2019-01-061-0/+2
| | | | | | | | | | | | | | | Warn users when -XDerivingStrategies is enabled but not used, at each potential use site. add -Wmissing-deriving-strategies Reviewers: bgamari, RyanGlScott Subscribers: andrewthad, rwbarton, carter GHC Trac Issues: #15798 Differential Revision: https://phabricator.haskell.org/D5451
* Dump Cmm with -ddump-cmm when building .cmm filesÖmer Sinan Ağacan2019-01-051-0/+1
| | | | Fixes #16131
* Remove an old OPTIONS_GHCÖmer Sinan Ağacan2018-12-201-4/+0
|
* Fix recompilation checking of pure pluginsDaniel Gröber2018-12-121-0/+7
| | | | | | | | | | | | | | | | | | | Previously when switching from using a Plugin with `RecompMaybe`/`ForceRecompile` in `pluginRecompile` to a Plugin with `NoForceRecompile` GHC would never even consider recompiling. However the previously active plugin could have modified the compilation output so we should recompile. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15858 Differential Revision: https://phabricator.haskell.org/D5299
* Explicitly pass -fno-PIC to C compiler on linuxZejun Wu2018-12-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent gcc on some linux ditributions may have -fPIC on by default ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations ``` This results in following error for i686: ``` $ TEST=T13366 make test ... c-iserv.bin: /home/watashi/github/ghc/libraries/ghc-prim/dist-install/build/HSghc-pri m-0.5.3.o: unknown symbol `_GLOBAL_OFFSET_TABLE_' ghc-stage2: unable to load package `ghc-prim-0.5.3' ... ``` As our runtime linker doesn't support R_386_GOTPC relocations at all (#15847). Also while we don't have such problem on x86_64, it's not desired to build PIC objects either. Test Plan: `TEST=T13366 make test` passed on {rGHC82a716431cc680392e332bc2b1a1fd0d7faa4cd8} Reviewers: simonmar, bgamari, austin Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15848 Differential Revision: https://phabricator.haskell.org/D5288
* Support generating HIE filesAlec Theriault2018-12-116-34/+134
| | | | | | | | | | | | | | | | | | | | Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie` files (see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles). This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for his GSOC project, as posted here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d. Test Plan: ./validate Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi Reviewed By: alanz, sjakobi Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter Differential Revision: https://phabricator.haskell.org/D5239
* RTS linker: don't crash early when not finding extra-librariesKyrill Briantsev2018-12-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support registering Plugins through the GHC APIDaniel Gröber2018-12-114-22/+56
| | | | | | | | | | | | | | | | | This allows tooling using the GHC API to use plugins internally. Hopefully this will make it possible to decouple the development of useful plugins from (currently) kitchen-sink type tooling projects such as ghc-mod or HIE -- at least to some extent. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, alanz, rwbarton, carter GHC Trac Issues: #15826 Differential Revision: https://phabricator.haskell.org/D5278
* Use --no-as-needed with LLD tooSimon Marlow2018-12-071-1/+3
| | | | | | | | | | | | Test Plan: validate using LLD as the linker (TODO) Reviewers: bgamari, angerman, kavon, erikd Reviewed By: bgamari Subscribers: watashi, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5336
* Add -fno-safe-haskell flagMatthew Pickering2018-12-073-5/+18
| | | | | | | | | | | | | | | | | This flag can be set to turn off the Safe Haskell checks. Whether a module is marked Safe/Unsafe/Trustworthy is ignored when this flag to set. Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter GHC Trac Issues: #15920 Differential Revision: https://phabricator.haskell.org/D5360
* Fix StgLint bound id check, generalize StgLintÖmer Sinan Ağacan2018-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | StgLint was incorrectly using isLocalId for bound id check to see whether an id is imported (in which case we don't expect it to be bound) or local. The problem with isLocalId is that its semantics changes after Core, as explained in the note: (last line) Note [GlobalId/LocalId] ~~~~~~~~~~~~~~~~~~~~~~~ A GlobalId is * always a constant (top-level) * imported, or data constructor, or primop, or record selector * has a Unique that is globally unique across the whole GHC invocation (a single invocation may compile multiple modules) * never treated as a candidate by the free-variable finder; it's a constant! A LocalId is * bound within an expression (lambda, case, local let(rec)) * or defined at top level in the module being compiled * always treated as a candidate by the free-variable finder After CoreTidy, top-level LocalIds are turned into GlobalIds We now pass current module as a parameter to StgLint, which uses it to see if an id should be bound (defined in the current module) or not (imported). Other changes: - Generalized StgLint to make it work on both StgTopBinding and CgStgTopBinding. - Bring all top-level binders into scope before linting top-level bindings to allow uses before definitions. TODO: We should remove the binder from local vars when checking RHSs of non-recursive bindings. Test Plan: This validates. Reviewers: simonpj, bgamari, sgraf Reviewed By: simonpj, sgraf Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5370
* Rename "changed" to "no-change" in HscMainÖmer Sinan Ağacan2018-12-071-8/+8
| | | | | | | | | | | | | | | | | hscSimpleIface is returning a bool for whether there were _no changes_ in the iface file. The same bool is called "no_change_at_all" in mkIface_, and "no_change" in hscWriteIface and other functions. However it is called "changed" in HscMain.finish and hscMaybeWriteIface, which is confusing because "changed" and "no_change" have opposite meanings. This patch renames "changed" to "no_change" to fix this. Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5416
* Windows: Use the "big" PE object format on amd64Ben Gamari2018-12-061-1/+37
| | | | | | | | | | | | | | Test Plan: Do full build on Windows. Reviewers: AndreasK, Phyx Reviewed By: AndreasK Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15934 Differential Revision: https://phabricator.haskell.org/D5383
* Fix #15953 by consistently using dumpIfSet_dyn to print debug outputChaitanya Koparkar2018-11-294-24/+32
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Print explicit foralls in type family eqns when appropriateRyan Scott2018-11-261-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When `-fprint-explicit-foralls` is enabled, type family equations are either printed without an explict `forall` entirely, or with a bizarre square bracket syntax (in the case of closed type families). I find neither satisfying, so in this patch, I introduce support for printing explicit `forall`s in open type-family, closed type-family, and data-family equations when appropriate. (By "when appropriate", I refer to the conditions laid out in `Note [When to print foralls]` in `IfaceType`.) One tricky point in the implementation is that I had to pick a visibility for each type variable in a `CoAxiom`/`FamInst` in order to be able to pass it to `pprUserIfaceForAll` //et al.// Because the type variables in a type family instance equation can't be instantiated by the programmer anyway, the choice only really matters for pretty-printing purposes, so I simply went with good ol' trustworthy `Specified`. (This design choice is documented in `Note [Printing foralls in type family instances]` in `IfaceType`.) Test Plan: make test TEST=T15827 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15827 Differential Revision: https://phabricator.haskell.org/D5282
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-244-65/+82
| | | | | | | | | | | | | | | | | | This patch removes the ping-pong style from HsPat (only, for now), using the plan laid out at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations (solution A). - the class `HasSrcSpan`, and its functions (e.g., `cL` and `dL`), are introduced - some instances of `HasSrcSpan` are introduced - some constructors `L` are replaced with `cL` - some patterns `L` are replaced with `dL->L` view pattern - some type annotation are necessarily updated (e.g., `Pat p` --> `Pat (GhcPass p)`) Phab diff: D5036 Trac Issues #15495 Updates haddock submodule
* Implement late lambda liftSebastian Graf2018-11-231-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements a selective lambda-lifting pass late in the STG pipeline. Lambda lifting has the effect of avoiding closure allocation at the cost of having to make former free vars available at call sites, possibly enlarging closures surrounding call sites in turn. We identify beneficial cases by means of an analysis that estimates closure growth. There's a Wiki page at https://ghc.haskell.org/trac/ghc/wiki/LateLamLift. Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #9476 Differential Revision: https://phabricator.haskell.org/D5224
* Fix unused-import warningsDavid Eichmann2018-11-228-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't pass -no-pie when -pgmc is suppliedKrzysztof Gogolewski2018-11-221-1/+4
| | | | | | | | | | | | | | Test Plan: validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15319 Differential Revision: https://phabricator.haskell.org/D5317
* Calling gcc: Pass optc flags as last options (#14452)Roland Senn2018-11-221-1/+3
| | | | | | | | | | | | | | Test Plan: make test TEST=T14452 Reviewers: hvr, bgamari, monoidal, thomie, osa1 Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #14452 Differential Revision: https://phabricator.haskell.org/D5318
* Rename literal constructorsSylvain Henry2018-11-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't track free variables in STG syntax by defaultSebastian Graf2018-11-192-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non-global free variables. This free variable information is only needed in the final code generation step (i.e. `StgCmm.codeGen`), which leads to transformations such as `StgCse` and `StgUnarise` having to maintain this information. This is tiresome and unnecessary, so this patch introduces a trees-to-grow-like approach that only introduces the free variable set into the syntax tree in the code gen pass, along with a free variable analysis on STG terms to generate that information. Fixes #15754. Reviewers: simonpj, osa1, bgamari, simonmar Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #15754 Differential Revision: https://phabricator.haskell.org/D5324
* Building GHC with hadrian on FreeBSDKrzysztof Gogolewski2018-11-171-2/+2
| | | | | | | | | | | | | | | Summary: I'm currently trying to make `hadrian` work as a build system on FreeBSD (https://ghc.haskell.org/trac/ghc/ticket/15860). I'm still having some issues with `libgmp` but one can get a working `ghc` using `--integer-simple` and this patch. Reviewers: bgamari, erikd, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5335
* NCG: New code layout algorithm.Andreas Klebinger2018-11-171-5/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a new code layout algorithm. It has been tested for x86 and is disabled on other platforms. Performance varies slightly be CPU/Machine but in general seems to be better by around 2%. Nofib shows only small differences of about +/- ~0.5% overall depending on flags/machine performance in other benchmarks improved significantly. Other benchmarks includes at least the benchmarks of: aeson, vector, megaparsec, attoparsec, containers, text and xeno. While the magnitude of gains differed three different CPUs where tested with all getting faster although to differing degrees. I tested: Sandy Bridge(Xeon), Haswell, Skylake * Library benchmark results summarized: * containers: ~1.5% faster * aeson: ~2% faster * megaparsec: ~2-5% faster * xml library benchmarks: 0.2%-1.1% faster * vector-benchmarks: 1-4% faster * text: 5.5% faster On average GHC compile times go down, as GHC compiled with the new layout is faster than the overhead introduced by using the new layout algorithm, Things this patch does: * Move code responsilbe for block layout in it's own module. * Move the NcgImpl Class into the NCGMonad module. * Extract a control flow graph from the input cmm. * Update this cfg to keep it in sync with changes during asm codegen. This has been tested on x64 but should work on x86. Other platforms still use the old codelayout. * Assign weights to the edges in the CFG based on type and limited static analysis which are then used for block layout. * Once we have the final code layout eliminate some redundant jumps. In particular turn a sequences of: jne .foo jmp .bar foo: into je bar foo: .. Test Plan: ci Reviewers: bgamari, jmct, jrtc27, simonmar, simonpj, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, trommler, jmct, carter, thomie, rwbarton GHC Trac Issues: #15124 Differential Revision: https://phabricator.haskell.org/D4726
* compareByPreference: handle the integer-gmp vs -simple caseAlp Mestanogullari2018-11-121-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it assumes the package names are identical and this breaks in the case where integer-gmp is in one package db and integer-simple in another. This became a problem with the commit: fc2ff6dd7496a33bf68165b28f37f40b7d647418. Instead of following the precedence information, leading to the right choice, the current code would compare the integer-gmp and integer-simple versions and pick integer-gmp because it happened to have a greater version, despite having a lower precedence. See https://github.com/snowleopard/hadrian/issues/702 for a comprehensive report about the problem. This effectively un-breaks integer-simple builds with hadrian. Test Plan: hadrian/build.sh --integer-simple Reviewers: snowleopard, bgamari Reviewed By: bgamari Subscribers: snowleopard, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5266
* Revert "Remove kind generalisation from tcRnType"Richard Eisenberg2018-10-291-2/+1
| | | | | | | | | This reverts commit 3a51abd04432ea3d13e4ea3c5a592f038bd57432. I had hit the wrong button when trying to validate the original commit... and ended up committing it prematurely instead. This reversion commit also updates the comments to explain why we kind-generalise.
* Finish fix for #14880.Tobias Dammers2018-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591
* Plugins: Add documentation and missing exportsBen Gamari2018-10-281-4/+32
| | | | | | | | | | | | | | Summary: Previously the TcPlugin and CorePlugin type synonyms were not exporting, resulting in much confusion. Reviewers: mpickering Reviewed By: mpickering Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5237
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-272-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894
* Surprising error message with bang patternSasa Bogicevic2018-10-151-1/+4
| | | | | | | | | | | | Reviewers: bgamari, alanz Reviewed By: bgamari Subscribers: sgraf, mpickering, rwbarton, thomie, carter GHC Trac Issues: #13600 Differential Revision: https://phabricator.haskell.org/D5040
* Deprecate -fllvm-pass-vectors-in-regsBen Gamari2018-10-151-5/+4
| | | | | | | | | | | | Summary: The behavior previously enabled by this flag is as been the default since 8.6.1. Reviewers: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5193
* Fix typo in documentationJan Path2018-10-141-1/+1
| | | | PR: https://github.com/ghc/ghc/pull/201/
* Include -fwarn-star-is-type in -WcompatVladislav Zavialov2018-10-121-0/+1
| | | | | | | | | | | | | | | | | According to the deprecation schedule in the accepted proposal, the first step is to include `-fwarn-star-is-type` in `-Wcompat`. Test Plan: Validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15476 Differential Revision: https://phabricator.haskell.org/D5044
* Support builtin classes like KnownNat in backpackPiyush P Kurur2018-10-112-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit allows backpack signatures to enforce constraints like KnownNat on data types. Thus it fixes #15379. There were two important differences in the way GHC used to handle classes like KnowNat 1. Hand crafted instances of `KnownNat` were forbidden, and 2. The dictionary for an instance `KnownNat T` was generated on the fly. For supporting backpack both these points have to be revisited. Disallowing instances of KnownNat -------------------------------------------- Users were disallowed to declare instances of certain builtin classes like KnownNat for obvious safety reasons --- when we use the constraint like `KnownNat T`, we want T to be associated to a natural number. However, due to the reuse of this code while processing backpack signatures, `instance KnownNat T` were being disallowed even in module signature files. There is an important difference when it comes to instance declarations in a signature file. Consider the signature `Abstract` given below ``` signature Abstract where data T :: Nat instance KnownNat T ``` Inside a signature like `Abstract`, the `instance Known T` is not really creating an instance but rather demanding any module that implements this signature to enforce the constraint `KnownNat` on its type T. While hand crafted KnownNat instances continued to be prohibited in modules, this commit ensures that it is not forbidden while handling signatures. Resolving Dictionaries ---------------------------- Normally GHC expects any instance `T` of class `KnownNat` to eventually resolve to an integer and hence used to generate the evidence/dictionary for such instances on the fly as in when it is required. However, when backpack module and signatures are involved It is not always possible to resolve the type to a concrete integer utill the mixin stage. To illustrate consider again the signature `Abstract` > signature Abstract where > data T :: Nat > instance KnownNat T and a module `Util` that depends on it: > module Util where > import Abstract > printT :: IO () > printT = do print $ natVal (Proxy :: Proxy T) Clearly, we need to "use" the dictionary associated with `KnownNat T` in the module `Util`, but it is too early for the compiler to produce a real dictionary as we still have not fixed what `T` is. Only when we mixin a concrete module > module Concrete where > type T = 42 do we really get hold of the underlying integer. In this commit, we make the following changes in the resolution of instance dictionary for constraints like `KnownNat T` 1. If T is indeed available as a type alias for an integer constant, generate the dictionary on the fly as before, failing which 2. Do not give up as before but look up the type class environment for the evidence. This was enough to make the resolution of `KnownNat` dictionaries work in the setting of Backpack as when actual code is generated, the signature Abstract (due to the `import Abstract` ) in `Util` gets replaced by an actual module like Concrete, and resolution happens as before. Everything that we said for `KnownNat` is applicable for `KnownSymbol` as well. Reviewers: bgamari, ezyang, goldfire, simonpj Reviewed By: simonpj Subscribers: simonpj, ezyang, rwbarton, thomie, carter GHC Trac Issues: #15379 Differential Revision: https://phabricator.haskell.org/D4988
* Make GHC (the library) flexible in the choice of integer libraryJoachim Breitner2018-10-032-21/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We have more and more users of GHC as a library, for example the Haskell-to-WebAssembly-compiler https://github.com/tweag/asterius. These need to make different decisions about various aspects of code generation than the host compiler, and ideally GHC-the-library allows them to set the `DynFlags` as needed. This patch adds a new `DynFlag` that configures which `integer` library to use. This flag is initialized by `cIntegerLibraryType` (as before), and is only used in `CorePrep` to decide whether to use `S#` or not. The other code paths that were varying based on `cIntegerLibraryType` are no now longer varying: The trick is to use `integer-wired-in` as the `-this-unit-id` when compiling either `integer-gmp` or `integer-simple`. Test Plan: Validate is happy. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: TerrorJack, adamse, simonpj, rwbarton, carter GHC Trac Issues: #13477 Differential Revision: https://phabricator.haskell.org/D5079
* Drop GHC 8.2 compatibilityRyan Scott2018-10-032-100/+0
| | | | | | | | | | | | | | | | | Summary: GHC 8.6.1 is out, so now GHC's support window only extends back to GHC 8.4. This means we can delete gobs of code that were only used for GHC 8.2 support. Hooray! Test Plan: ./validate Reviewers: bgamari, Phyx, erikd Reviewed By: bgamari, Phyx Subscribers: rwbarton, erikd, carter Differential Revision: https://phabricator.haskell.org/D5192
* GHCi should not filter instances involving cTuplesAlec Theriault2018-10-021-0/+2
| | | | | | | | | | | | | | | | Summary: See the new T12005 test case for an example of this. Test Plan: make TEST=T12005 Reviewers: bgamari, osa1 Reviewed By: osa1 Subscribers: osa1, rwbarton, carter GHC Trac Issues: #12005 Differential Revision: https://phabricator.haskell.org/D5182
* Add -fkeep-cafsSimon Marlow2018-09-282-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I noticed while playing around with https://github.com/fbsamples/ghc-hotswap/ that the main binary needs to have a custom main function to set `config.keep_cafs = true` when initialising the runtime. This is pretty annoying, it means an extra C file with some cryptic incantations in it, and a `-no-hs-main` flag. So I've replaced this with a link-time flag to GHC, `-fkeep-cafs` that does the same thing. Test Plan: New unit test that tests for the RTS's GC'd CAFs assertion, and also the -keep-cafs flag. Reviewers: bgamari, osa1, erikd, noamz Reviewed By: osa1 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5183
* Expose wopt_set/unset_fatal in DynFlagsNeil Mitchell2018-09-281-1/+1
| | | | PR: https://github.com/ghc/ghc/pull/199/
View Lorry Controller Status