summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Add Int8# and Word8#Michal Terepeta2018-11-0221-181/+579
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the first step of implementing: https://github.com/ghc-proposals/ghc-proposals/pull/74 The main highlights/changes: primops.txt.pp gets two new sections for two new primitive types for signed and unsigned 8-bit integers (Int8# and Word8 respectively) along with basic arithmetic and comparison operations. PrimRep/RuntimeRep get two new constructors for them. All of the primops translate into the existing MachOPs. For CmmCalls the codegen will now zero-extend the values at call site (so that they can be moved to the right register) and then truncate them back their original width. x86 native codegen needed some updates, since it wasn't able to deal with the new widths, but all the changes are quite localized. LLVM backend seems to just work. This is the second attempt at merging this, after the first attempt in D4475 had to be backed out due to regressions on i386. Bumps binary submodule. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate (on both x86-{32,64}) Reviewers: bgamari, hvr, goldfire, simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5258
* Bump time submoduleBen Gamari2018-11-021-1/+1
|
* Move eta-reduced coaxiom compatibility handling quirks into FamInstEnv.mniip2018-11-013-23/+42
| | | | | | | | | | | | | | | | | | | | The quirk caused an issue where GHC concluded that 'D' is possibly unifiable with 'D a' (the two types could have the same kind if D is a data family). Test Plan: Ensure T9371 stays fixed. Introduce T15704 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15704 Differential Revision: https://phabricator.haskell.org/D5206
* Add built-in syntax suggestions, and refactor to allow library useMatthías Páll Gissurarson2018-11-011-194/+240
| | | | | | | | | | | | | | | | | | | | | Summary: This change to the valid hole fits adds built-in syntax candidates (like (:) and []), so that they are checked in addition to what is in scope. The rest is merely a refactor and export of the functions used to find the valid hole fits, since there was interest at ICFP to use the valid hole fit machinery for additional uses. By exporting the `tcFilterHoleFits` function, this can now be done without having to rely on parsing the actual error message. Test Plan: Test for built-in syntax included Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5227
* Lower precedence for {-# UNPACK #-}Vladislav Zavialov2018-11-011-35/+85
| | | | | | | | | | Test Plan: Validate Reviewers: goldfire, bgamari Subscribers: osa1, mpickering, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5221
* Don't lint erroneous programs.Richard Eisenberg2018-11-011-2/+5
| | | | | | | | | | newFamInst lints its types. This is good. But it's not so good when there have been errors and thus recovery tycons are about. So we now don't. Fixes #15796. Test case: typecheck/should_fail/T15796
* Actually fail in failIfEmitsConstraintsRichard Eisenberg2018-11-011-1/+1
| | | | | | | | | | | | The function TcHsType.failIfEmitsConstraints says that it fails. It even does so in its name. But it didn't! It *reported* constraints but didn't fail. Now it does. This is important in tcHsClsInstType; see the comments therein. This was discovered while looking at #15797, but that ticket requires visible kind application to exhibit the bug; the test case will come with the patch for #12045.
* Fix embarrassing, egregious bug in roles of (->)Richard Eisenberg2018-11-012-2/+2
| | | | | | | | | | | | | | Previously, I had inexplicably decided that (->)'s roles were all Representational. But, of course, its first two parameters are *dependent* RuntimeReps. All dependent parameters have a Nominal role, because all roles in kinds are Nominal. Fix is easy, but I have no idea how the world hasn't come crashing down before now. This was found while investigating #15801, which requires visible type application in types to observe. Hence, the test case will come with the main patch for #12045.
* Fix #15815 by parenthesizing the arguments to infix ~Ryan Scott2018-10-291-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An unfortunate consequence of commit b9483981d128f55d8dae3f434f49fa6b5b30c779 (`Remove HsEqTy and XEqTy`) is infix uses of `~` in TH quotes now desugar differently than before. In particular, we have that: ```haskell a ~ (Int -> Int) ``` Now desugars to: ```haskell HsOpTy a (~) (HsOpTy Int (->) Int) ``` Which GHC interprets as being: ```haskell a ~ Int -> Int ``` Or, equivalently: ```haskell (a ~ Int) -> Int ``` Which is different than what was intended! This is the cause of #15815. All of this has revealed that we likely need to renovate the way we desugar infix type operators to be more consistent with the treatment for infix expressions (see https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on this.) Doing so would constitute a breaking change, however, so we will likely want to wait until another major GHC release to do this. In the meantime, this patch offers a non-invasive change to the way that infix uses of `~` are desugared. This makes the program in #15815 compile again by inserting extra `HsParTy`s around the arguments to `~` if they are lacking them. Test Plan: make test TEST=T15815 Reviewers: int-index, goldfire, bgamari Reviewed By: int-index Subscribers: int-e, rwbarton, carter GHC Trac Issues: #15815 Differential Revision: https://phabricator.haskell.org/D5274
* Revert "Remove kind generalisation from tcRnType"Richard Eisenberg2018-10-292-6/+18
| | | | | | | | | 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.
* Remove kind generalisation from tcRnTypeRichard Eisenberg2018-10-291-20/+4
| | | | | There is no need to kind-generalise in tcRnType. Types are not instantiated eagerly, so there's never anything to generalise.
* Fix #15787 by squashing a coercion hole.Richard Eisenberg2018-10-281-1/+3
| | | | | | | | | | | | | In type-incorrect code, we can sometimes let a coercion hole make it through the zonker. If this coercion hole then ends up in the environment (e.g., in the type of a data constructor), then it causes trouble later. This patch avoids trouble by substituting the coercion hole for its representative CoVar. Really, any coercion would do, but the CoVar was very handy. test case: polykinds/T15787
* Finish fix for #14880.Tobias Dammers2018-10-2836-805/+1120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bump template-haskell version to 2.15.0.0Ryan Scott2018-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, `th-abstraction`). This properly bumps the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15818 Differential Revision: https://phabricator.haskell.org/D5272
* Rewrite FastString table in concurrent hashtableZejun Wu2018-10-281-87/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reimplement global FastString table using a concurrent hashatable with fixed size segments and dynamically growing buckets instead of fixed size buckets. This addresses the problem that `mkFastString` was not linear when the total number of entries was large. Test Plan: ./validate ``` inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null GHCi, version 8.7.20181005: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. FastString stats: segments: 256 buckets: 16384 entries: 7117 largest segment: 64 smallest segment: 64 longest bucket: 5 has z-encoding: 0% ``` Also comapre the two implementation using {P187} The new implementation is on a par with the old version with different conbination of parameters and perform better when the number of FastString's are large. {P188} Reviewers: simonmar, bgamari, niteria Reviewed By: simonmar, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14854 Differential Revision: https://phabricator.haskell.org/D5211
* Plugins: Add documentation and missing exportsBen Gamari2018-10-282-5/+33
| | | | | | | | | | | | | | 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
* plugins: search for .a files if necessarysheaf2018-10-281-40/+38
| | | | | | | | | | | | | | | | | | Summary: on windows, plugins are loaded via .a files, but those paths were not being searched when loading plugins Test Plan: ./validate Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15700 Differential Revision: https://phabricator.haskell.org/D5253
* Fix TcType.anyRewritableTyVarNingning Xie2018-10-281-13/+9
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes #15805, where we found that `TcType.anyRewritableTyVar` has one wrong case. Besides the fix, it also: - removed some unnecessary `ASSERT2(tcIsTcTyVar...)` in `TcType`, as now we have `tcIsTcTyVar = isTyVar`. - fixed some comments Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15805 Differential Revision: https://phabricator.haskell.org/D5263
* Fix `:k` command: add validity checkingNingning Xie2018-10-282-1/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes #15806, where we found that the `:k` command in GHCi misses a validity checking for the type. Missing validity checking causes `:k` to accept types that are not validated. For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while impredictivity of type instantiation shouldn't be allowed. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15806 Differential Revision: https://phabricator.haskell.org/D5265
* Fix rare undefined asm temp end label error in x86Zejun Wu2018-10-281-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Encountered assembly error due to undefined label `.LcaDcU_info_end` for following code generated by `pprFrameProc`: ``` .Lsat_sa8fp{v}_info_fde_end: .long .Lblock{v caDcU}_info_fde_end-.Lblock{v caDcU}_info_fde .Lblock{v caDcU}_info_fde: .long _nbHlD-.Lsection_frame .quad block{v caDcU}_info-1 .quad .Lblock{v caDcU}_info_end-block{v caDcU}_info+1 .byte 1 ``` This diff fixed the error. Test Plan: ./validate Also the case where we used to have assembly error is now fixed. Unfortunately, I have limited insight here and cannot get a small enough repro or test case for this. Ben says: > I think I see: Previously we only produced end symbols for the info > tables of top-level procedures. However, blocks within a procedure may > also have info tables, we will dutifully generate debug information for > and consequently we get undefined symbols. Reviewers: simonmar, scpmw, last_g, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5246
* Fix for T14251 on ARMKavon Farvardin2018-10-282-39/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | We now calculate the SSE register padding needed to fix the calling convention in LLVM in a robust way: grouping them by whether registers in that class overlap (with the same class overlapping itself). My prior patch assumed that no matter the platform, physical register Fx aliases with Dx, etc, for our calling convention. This is unfortunately not the case for any platform except x86-64. Test Plan: Only know how to test on x86-64, but it should be tested on ARM with: `make test WAYS=llvm && make test WAYS=optllvm` Reviewers: bgamari, angerman Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15780, #14251, #15747 Differential Revision: https://phabricator.haskell.org/D5254
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-2738-429/+764
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove redundant SOURCE importSimon Jakobi2018-10-262-6/+1
|
* Fix nasty bug in the type free-var finder, at lastSimon Peyton Jones2018-10-261-12/+94
| | | | | | | | | | | | | | | | | | | | | Consider the type forall k. b -> k where b :: k -> Type Here the 'k' in b's kind must be a different 'k' to the forall k, because 'b' is free in the expression. So we must return 'k' among the free vars returned from tyCoVarsOfType applied that type. But we weren't. This is an outright bug, although we don't have a program that fails because of it. It's easy to fix, too: see TyCoRep Note [Closing over free variable kinds] This fix has been in the pipeline for ages because it fell into the Trac #14880 swamp. But this patch nails it.
* Fix generalisation for type constructorsSimon Peyton Jones2018-10-262-64/+86
| | | | | | | | | Fixing the way that we close-over-kinds when taking the free vars of a type revealed that the way we generalise type constructors was a bit wrong. This fixes it. See TcTyClDecls Note [Generalisation for type constructors]
* De-monadise the 'extract' functions in RnTypesSimon Peyton Jones2018-10-263-111/+102
| | | | | | | | | | | As Trac #15765 says, Once upon a time, the extract functions at the bottom of RnTypes were pure. Then, along came -XTypeInType, which needed to do a check in these functions for users mixing type variables with kind variables. Now, however, with -XTypeInType gone again, we no longer do this check. Thus, there is no reason to keep these functions monadic.
* A little more wibbling to -ddump-typesSimon Peyton Jones2018-10-251-2/+1
|
* Fix comment in TcTypeSimon Peyton Jones2018-10-251-20/+5
|
* Improve comments, triggered by Trac #15135Simon Peyton Jones2018-10-252-13/+22
|
* Remove a zonkTcTyVarToTyVarSimon Peyton Jones2018-10-252-24/+55
| | | | | | | | | | | | This patch fixes Trac #15778 by removing a zonkTcTyVarToTyVar from tcHsSigType. Nww that a pattern-bound type variable can refer to a type, it's obvoiusly wrong to expect it to be a TyVar! Moreover, that zonk is entirely unnecessary. I added a new Note [Type variables in the type environment] in TcRnTypes
* Add comments for StgCse and UnariseSimon Peyton Jones2018-10-252-0/+18
| | | | This just improves docmentation for the fix to Trac #15300
* Fix some broken links (#15733)Fangyi Zhou2018-10-251-1/+1
| | | | | | | | | | | | | | | | Change some URLs from hackage.haskell.org/trac to ghc.haskell.org/trac Test Plan: manually verify links work Reviewers: bgamari, simonmar, mpickering Reviewed By: bgamari, mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15733 Differential Revision: https://phabricator.haskell.org/D5257
* Remove unnecessary free-var-set deletionSimon Peyton Jones2018-10-243-12/+11
| | | | | | | In TcSimplify.neededEvVars, in add_implic_seeds we were deleting the 'givens'; but they are already deleted, so this is a no-op. This patch just remove the redundant delete.
* Wibble report a wantedSimon Peyton Jones2018-10-241-1/+4
|
* Add HasDebugCallStack to ctEvCoecionSimon Peyton Jones2018-10-241-1/+1
| | | | This is a debug-only change
* Report a Wanted error even if there are Given onesSimon Peyton Jones2018-10-242-10/+16
| | | | | | | | | | | | | | | We suppress some Given errors; see Note [Given errors] in TcErrors. But we must be careful not to suppress Wanted errors because of the presence of these Given errors -- else we might allow compilation to bogusly proceed The rubber hits the road in TcRnTypes.insolubleCt, where we don't want to treat Givens as insoluble, nor (and this is the new bit) Deriveds that arise from Givens. See Note [Given insolubles] in TcRnTypes. This fixes #15767.
* Don't print out undefined coercionsSimon Peyton Jones2018-10-242-1/+5
| | | | | | | | | | A debug-print was trying to print the coercion returned by the flattener. But that coercion can be undefined in the case of Derived constraints. Because we might rewrite it with [D] a ~ ty, and there is no evidence for that. Solution: don't attempt to print the coercion.
* Solve equalities in a pattern signatureSimon Peyton Jones2018-10-241-2/+23
| | | | | | | | Trac #15694 showed that we were forgetting to solve the equalities of a pattern signature until too late. Result: WARNINGs and a panic: "Type-correct unfilled coercion hole"
* Refactor the treatment of predicate typesSimon Peyton Jones2018-10-2414-114/+276
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15648 showed that GHC was a bit confused about the difference between the types for * Predicates * Coercions * Evidence (in the typechecker constraint solver) This patch cleans it up. See especially Type.hs Note [Types for coercions, predicates, and evidence] Particular changes * Coercion types (a ~# b) and (a ~#R b) are not predicate types (so isPredTy reports False for them) and are not implicitly instantiated by the type checker. This is a real change, but it consistently reflects that fact that (~#) and (~R#) really are different from predicates. * isCoercionType is renamed to isCoVarType * During type inference, simplifyInfer, we do /not/ want to infer a constraint (a ~# b), because that is no longer a predicate type. So we 'lift' it to (a ~ b). See TcType Note [Lift equality constaints when quantifying] * During type inference for pattern synonyms, we need to 'lift' provided constraints of type (a ~# b) to (a ~ b). See Note [Equality evidence in pattern synonyms] in PatSyn * But what about (forall a. Eq a => a ~# b)? Is that a predicate type? No -- it does not have kind Constraint. Is it an evidence type? Perhaps, but awkwardly so. In the end I decided NOT to make it an evidence type, and to ensure the the type inference engine never meets it. This made me /simplify/ the code in TcCanonical.makeSuperClasses; see TcCanonical Note [Equality superclasses in quantified constraints] Instead I moved the special treatment for primitive equality to TcInteract.doTopReactOther. See TcInteract Note [Looking up primitive equalities in quantified constraints] Also see Note [Evidence for quantified constraints] in Type. All this means I can have isEvVarType ty = isCoVarType ty || isPredTy ty which is nice. All in all, rather a lot of work for a small refactoring, but I think it's a real improvement.
* Improve output from -ddump-typesSimon Peyton Jones2018-10-241-61/+79
| | | | | | | | | | | | | | | | | | This patch makes a number of improvements to the output generated by -ddump-types * Prints data constructor separately * Omits empty chunks of output I was driven initially by the unhelpful existing output for data constructors, but ended up doing some refactoring. Lots of error message wibbles, but nothing significant. Certainly no change in user behaviour. (NB: It is just possible that I have failed to cleanly separate this patch from the next one, about isPredTy and friends.)
* Comments and white spaceSimon Peyton Jones2018-10-241-3/+2
|
* Fix #15792 by not reifying invisible arguments in AppTysRyan Scott2018-10-242-5/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `reifyType` function in `TcSplice` is carefully designed to avoid reifying visible arguments to `TyConApp`s. However, the same care was not given towards the `AppTy` case, which lead to #15792. This patch changes to the `AppTy` case of `reifyType` so that it consults the kind of the function type to determine which of the argument types are invisible (and therefore should be dropped) during reification. This required crafting a variant of `tyConArgFlags`, which I dubbed `appTyArgFlags`, that accept an arbitrary function `Type` instead of a `TyCon`. Test Plan: make test TEST=T15792 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15792 Differential Revision: https://phabricator.haskell.org/D5252
* Keep top-level names in typed TH quotes aliveRyan Scott2018-10-241-7/+14
| | | | | | | | | | | | | | | | | | | | Summary: When renaming untyped TH quotes, some care is taken to ensure that uses of top-level names in quotes do not have their bindings discarded during desugaring. The same care was not applied to typed TH quotes, so this patch brings the two into sync. Test Plan: make test TEST=T15783 Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15783 Differential Revision: https://phabricator.haskell.org/D5248
* Fix #15781 by using ktypedocs on type synonym RHSesRyan Scott2018-10-241-3/+8
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to D5173, which permitted unparenthesized kind signatures in certain places. One place that appeared to be overlooked was the right-hand sides of type synonyms, which this patch addresses by introducing a `ktypedoc` parser production (which is to `ctypdoc` as `ktype` is to `ctype`) and using it in the right place. Test Plan: make test TEST="KindSigs T15781" Reviewers: harpocrates, bgamari Reviewed By: harpocrates Subscribers: rwbarton, mpickering, carter GHC Trac Issues: #15781 Differential Revision: https://phabricator.haskell.org/D5245
* Trigger multiline mode in GHCi on '\case' (#13087)Alec Theriault2018-10-241-0/+1
| | | | | | | | | | | | | | | | | | | Summary: In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten edge case in ALR, since `maybe_layout` (which handles the non-ALR layout) already deals with the 'ITlcase' token properly. Test Plan: make TEST=T10453 && make TEST=T13087 Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #10453, #13087 Differential Revision: https://phabricator.haskell.org/D5236
* Clarify Note about ForAllCo coercions.Richard Eisenberg2018-10-221-4/+17
| | | | Comments only: [skip ci]
* Adding almost devoid check for covar in ForAllCoNingning Xie2018-10-194-23/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For the sake of consistency of the dependent core, there is a restriction on where a coercion variable can appear in ForAllCo: the coercion variable can appear nowhere except in coherence coercions. Currently this restriction is missing in Core. The goal of this patch is to add the missing restriction. After discussion, we decide: coercion variables can appear nowhere except in `GRefl` and `Refl`. Relaxing the restriction to include `Refl` should not break consistency, we premuse. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15757 Differential Revision: https://phabricator.haskell.org/D5231
* Fix #15761 by adding parensRichard Eisenberg2018-10-171-7/+9
| | | | | | This was just a pretty-printer infelicity. Fixed now. Test case: printer/T15761
* Fix BLACKHOLE inspection in RtClosureInspectÖmer Sinan Ağacan2018-10-151-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | When inspecing a BLACKHOLE if the BLACKHOLE points to a TSO or a BLOCKING_QUEUE we should return a suspension to the BLACKHOLE itself (instead of returning a suspension to the indirectee). The reason is because in the debugger when we want to evaluate this term we need to enter the BLACKHOLE and not to the TSO or BLOCKING_QUEUE. See the runtime panic caused by this in #8316. Note that while with this patch we do the right thing to evaluate thunks in GHCi, evaluating thunks that are owned by the evaluator thread in a breakpoint will cause a deadlock as we don't release the breakMVar, which is what blocks the evaluator thread from continuing with evaluation. So the GHCi thread will enter the BLACKHOLE, but owner of the BLACKHOLE is also blocked. Reviewers: simonmar, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #8316 Differential Revision: https://phabricator.haskell.org/D5179
* Generate correct relocation for external cost centreZejun Wu2018-10-151-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to always generate direct access for cost centre labels. We fixed this by generating indirect data load for cost centre defined in external module. Test Plan: The added test used to fail with error message ``` /bin/ld.gold: error: T15723B.o: requires dynamic R_X86_64_PC32 reloc against 'T15723A_foo1_EXPR_cc' which may overflow at runtime; recompile with -fPIC ``` and now passes. Also check that `R_X86_64_PC32` is generated for CostCentre from the same module and `R_X86_64_GOTPCREL` is generated for CostCentre from external module: ``` $ objdump -rdS T15723B.o 0000000000000028 <T15723B_test_info>: 28: 48 8d 45 f0 lea -0x10(%rbp),%rax 2c: 4c 39 f8 cmp %r15,%rax 2f: 72 70 jb a1 <T15723B_test_info+0x79> 31: 48 83 ec 08 sub $0x8,%rsp 35: 48 8d 35 00 00 00 00 lea 0x0(%rip),%rsi # 3c <T15723B_test_info+0x14> 38: R_X86_64_PC32 T15723B_test1_EXPR_cc-0x4 3c: 49 8b bd 60 03 00 00 mov 0x360(%r13),%rdi 43: 31 c0 xor %eax,%eax 45: e8 00 00 00 00 callq 4a <T15723B_test_info+0x22> 46: R_X86_64_PLT32 pushCostCentre-0x4 4a: 48 83 c4 08 add $0x8,%rsp 4e: 48 ff 40 30 incq 0x30(%rax) 52: 49 89 85 60 03 00 00 mov %rax,0x360(%r13) 59: 48 83 ec 08 sub $0x8,%rsp 5d: 49 8b bd 60 03 00 00 mov 0x360(%r13),%rdi 64: 48 8b 35 00 00 00 00 mov 0x0(%rip),%rsi # 6b <T15723B_test_info+0x43> 67: R_X86_64_GOTPCREL T15723A_foo1_EXPR_cc-0x4 6b: 31 c0 xor %eax,%eax 6d: e8 00 00 00 00 callq 72 <T15723B_test_info+0x4a> 6e: R_X86_64_PLT32 pushCostCentre-0x4 72: 48 83 c4 08 add $0x8,%rsp 76: 48 ff 40 30 incq 0x30(%rax) ``` Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15723 Differential Revision: https://phabricator.haskell.org/D5214
View Lorry Controller Status