summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Include usg_file_hash in ghc --show-iface outputSimon Marlow2017-10-241-1/+2
| | | | | | | | | | | | | | Summary: Otherwise we can get an iface hash difference, but no indication of what caused it in the --show-iface output. Test Plan: Harbourmaster Reviewers: austin, bgamari, erikd Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4115
* Temporary fix to Trac #14380Simon Peyton Jones2017-10-241-4/+17
| | | | | | | | This fix replaces an utterly bogus error message with a decent one, rejecting a pattern synonym with a list pattern and rebindable syntax. Not hard to fix properly, but I'm going to wait for a willing volunteer and/or more user pressure.
* Comments onlySimon Peyton Jones2017-10-231-1/+1
|
* Improve kick-out in the constraint solverSimon Peyton Jones2017-10-205-124/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch was provoked by Trac #14363. Turned out that we were kicking out too many constraints in TcSMonad.kickOutRewritable, and that mean that the work-list never became empty: infinite loop! That in turn made me look harder at the Main Theorem in Note [Extending the inert equalities]. Main changes * Replace TcType.isTyVarExposed by TcType.isTyVarHead. The over-agressive isTyVarExposed is what caused Trac #14363. See Note [K3: completeness of solving] in TcSMonad. * TcType.Make anyRewriteableTyVar role-aware. In particular, a ~R ty cannot rewrite b ~R f a See Note [anyRewriteableTyVar must be role-aware]. That means it has to be given a role argument, which forces a little refactoring. I think this change is fixing a bug that hasn't yet been reported. The actual reported bug is handled by the previous bullet. But this change is definitely the Right Thing The main changes are in TcSMonad.kick_out_rewritable, and in TcType (isTyVarExposed ---> isTyVarHead). I did a little unforced refactoring: * Use the cc_eq_rel field of a CTyEqCan when it is available, rather than recomputing it. * Define eqCanRewrite :: EqRel -> EqRel -> EqRel, and use it, instead of duplicating its logic
* Comments and white spaceSimon Peyton Jones2017-10-202-1/+4
|
* Outputable: Add pprTraceExceptionBen Gamari2017-10-191-1/+11
|
* Add Functor Bag instanceBen Gamari2017-10-191-0/+3
|
* Export injectiveVarsOf{Binder,Type} from TyCoRepRyan Scott2017-10-192-29/+36
| | | | | | | | | | | | | | | | | | Summary: I ended up needing to use the functionality of `injectiveVarsOfBinder`/`injectiveVarsOfType` in this Haddock PR (https://github.com/haskell/haddock/pull/681), but alas, neither of these functions were exported. Let's do so. Test Plan: Does it compile? Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4107
* Fix #14369 by making injectivity warnings finer-grainedRyan Scott2017-10-191-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Previously, GHC would always raise the possibility that a type family might not be injective in certain error messages, even if that type family actually //was// injective. Fix this by actually checking for a type family's lack of injectivity before emitting such an error message. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14369 Differential Revision: https://phabricator.haskell.org/D4106
* Error when deriving instances in hs-boot filesRyan Scott2017-10-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: According to the GHC users' guide, one cannot derive instances for data types in `.hs-boot` files. However, GHC was not enforcing this in practice, which led to #14365. Fix this by actually throwing an error if a derived instance is detected in an `.hs-boot` file (and recommend how to fix it in the error message.) Test Plan: make test TEST=T14365 Reviewers: ezyang, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14365 Differential Revision: https://phabricator.haskell.org/D4102
* Typofix in commentGabor Greif2017-10-181-1/+1
|
* Better solving for representational equalitiesSimon Peyton Jones2017-10-184-163/+215
| | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a bit of extra solving power for representational equality constraints to fix Trac #14333 The main changes: * Fix a buglet in TcType.isInsolubleOccursCheck which wrongly reported a definite occurs-check error for (a ~R# b a) * Get rid of TcSMonad.emitInsolubles. It had an ad-hoc duplicate-removal piece that is better handled in interactIrred, now that insolubles are Irreds. We need a little care to keep inert_count (which does not include insolubles) accurate. * Refactor TcInteract.solveOneFromTheOther, to return a much simpler type. It was just over-complicated before. * Make TcInteract.interactIrred look for constraints that match either way around, in TcInteract.findMatchingIrreds This wasn't hard and it cleaned up quite a bit of code.
* Don't deeply expand insolublesSimon Peyton Jones2017-10-181-6/+16
| | | | | | | | | Trac #13450 went bananas if we expand insoluble constraints. Better just to leave them un-expanded. I'm not sure in detail about why it goes so badly wrong; but regardless, the less we mess around with insoluble contraints the better the error messages will be.
* Fix grammaros in commentsGabor Greif2017-10-172-2/+2
|
* Simplify, no functionality changeGabor Greif2017-10-171-7/+6
|
* RtClosureInspect: Fix inspecting Char# on 64-bit big-endianJames Clarke2017-10-161-1/+4
| | | | | | | | | | | | | | | | | Char# is represented with a full machine word, whereas Char's Storable instance uses an Int32, so we can't just treat it like a single-element Char array. Instead, read it as an Int and use chr to turn it into a Char. This fixes Trac #11262. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #11262 Differential Revision: https://phabricator.haskell.org/D4089
* Levity polymorphic Backpack.Edward Z. Yang2017-10-165-13/+44
| | | | | | | | | | | | | | | | | | | | | This patch makes it possible to specify non * kinds of abstract data types in signatures, so you can have levity polymorphism through Backpack, without the runtime representation constraint! Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: andrewthad, bgamari, austin, goldfire Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13955 Differential Revision: https://phabricator.haskell.org/D3825
* Implement new `compareByteArrays#` primopHerbert Valerio Riedel2017-10-161-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new primop compareByteArrays# :: ByteArray# -> Int# {- offset -} -> ByteArray# -> Int# {- offset -} -> Int# {- length -} -> Int# allows to compare the subrange of the first `ByteArray#` to the (same-length) subrange of the second `ByteArray#` and returns a value less than, equal to, or greater than zero if the range is found, respectively, to be byte-wise lexicographically less than, to match, or be greater than the second range. Under the hood, the new primop is implemented in terms of the standard ISO C `memcmp(3)` function. It is currently an out-of-line primop but work is underway to optimise this into an inline primop for a future follow-up Differential (see D4091). This primop has applications in packages like `text`, `text-short`, `bytestring`, `text-containers`, `primitive`, etc. which currently have to incur the overhead of an ordinary FFI call to directly or indirectly invoke `memcmp(3)` as well has having to deal with some `unsafePerformIO`-variant. While at it, this also improves the documentation for the existing `copyByteArray#` primitive which has a non-trivial type-signature that significantly benefits from a more explicit description of its arguments. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D4090
* Fix panic for `ByteArray#` arguments in CApiFFI foreign importsHerbert Valerio Riedel2017-10-161-0/+6
| | | | | | | | | | | | | | | | | | | | Declarations such as foreign import capi unsafe "string.h strlen" c_strlen_capi :: ByteArray# -> IO CSize foreign import capi unsafe "string.h memset" c_memset_capi :: MutableByteArray# s -> CInt -> CSize -> IO () would cause GHC to panic because the CApiFFI c-wrapper generator didn't know what C type to use for `(Mutable)ByteArray#` types (unlike the `ccall` codepath). This addresses #9274 Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D4092
* Fix typoPeter Trommler2017-10-161-1/+1
|
* Fix typoPeter Trommler2017-10-161-1/+1
|
* Do not bind coercion variables in SpecConstr rulesSimon Peyton Jones2017-10-121-2/+42
| | | | | | | | | | | | | | | | Trac #14270 showed that SpecConstr could cause nasty Lint failures if it generates a RULE that binds coercion varables. See * Note [SpecConstr and casts], and * the test simplCore/should_compile/T14270. This doesn't feel like the final word to me, because somehow the specialisation "ought" to work. So I left in a debug WARN to yell if the new check acutally fires. Meanwhile, it stops the erroneous specialisation. binding coercion
* Do not quantify over deriving clausesSimon Peyton Jones2017-10-121-9/+13
| | | | | | | | | | | | Trac #14331 showed that in a data type decl like data D = D deriving (C (a :: k)) we were quantifying D over the 'k' in the deriving clause. Yikes. Easily fixed, by deleting code in RnTypes.extractDataDefnKindVars See the discussion on the ticket, esp comment:8.
* Add a missing zonk in TcDerivInfer.simplifyDerivSimon Peyton Jones2017-10-111-0/+2
| | | | | | I'm astonished that anything worked without this! Fixes Trac #14339
* Avoid creating dependent types in FloatOutSimon Peyton Jones2017-10-111-20/+61
| | | | | | | | This bug was exposed by Trac #14270. The problem and its cure is described in SetLevels, Note [Floating and kind casts]. It's simple and will affect very few programs. But the very fact that it was so unexpected is discomforting.
* Pretty-printing of derived multi-parameter classes omits parenthesesAlan Zimmerman2017-10-113-6/+42
| | | | | | | | | | | | | | | | | | | Summary: Pretty printing a splice with an HsAppType in the deriving clause, such as $([d| data Foo a = Foo a deriving (C a) |]) would omit the parens. Test Plan: ./validate Reviewers: RyanGlScott, austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14289 Differential Revision: https://phabricator.haskell.org/D4056
* Fix #10816 by renaming FixitySigs more consistentlyRyan Scott2017-10-112-45/+38
| | | | | | | | | | | | | | | | | | | | | Summary: #10816 surfaced because we were renaming top-level fixity declarations with a different code path (`rnSrcFixityDecl`) than the code path for fixity declarations inside of type classes, which is not privy to names that exist in the type namespace. Luckily, the fix is simple: use `rnSrcFixityDecl` in both places. Test Plan: make test TEST=T10816 Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #10816 Differential Revision: https://phabricator.haskell.org/D4077
* Remove wc_insol from WantedConstraintsSimon Peyton Jones2017-10-1110-220/+247
| | | | | | | | | | | | | | | | | | | | | | | | This patch is a pure refactoring, which I've wanted to do for some time. The main payload is * Remove the wc_insol field from WantedConstraints; instead put all the insolubles in wc_simple * Remove inert_insols from InertCans Instead put all the insolubles in inert_irreds * Add a cc_insol flag to CIrredCan, to record that the constraint is definitely insoluble Reasons * Quite a bit of code gets slightly simpler * Fewer concepts to keep separate * Insolubles don't happen at all in production code that is just being recompiled, so previously there was a lot of moving-about of empty sets A couple of error messages acutally improved.
* Delete two unused functionsSimon Peyton Jones2017-10-112-13/+1
| | | | | | | | Delete unused functions pprArrowChain pprPrefixApp from TyCoRep
* Change "cobox" to "co" in debug outputSimon Peyton Jones2017-10-111-1/+1
| | | | | These coercions are /not/ boxed, so "cobox" is positively misleading. And it's longer than necessary.
* Fix over-eager error suppression in TcErrorsSimon Peyton Jones2017-10-111-2/+22
| | | | | | See Note [Given insolubles] in TcRnTypes Fixes Trac #14325.
* Minor refactoringSimon Peyton Jones2017-10-111-16/+16
| | | | | I'm trying to understand Check.hs. This patch is a very minor refactoring. No change in behaviour.
* Typos in comments onlySimon Peyton Jones2017-10-111-2/+2
|
* Tidy up some convoluted "child/parent" codeSimon Peyton Jones2017-10-112-83/+65
| | | | | | | | | | | In investigating something else (Trac #14307) I encountered the wonders of TcRnExports.lookupChildrenExport, and the data type ChildLookupResult. I managed to remove the NameErr constructor from ChildLookupResult, and simplify the code significantly at the same time. This is just refactoring; no change in behaviour.
* Split SysTools up someTamar Christina2017-10-107-1078/+1199
| | | | | | | | | | | | | | | | | Summary: SysTools and DriverTools have an annoying mutual dependency. They also each contain pieces of the linker. In order for changes to be shared between the library and the exe linking code this dependency needs to be broken in order to avoid using hs-boot files. Reviewers: austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4071
* Simply Data instance context for AmbiguousFieldOccRyan Scott2017-10-071-4/+1
| | | | | | The current, verbose instance context can be compacted into `DataId pass`. Indeed, that's what most of the `Data` instances in this module already do, so this just makes things consistent.
* Fix #14320 by looking through HsParTy in more placesRyan Scott2017-10-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: GHC was needlessly rejecting GADT constructors' type signatures that were surrounded in parentheses due to the fact that `splitLHsForAllTy` and `splitLHsQualTy` (which are used to check as part of checking if GADT constructor return types are correct) weren't looking through parentheses (i.e., `HsParTy`). This is easily fixed, though. Test Plan: make test TEST=T14320 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14320 Differential Revision: https://phabricator.haskell.org/D4072
* Incorporate changes from #11721 into Template HaskellRyan Scott2017-10-073-23/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: #11721 changed the order of type variables in GADT constructor type signatures, but these changes weren't reflected in Template Haskell reification of GADTs. Let's do that. Along the way, I: * noticed that the `T13885` test was claiming to test TH reification of GADTs, but the reified data type wasn't actually a GADT! Since this patch touches that part of the codebase, I decided to fix this. * incorporated some feedback from @simonpj in https://phabricator.haskell.org/D3687#113566. (These changes alone don't account for any different in behavior.) Test Plan: make test TEST=T11721_TH Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: goldfire, bgamari, simonpj Subscribers: rwbarton, thomie, simonpj GHC Trac Issues: #11721 Differential Revision: https://phabricator.haskell.org/D4070
* Remove m_type from Match (#14313)Joachim Breitner2017-10-049-68/+23
| | | | | | | this is a remains from supporting Result Type Signaturs in the ancient past. Differential Revision: https://phabricator.haskell.org/D4066
* Don't pass HscEnv to functions in the Hsc monadDouglas Wilson2017-10-031-45/+53
| | | | | | | | | | | | | | | | | | | | `Hsc` is a reader monad in `HscEnv`. Several functions in HscMain were taking parameters of type `HscEnv` or `DynFlags`, and returning values of type `Hsc a`. This patch removes those parameters in favour of asking them from the context. This removes a source of confusion and should make refactoring a bit easier. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4061
* Include libraries which fill holes as deps when linking.Edward Z. Yang2017-10-031-1/+3
| | | | | | | | | | | | | | | | | | | Fixes the issue reported at https://github.com/haskell/cabal/issues/4755 and fixes #14304 in the GHC tracker. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14304 Differential Revision: https://phabricator.haskell.org/D4057
* Implement Div, Mod, and Log for type-level nats.Iavor Diatchki2017-10-032-15/+167
| | | | | | | | | | Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, dfeuer, adamgundry, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4002
* Track the order of user-written tyvars in DataConRyan Scott2017-10-0314-200/+426
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After typechecking a data constructor's type signature, its type variables are partitioned into two distinct groups: the universally quantified type variables and the existentially quantified type variables. Then, when prompted for the type of the data constructor, GHC gives this: ```lang=haskell MkT :: forall <univs> <exis>. (...) ``` For H98-style datatypes, this is a fine thing to do. But for GADTs, this can sometimes produce undesired results with respect to `TypeApplications`. For instance, consider this datatype: ```lang=haskell data T a where MkT :: forall b a. b -> T a ``` Here, the user clearly intended to have `b` be available for visible type application before `a`. That is, the user would expect `MkT @Int @Char` to be of type `Int -> T Char`, //not// `Char -> T Int`. But alas, up until now that was not how GHC operated—regardless of the order in which the user actually wrote the tyvars, GHC would give `MkT` the type: ```lang=haskell MkT :: forall a b. b -> T a ``` Since `a` is universal and `b` is existential. This makes predicting what order to use for `TypeApplications` quite annoying, as demonstrated in #11721 and #13848. This patch cures the problem by tracking more carefully the order in which a user writes type variables in data constructor type signatures, either explicitly (with a `forall`) or implicitly (without a `forall`, in which case the order is inferred). This is accomplished by adding a new field `dcUserTyVars` to `DataCon`, which is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to the order in which the user wrote them. For more details, refer to `Note [DataCon user type variables]` in `DataCon.hs`. An interesting consequence of this design is that more data constructors require wrappers. This is because the workers always expect the first arguments to be the universal tyvars followed by the existential tyvars, so when the user writes the tyvars in a different order, a wrapper type is needed to swizzle the tyvars around to match the order that the worker expects. For more details, refer to `Note [Data con wrappers and GADT syntax]` in `MkId.hs`. Test Plan: ./validate Reviewers: austin, goldfire, bgamari, simonpj Reviewed By: goldfire, simonpj Subscribers: ezyang, goldfire, rwbarton, thomie GHC Trac Issues: #11721, #13848 Differential Revision: https://phabricator.haskell.org/D3687
* Optimize linker by minimizing calls to tryGCC to avoid fork/exec overhead.Tamar Christina2017-10-031-20/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows process creations are fairly expensive. As such calling them in what's essentially a hot loop is also fairly expensive. Each time we make a call to `tryGCC` the following fork/exec/wait happen ``` gcc -> realgcc -> cc1 ``` This is very problematic, because according to the profiler about 20% of the time is spent on just process creation and spin time. The goal of the patch is to mitigate this by asking GCC once for it's search directories, caching these (because it's very hard to change these at all after the process started since GCC's base dirs don't change unless with extra supplied `-B` flags.). We also do the same for the `findSysDll` function, since this computes the search path every time by registery accesses etc. These changes and D3909 drop GHC on Windows startup time from 2-3s to 0.5s. The remaining issue is a 1.5s wait lock on `CONIN$` which can be addressed with the new I/O manager code. But this makes GHCi as responsive on Windows as GHC 7.8 was. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3910
* Suppress error cascade in record fieldsSimon Peyton Jones2017-10-031-11/+21
| | | | | | | | | | | | | | | When a record contruction or pattern uses a data constructor that isn't in scope, we may produce spurious ambiguous-field errors (Trac #14307). E.g. f (A { fld = x }) = e where 'A' is not in scope. We want to draw attention to the out-of-scope data constructor first; once that is fixed we can think about the fields. This patch suppresses the field errors if the data con is out of scope.
* Fix nasty bug in w/w for absence analysisSimon Peyton Jones2017-10-035-96/+197
| | | | | | | | | | | | | | | | | | | | This dark corner was exposed by Trac #14285. It involves the interaction between absence analysis and INLINABLE pragmas. There is a full explanation in Note [aBSENT_ERROR_ID] in MkCore, which you can read there. The changes in this patch are * Make exprIsHNF return True for absentError, treating absentError like an honorary data constructor. * Make absentError /not/ be diverging, unlike other error Ids. This is all a bit horrible. * While doing this I found that exprOkForSpeculation didn't have a case for value lambdas so I added one. It's not really called on lifted types much, but it seems like the right thing
* Fix bug in the short-cut solverSimon Peyton Jones2017-10-033-58/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #13943 showed that the relatively-new short-cut solver for class constraints (aka -fsolve-constant-dicts) was wrong. In particular, see "Type families" under Note [Shortcut solving] in TcInteract. The short-cut solver recursively solves sub-goals, but it doesn't flatten type-family applications, and as a result it erroneously thought that C (F a) cannot possibly match (C 0), which is simply untrue. That led to an inifinte loop in the short-cut solver. The significant change is the one line + , all isTyFamFree preds -- See "Type families" in + -- Note [Shortcut solving] but, as ever, I do some other refactoring. (E.g. I changed the name of the function to shortCutSolver rather than the more generic trySolveFromInstance.) I also made the short-cut solver respect the solver-depth limit, so that if this happens again it won't just produce an infinite loop. A bit of other refactoring, notably moving isTyFamFree from TcValidity to TcType
* Comments onlySimon Peyton Jones2017-10-033-10/+11
|
* Pretty-printer missing parens for infix class declarationAlan Zimmerman2017-10-021-0/+4
| | | | | | | | | | class (a `C` b) c Is pretty printed as class a `C` b c Fixes #14306
* Fix #13391 by checking for kind-GADTsRichard Eisenberg2017-09-282-0/+37
| | | | | | | The check is a bit gnarly, but I couldn't think of a better way. See the new code in TcTyClsDecls. test case: polykinds/T13391
View Lorry Controller Status