summaryrefslogtreecommitdiff
path: root/compiler/main/DynFlags.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Make GHCi & TH work when the compiler is built with -profSimon Marlow2015-11-071-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Amazingly, there were zero changes to the byte code generator and very few changes to the interpreter - mainly because we've used good abstractions that hide the differences between profiling and non-profiling. So that bit was pleasantly straightforward, but there were a pile of other wibbles to get the whole test suite through. Note that a compiler built with -prof is now like one built with -dynamic, in that to use TH you have to build the code the same way. For dynamic, we automatically enable -dynamic-too when TH is required, but we don't have anything equivalent for profiling, so you have to explicitly use -prof when building code that uses TH with a profiled compiler. For this reason Cabal won't work with TH. We don't expect to ship a profiled compiler, so I think that's OK. Test Plan: validate with GhcProfiled=YES in validate.mk Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1407 GHC Trac Issues: #4837, #545
* DynFlags: -freverse-errors should be defFlagBen Gamari2015-11-011-2/+2
| | | | | This flag works under both GHC and GHCi, as pointed out on D1367. Thanks to @thomie for pointing this out.
* Reimplement shadowing on a per database basis.Edward Z. Yang2015-10-301-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: This commit reimplements shadowing on package databases by doing the shadowing calculation on a per-database basis: specifically, if a later package database shadows a package from the earlier databases, we first remove that package (and its transitive dependencies) before merging the databases together. This should also fix bootstrapping GHC HEAD with HEAD. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: ggreif, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1385
* DynFlags: Add (another) missing hunk from D1360Ben Gamari2015-10-291-0/+5
| | | | What a disaster this merge was.
* Make worker-wrapper optionalChristiaan Baaij2015-10-271-4/+25
| | | | | | | | | | | | | | | | | | | Add -fworker-wrapper flag which enables the worker-wrapper transformation. It is implied by -O. The expected users of this flag, which includes myself, are GHC API users. In my Haskell-to-Hardware compiler, which uses the GHC API, I have seen no benifits of the worker-wrapper transformation. It does however induce longer compilation times. Further discussion can be seen here: https://mail.haskell.org/pipermail/ghc-devs/2015-October/010096.html Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1372 GHC Trac Issues: #11020
* DynFlags: Yet one more fixBen Gamari2015-10-271-0/+3
|
* DynFlags: Fix more merge errorsBen Gamari2015-10-271-1/+3
|
* Fix "Use correct documentation flag for freverse-errors"Ben Gamari2015-10-271-0/+4
| | | | | This fixes commit d1d8704cb3d003315177fad1394fce49f98fb1a2, which somehow was mangled during merge.
* Make it possible to have different UniqSupply strategiesBartosz Nitka2015-10-271-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To get reproducible/deterministic builds, the way that the Uniques are assigned shouldn't matter. This allows to test for that. It add 2 new flags: * `-dinitial-unique` * `-dunique-increment` And by varying these you can get interesting effects: * `-dinitial-unique=0 -dunique-increment 1` - current sequential UniqSupply * `-dinitial-unique=16777215 -dunique-increment -1` - UniqSupply that generates in decreasing order * `-dinitial-unique=1 -dunique-increment PRIME` - where PRIME big enough to overflow often - nonsequential order I haven't proven the usefullness of the last one yet and it's the reason why we have to mask the bits with `0xFFFFFF` in `genSym`, so I can remove it if it becomes contentious. Test Plan: validate on harbormaster Reviewers: simonmar, austin, ezyang, bgamari Reviewed By: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1360 GHC Trac Issues: #4012
* Use correct documentation flag for freverse-errorsSiddhanathan Shanmugam2015-10-271-2/+2
| | | | | | | | | | Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1376 GHC Trac Issues: #10848
* Add flag to reverse errors in GHC/GHCiSiddhanathan Shanmugam2015-10-261-2/+11
| | | | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1367 GHC Trac Issues: #10848
* Libdw: Add libdw-based stack unwindingBen Gamari2015-10-171-0/+1
| | | | | | | | | | | | | | | | | | | | | This adds basic support to the RTS for DWARF-assisted unwinding of the Haskell and C stack via libdw. This only adds the infrastructure; consumers of this functionality will be introduced in future diffs. Currently we are carrying the initial register collection code in Libdw.c but this will eventually make its way upstream to libdw. Test Plan: See future patches Reviewers: Tarrasch, scpmw, austin, simonmar Reviewed By: austin, simonmar Subscribers: simonmar, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1196 GHC Trac Issues: #10656
* Implement DuplicateRecordFieldsAdam Gundry2015-10-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements DuplicateRecordFields, the first part of the OverloadedRecordFields extension, as described at https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields This includes fairly wide-ranging changes in order to allow multiple records within the same module to use the same field names. Note that it does *not* allow record selector functions to be used if they are ambiguous, and it does not have any form of type-based disambiguation for selectors (but it does for updates). Subsequent parts will make overloading selectors possible using orthogonal extensions, as described on the wiki pages. This part touches quite a lot of the codebase, and requires changes to several GHC API datatypes in order to distinguish between field labels (which may be overloaded) and selector function names (which are always unique). The Haddock submodule has been adapted to compile with the GHC API changes, but it will need further work to properly support modules that use the DuplicateRecordFields extension. Test Plan: New tests added in testsuite/tests/overloadedrecflds; these will be extended once the other parts are implemented. Reviewers: goldfire, bgamari, simonpj, austin Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D761
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-141-15/+15
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Update Cabal to HEAD, IPID renamed to Component ID.Edward Z. Yang2015-10-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit contains a Cabal submodule update which unifies installed package IDs and package keys under a single notion, a Component ID. We update GHC to keep follow this unification. However, this commit does NOT rename installed package ID to component ID and package key to unit ID; the plan is to do that in a companion commit. - Compiler info now has "Requires unified installed package IDs" - 'exposed' is now expected to contain unit keys, not IPIDs. - Shadowing is no more. We now just have a very simple strategy to deal with duplicate unit keys in combined package databases: if their ABIs are the same, use the latest one; otherwise error. Package databases maintain the invariant that there can only be one entry of a unit ID. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1184 GHC Trac Issues: #10714
* Switch to LLVM version 3.7Erik de Castro Lopo2015-10-141-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | Before this commit, GHC only supported LLVM 3.6. Now it only supports LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier do not work on AArch64/Arm64, but 3.7 does. Also: * Add CC_Ghc constructor to LlvmCallConvention. * Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with a single `supportedLlvmVersion` variable. * Get `supportedLlvmVersion` from version specified in configure.ac. * Drop llvmVersion field from DynFlags (no longer needed because only one version is supported). Test Plan: Validate on x86_64 and arm Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1320 GHC Trac Issues: #10953
* Delete ShPackageKey for now.Edward Z. Yang2015-10-101-41/+0
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Move orphan instance/rule warnings to typechecker/desugarer.Edward Z. Yang2015-10-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing these warnings at MkIface time, we do them when we create the instances/rules in the typechecker/desugarer. Emitting warnings for auto-generated instances was a pain (since the specialization monad doesn't have the capacity to emit warnings) so instead I just deprecated -fwarn-auto-orphans. Auto rule orphans are pretty harmless anyway: they don't cause interface files to be eagerly loaded in. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1297
* DeriveLift extension (#1830)RyanGlScott2015-09-211-0/+2
| | | | | | | | | | | | | | | | | | | | Summary: This implements -XDeriveLift, which allows for automatic derivation of the Lift class from template-haskell. The implementation is based off of Ian Lynagh's th-lift library (http://hackage.haskell.org/package/th-lift). Test Plan: ./validate Reviewers: hvr, simonpj, bgamari, goldfire, austin Reviewed By: goldfire, austin Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1168 GHC Trac Issues: #1830
* ApplicativeDo transformationSimon Marlow2015-09-171-0/+2
| | | | | | | | | | | | | | | | Summary: This is an implementation of the ApplicativeDo proposal. See the Note [ApplicativeDo] in RnExpr for details on the current implementation, and the wiki page https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo for design notes. Test Plan: validate Reviewers: simonpj, goldfire, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D729
* DynFlags: remove unused sPgm_sysman (#8689)Thomas Miedema2015-09-161-4/+1
| | | | | | | | Something about a long deleted 'system manager' for the 'parallel system'. Also remove confusing comment in SysTools, that supposedly referred to sPgm_sysman. See commit 16d5d1c75c999677783c9c1bda519540fa9a6e58.
* Accept underscores in the module parser. (Thanks spinda for the fix.)Edward Z. Yang2015-09-031-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Improve the error messages for class instance errorsSimon Peyton Jones2015-09-021-0/+2
| | | | | | | | | | Summary: See Note [Displaying potential instances]. Reviewers: austin Subscribers: KaneTW, thomie Differential Revision: https://phabricator.haskell.org/D1176
* Fix rdynamic flag and test on WindowsTamar Christina2015-08-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The rdynamic tests and feature are marked broken on windows. This is because the flag used doesn't exist and the symbol lookup in the test did not account for platform differences in name mangling. This commit fixes the flag and tests for rdynamic on windows. Test Plan: make TEST="rdynamic" on both x86 and x86_64 Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1149 GHC Trac Issues: #9381
* DynFlags: Prohibit hpc and byte-code interpreterBen Gamari2015-08-131-0/+4
| | | | | The user's guide says hpc is incompatible with GHCi and #9903 would agree. Fixes #9903.
* Ensure DynFlags are consistentBen Gamari2015-08-061-2/+34
| | | | | | | | | | | | | | | | | | | | | | | While we have always had makeDynFlagsConsistent to enforce a variety of consistency invariants on DynFlags, it hasn't been widely used. GHC.Main, for instance, ignored it entirely. This leads to issues like Trac #10549, where an OPTIONS_GHC pragma introduced an inconsistency, leading to a perplexing crash later in compilation. Here I add consistency checks in GHC.Main.set{Session,Program}DynFlags, closing this hole. Fixes #10549. Test Plan: Validate with T10549 Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1128 GHC Trac Issues: #10549
* Warn about missed specialisations for importsSimon Peyton Jones2015-08-051-5/+8
| | | | | | | | | | | | | | | This change was provoked by Trac #10720, where a missing INLINEABLE pragma gave very poor performance. The change is to warn when an imported function is not specialised in a situation where the user expects it to be. New flags -fwarn-missed-specialisations -fwarn-all-missed-specialisations Documented in user manual. See Note [Warning about missed specialisations]
* Make -fcpr-off a dynamic flagChristiaan Baaij2015-08-051-0/+3
| | | | | | | | | | | | | | Test Plan: validate Reviewers: austin, goldfire, simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1110 GHC Trac Issues: #10706
* Typos in comments [skip ci]Gabor Greif2015-08-031-1/+1
|
* Implementation of StrictData language extensionAdam Sandberg Eriksson2015-07-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the `StrictData` language extension, which lets the programmer default to strict data fields in datatype declarations on a per-module basis. Specification and motivation can be found at https://ghc.haskell.org/trac/ghc/wiki/StrictPragma This includes a tricky parser change due to conflicts regarding `~` in the type level syntax: all ~'s are parsed as strictness annotations (see `strict_mark` in Parser.y) and then turned into equality constraints at the appropriate places using `RdrHsSyn.splitTilde`. Updates haddock submodule. Test Plan: Validate through Harbormaster. Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari Reviewed By: simonpj, tibbe, bgamari Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering Differential Revision: https://phabricator.haskell.org/D1033 GHC Trac Issues: #8347
* Library names, with Cabal submodule updateEdward Z. Yang2015-07-231-1/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A library name is a package name, package version, and hash of the version names of all textual dependencies (i.e. packages which were included.) A library name is a coarse approximation of installed package IDs, which are suitable for inclusion in package keys (you don't want to put an IPID in a package key, since it means the key will change any time the source changes.) - We define ShPackageKey, which is the semantic object which is hashed into a PackageKey. You can use 'newPackageKey' to hash a ShPackageKey to a PackageKey - Given a PackageKey, we can lookup its ShPackageKey with 'lookupPackageKey'. The way we can do this is by consulting the 'pkgKeyCache', which records a reverse mapping from every hash to the ShPackageKey. This means that if you load in PackageKeys from external sources (e.g. interface files), you also need to load in a mapping of PackageKeys to their ShPackageKeys so we can populate the cache. - We define a 'LibraryName' which encapsulates the full depenency resolution that Cabal may have selected; this is opaque to GHC but can be used to distinguish different versions of a package. - Definite packages don't have an interesting PackageKey, so we rely on Cabal to pass them to us. - We can pretty-print package keys while displaying the instantiation, but it's not wired up to anything (e.g. the Outputable instance of PackageKey). Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1056 GHC Trac Issues: #10566
* Implement -dsuppress-unfoldingsSimon Peyton Jones2015-07-211-0/+3
| | | | | | | This extra "suppress" flag helps when there are a lot of Ids with big unfoldings that clutter up the dump Also slightly refactor printing of coercions in Core
* Put Opt_Static into defaultFlags if not pc_DYNAMIC_BY_DEFAULT (#7478)Bernhard Herzog2015-07-171-1/+2
| | | | | | | | | | | | | | | | | The test for Trac issue #7478 fails on some systems due to inconsistent default flags for dynamic vs. static linking. Test Plan: validate Reviewers: austin, thomie Reviewed By: thomie Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1017 GHC Trac Issues: #7478
* Implement -fprint-expanded-synonymsÖmer Sinan Ağacan2015-07-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | Add a flag to print type-synonyms-expanded versions of types in type error messages (in addition to old error messages with synonyms) * Mailing list discussion: https://mail.haskell.org/pipermail/ghc-devs/2015-June/009247.html * Wiki page: https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal * Trac: https://ghc.haskell.org/trac/ghc/ticket/10547 Test Plan: * I'll find some examples and add tests. Reviewers: austin, simonpj, goldfire, bgamari Reviewed By: austin, simonpj, goldfire, bgamari Subscribers: rodlogic, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1016 GHC Trac Issues: #10547
* Delete the WayPar wayThomas Miedema2015-07-101-14/+0
| | | | | | Also remove 't' and 's' from ALL_WAYS; they don't exist. Differential Revision: https://phabricator.haskell.org/D1055
* always use -fPIC on OpenBSD/AMD64 platformKarel Gardas2015-07-071-0/+6
| | | | | | | | | | | | | | | | Summary: This patch switches -fPIC on for every invocation of GHC on OpenBSD/AMD64 platform. The reason is OpenBSD's support for PIE (PIC for executables) hence -fPIC is also needed for GHC compiled code. Fixes #10597 Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1027
* Allow deferred type error warnings to be suppressedDavid Kraeutmann2015-07-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | Adds a flag -fwarn-deferred-type-errors similar to -fwarn-typed-holes. Changes the boolean flag of -fdefer-type-errors to a 3-state flag similar to the one used by -fdefer-typed-holes/-fwarn-typed-holes. Test Plan: Since only the absence of deferred type error warnings when -fno-warn-deferred-type-errors is passed has to be tested, I duplicated a test case checking -fdefer-type-errors and adjusted it accordingly. Reviewers: nomeata, simonpj, austin, thomie, bgamari, hvr Reviewed By: nomeata, simonpj, austin, thomie, bgamari, hvr Subscribers: bgamari, simonpj, nomeata, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D864 GHC Trac Issues: #10283
* Add -fcross-module-specialise flagBen Gamari2015-06-281-0/+3
| | | | | | | | | | | | | | | | | | | | Summary: As of 7.10.1 we specialize INLINEABLE identifiers defined in other modules. This can expose issues (compiler bugs or otherwise) in some cases (e.g. Trac #10491) and therefore we now provide a way for the user to disable this optimization. Test Plan: Successfully compile Splice.hs from Trac #10491. Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D999 GHC Trac Issues: #10491
* Another major improvement of "improvement"Simon Peyton Jones2015-06-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I wasn't very happy with my fix to Trac #10009. This is much better. The main idea is that the inert set now contains a "model", which embodies *all* the (nominal) equalities that we know about, with a view to exposing unifications. This requires a lot fewer iterations of the solver than before. There are extensive comments in TcSMonad: Note [inert_model: the inert model] Note [Adding an inert canonical constraint the InertCans] The big changes are * New inert_model field in InertCans * Functions addInertEq, addInertCan deal with adding a constraint, maintaining the model * A nice improvement is that unification variables can unify with fmvs, so that from, say alpha ~ fmv we get alpha := fmv See Note [Orientation of equalities with fmvs] in TcFlatten It's still not perfect, as the Note explains New flag -fconstraint-solver-iterations=n, allows us to control the number of constraint solver iterations, and in particular will flag up when it's more than a small number. Performance is generally slightly better: T5837 is a lot better for some reason.
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-06-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Revert "compiler: make sure we reject -O + HscInterpreted" (again)Austin Seipp2015-05-191-7/+5
| | | | | | Apparently my machine likes this commit, but Harbormaster does not? This reverts commit b199536be25ea046079587933cc73d0a948a0626.
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-05-191-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Revert D727Austin Seipp2015-05-121-7/+5
| | | | | | | | This caused print007 to fail, so I guess I botched this more than I thought. This is a combination of reverting: "Fix build breakage from 9736c042", commit f35d621. "compiler: make sure we reject -O + HscInterpreted", commit 9736c04.
* Fix weird behavior of -ignore-dot-ghci and -ghci-sciptZejun Wu2015-05-121-0/+2
| | | | | | | | | | | | * Make `-ghci-script` be executed in the order they are specified; * Make `-ignore-dot-ghci` only ignores the default .ghci files but still execute the scripts passed by `-ghci-script`. Reviewed By: simonmar, austin Differential Revision: https://phabricator.haskell.org/D887 GHC Trac Issues: #10408
* New handling of overlapping inst in Safe HaskellDavid Terei2015-05-111-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | We do much better now due to the newish per-instance flags. Rather than mark any module that uses `-XOverlappingInstances`, `-XIncoherentInstances` or the new `OVERLAP*` pragmas as unsafe, we regard them all as safe and defer the check until an overlap occurs. An type-class method call that involves overlapping instances is considered _unsafe_ when: 1) The most specific instance, Ix, is from a module marked `-XSafe` 2) Ix is an orphan instance or a MPTC 3) At least one instance that Ix overlaps, Iy, is: a) from a different module than Ix AND b) Iy is not marked `OVERLAPPABLE` This check is only enforced in modules compiled with `-XSafe` or `-XTrustworthy`. This fixes Safe Haskell to work with the latest overlapping instance pragmas, and also brings consistent behavior. Previously, Safe Inferred modules behaved differently than `-XSafe` modules.
* Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382.Edward Z. Yang2015-05-111-23/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. There are some minor BC changes to template-haskell to make it boot on GHC 7.8. Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382
* Fix build breakage from 9736c042Austin Seipp2015-05-111-4/+7
| | | | | | | This was a snaffu caused by my in-tree patch actually differing from the Phab one slightly. Whoops. Signed-off-by: Austin Seipp <austin@well-typed.com>
* compiler: make sure we reject -O + HscInterpretedAustin Seipp2015-05-111-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using GHCi, we explicitly reject optimization, because the compilers optimization passes can introduce unboxed tuples, which the interpreter is not able to handle. But this goes the other way too: using GHCi on optimized code may cause the optimizer to float out breakpoints that the interpreter introduces. This manifests itself in weird ways, particularly if you as an API client use custom DynFlags to introduce optimization in combination with HscInterpreted. It turns out we weren't checking for consistent DynFlag settings when doing `setSessionDynFlags`, as #10052 showed. While the main driver handled it in `DynFlags` via `parseDynamicFlags`, we didn't check this elsewhere. This does a little refactoring to split out some of the common code, and immunizes the various `DynFlags` utilities in the `GHC` module from this particular bug. We should probably be checking other general invariants too. This fixes #10052, and adds some notes about the behavior in `GHC` and `FloatOut` As a bonus, expose `warningMsg` from `ErrUtils` as a helper since it didn't exist (somehow). Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: edsko Differential Revision: https://phabricator.haskell.org/D727 GHC Trac Issues: #10052
* Revert stage 1 template-haskell. This is a combination of 5 commits.Edward Z. Yang2015-05-091-4/+23
| | | | | | | | | | | | | | | | | | | | | | Revert "Quick fix: drop base bound on template-haskell." This reverts commit 3c70ae032e4361b203dfcf22b0a424e8838a5037. Revert "Always do polymorphic typed quote check, c.f. #10384" This reverts commit 9a43b2c1f78b3cf684646af64b9b67dc8079f58f. Revert "RnSplice's staging test should be applied for quotes in stage1." This reverts commit eb0ed4030374af542c0a459480d32c8d4525e48d. Revert "Split off quotes/ from th/ for tests that can be done on stage1 compiler." This reverts commit 21c72e7d38c96ac80d31addf67ae4b3c7a6c3bbb. Revert "Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382." This reverts commit 28257cae77023f2ccc4cc1c0cd1fbbd329947a00.
* Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382.Edward Z. Yang2015-05-091-23/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit adds stage 1 support for Template Haskell quoting, e.g. [| ... expr ... |], which is useful for authors of quasiquoter libraries that do not actually need splices. The TemplateHaskell extension now does not unconditionally fail; it only fails if the renamer encounters a splice that it can't run. In order to make sure the referenced data structures are consistent, template-haskell is now a boot library. In the following patches, there are: - A few extra safety checks which should be enabled in stage1 - Separation of the th/ testsuite into quotes/ which can be run on stage1 Note for reviewer: big diff changes are simply code being moved out of an ifdef; there was no other substantive change to that code. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, goldfire Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D876 GHC Trac Issues: #10382
View Lorry Controller Status