summaryrefslogtreecommitdiff
path: root/compiler/GHC
Commit message (Collapse)AuthorAgeFilesLines
* Improve error messages for (a %m) without LinearTypesVladislav Zavialov2020-09-291-3/+18
| | | | | | | | Detect when the user forgets to enable the LinearTypes extension and produce a better error message. Steals the (a %m) syntax from TypeOperators, the workaround is to write (a % m) instead.
* New linear types syntax: a %p -> b (#18459)Vladislav Zavialov2020-09-2915-34/+42
| | | | | | Implements GHC Proposal #356 Updates the haddock submodule.
* Linear types: fix kind inference when checking dataconsKrzysztof Gogolewski2020-09-291-1/+3
|
* Optimize NthCo (FunCo ...) in coercion optRichard Eisenberg2020-09-293-28/+39
| | | | | | | | | | We were missing this case previously. Close #18528. Metric Decrease: T18223 T5321Fun
* Remove outdated comment in rnHsTyKiVladislav Zavialov2020-09-271-4/+0
| | | | | This comment dates back to 3df40b7b78044206bbcffe3e2c0a57d901baf5e8 and does not seem relevant anymore.
* Don't rearrange (->) in the renamerVladislav Zavialov2020-09-271-36/+26
| | | | | | | | | | The parser produces an AST where the (->) is already associated correctly: 1. (->) has the least possible precedence 2. (->) is right-associative Thus we don't need to handle it in mkHsOpTyRn.
* Comments: change outdated reference to mergeOpswip/docs-no-merge-opsVladislav Zavialov2020-09-271-1/+1
| | | | | | | As of 686e06c59c3aa6b66895e8a501c7afb019b09e36, GHC.Parser.PostProcess.mergeOps no longer exists. [ci skip]
* Fix handling of function coercions (#18747)Krzysztof Gogolewski2020-09-261-1/+1
| | | | This was broken when we added multiplicity to the function type.
* Disallow linear types in FFI (#18472)Krzysztof Gogolewski2020-09-261-10/+19
|
* Make 'undefined x' linear in 'x' (#18731)Krzysztof Gogolewski2020-09-261-2/+7
|
* Extract SharedIdEnv into its own moduleSebastian Graf2020-09-264-143/+159
| | | | | | It's now named `GHC.Types.Unique.SDFM.UniqSDFM`. The implementation is more clear about its stated goals and supported operations.
* PmCheck: Big refactor of module structureSebastian Graf2020-09-2617-1822/+1993
| | | | | | | | | | | | | | * Move everything from `GHC.HsToCore.PmCheck.*` to `GHC.HsToCore.Pmc.*` in analogy to `GHC.Tc`, rename exported `covCheck*` functions to `pmc*` * Rename `Pmc.Oracle` to `Pmc.Solver` * Split off the LYG desugaring and checking steps into their own modules (`Pmc.Desugar` and `Pmc.Check` respectively) * Split off a `Pmc.Utils` module with stuff shared by `Pmc.{,Desugar,Check,Solver}` * Move `Pmc.Types` to `Pmc.Solver.Types`, add a new `Pmc.Types` module with all the LYG types, which form the interfaces between `Pmc.{Desugar,Check,Solver,}`.
* Fix typed holes causing linearity errors (#18491)Krzysztof Gogolewski2020-09-251-0/+2
|
* Pattern guards BindStmt always use multiplicity ManyArnaud Spiwack2020-09-251-1/+8
| | | | | | | | | Fixes #18439 . The rhs of the pattern guard was consumed with multiplicity one, while the pattern assumed it was Many. We use Many everywhere instead. This is behaviour consistent with that of `case` expression. See #18738.
* Stop removing definitions of record fields in GHC.Iface.Ext.AstZubin Duggal2020-09-251-16/+10
|
* Make sizeExpr strict in the size threshold to facilitate WW.Andreas Klebinger2020-09-251-1/+4
|
* PmCheck: Desugar string literal patterns with -XRebindableSyntax correctly ↵Sebastian Graf2020-09-241-5/+11
| | | | | | (#18708) Fixes #18708.
* Improve kind generalisation, error messagesSimon Peyton Jones2020-09-2416-550/+732
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does two things: * It refactors GHC.Tc.Errors a bit. In debugging Quick Look I was forced to look in detail at error messages, and ended up doing a bit of refactoring, esp in mkTyVarEqErr'. It's still quite a mess, but a bit better, I think. * It makes a significant improvement to the kind checking of type and class declarations. Specifically, we now ensure that if kind checking fails with an unsolved constraint, all the skolems are in scope. That wasn't the case before, which led to some obscure error messages; and occasional failures with "no skolem info" (eg #16245). Both of these, and the main Quick Look patch itself, affect a /lot/ of error messages, as you can see from the number of files changed. I've checked them all; I think they are as good or better than before. Smaller things * I documented the various instances of VarBndr better. See Note [The VarBndr tyep and its uses] in GHC.Types.Var * Renamed GHC.Tc.Solver.simpl_top to simplifyTopWanteds * A bit of refactoring in bindExplicitTKTele, to avoid the footwork with Either. Simpler now. * Move promoteTyVar from GHC.Tc.Solver to GHC.Tc.Utils.TcMType Fixes #16245 (comment 211369), memorialised as typecheck/polykinds/T16245a Also fixes the three bugs in #18640
* Implement Quick Look impredicativitySimon Peyton Jones2020-09-2430-1801/+2774
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Quick Look impredicativity (#18126), sticking very closely to the design in A quick look at impredicativity, Serrano et al, ICFP 2020 The main change is that a big chunk of GHC.Tc.Gen.Expr has been extracted to two new modules GHC.Tc.Gen.App GHC.Tc.Gen.Head which deal with typechecking n-ary applications, and the head of such applications, respectively. Both contain a good deal of documentation. Three other loosely-related changes are in this patch: * I implemented (partly by accident) points (2,3)) of the accepted GHC proposal "Clean up printing of foralls", namely https://github.com/ghc-proposals/ghc-proposals/blob/ master/proposals/0179-printing-foralls.rst (see #16320). In particular, see Note [TcRnExprMode] in GHC.Tc.Module - :type instantiates /inferred/, but not /specified/, quantifiers - :type +d instantiates /all/ quantifiers - :type +v is killed off That completes the implementation of the proposal, since point (1) was done in commit df08468113ab46832b7ac0a7311b608d1b418c4d Author: Krzysztof Gogolewski <krzysztof.gogolewski@tweag.io> Date: Mon Feb 3 21:17:11 2020 +0100 Always display inferred variables using braces * HsRecFld (which the renamer introduces for record field selectors), is now preserved by the typechecker, rather than being rewritten back to HsVar. This is more uniform, and turned out to be more convenient in the new scheme of things. * The GHCi debugger uses a non-standard unification that allows the unification variables to unify with polytypes. We used to hack this by using ImpredicativeTypes, but that doesn't work anymore so I introduces RuntimeUnkTv. See Note [RuntimeUnkTv] in GHC.Runtime.Heap.Inspect Updates haddock submodule. WARNING: this patch won't validate on its own. It was too hard to fully disentangle it from the following patch, on type errors and kind generalisation. Changes to tests * Fixes #9730 (test added) * Fixes #7026 (test added) * Fixes most of #8808, except function `g2'` which uses a section (which doesn't play with QL yet -- see #18126) Test added * Fixes #1330. NB Church1.hs subsumes Church2.hs, which is now deleted * Fixes #17332 (test added) * Fixes #4295 * This patch makes typecheck/should_run/T7861 fail. But that turns out to be a pre-existing bug: #18467. So I have just made T7861 into expect_broken(18467)
* Preliminary work towards removing DynFlags -> Driver.Ppr dependencySylvain Henry2020-09-231-3/+4
|
* Remove sdocWithDynFlags (fix #10143)Sylvain Henry2020-09-232-12/+2
|
* Refactor CLabel pretty-printingSylvain Henry2020-09-2310-224/+203
| | | | | | | | | | * Don't depend on the selected backend to know if we print Asm or C labels: we already have PprStyle to determine this. Moreover even when a native backend is used (NCG, LLVM) we may want to C headers containing pretty-printed labels, so it wasn't a good predicate anyway. * Make pretty-printing code clearer and avoid partiality
* PmCheck: Rewrite inhabitation testSebastian Graf2020-09-228-1225/+1152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to produce inhabitants of a pattern-match refinement type Nabla in the checker in at least two different and mostly redundant ways: 1. There was `provideEvidence` (now called `generateInhabitingPatterns`) which is used by `GHC.HsToCore.PmCheck` to produce non-exhaustive patterns, which produces inhabitants of a Nabla as a sub-refinement type where all match variables are instantiated. 2. There also was `ensure{,All}Inhabited` (now called `inhabitationTest`) which worked slightly different, but was whenever new type constraints or negative term constraints were added. See below why `provideEvidence` and `ensureAllInhabited` can't be the same function, the main reason being performance. 3. And last but not least there was the `nonVoid` test, which tested that a given type was inhabited. We did use this for strict fields and -XEmptyCase in the past. The overlap of (3) with (2) was always a major pet peeve of mine. The latter was quite efficient and proven to work for recursive data types, etc, but could not handle negative constraints well (e.g. we often want to know if a *refined* type is empty, such as `{ x:[a] | x /= [] }`). Lower Your Guards suggested that we could get by with just one, by replacing both functions with `inhabitationTest` in this patch. That was only possible by implementing the structure of φ constraints as in the paper, namely the semantics of φ constructor constraints. This has a number of benefits: a. Proper handling of unlifted types and strict fields, fixing #18249, without any code duplication between `GHC.HsToCore.PmCheck.Oracle.instCon` (was `mkOneConFull`) and `GHC.HsToCore.PmCheck.checkGrd`. b. `instCon` can perform the `nonVoid` test (3) simply by emitting unliftedness constraints for strict fields. c. `nonVoid` (3) is thus simply expressed by a call to `inhabitationTest`. d. Similarly, `ensureAllInhabited` (2), which we called after adding type info, now can similarly be expressed as the fuel-based `inhabitationTest`. See the new `Note [Why inhabitationTest doesn't call generateInhabitingPatterns]` why we still have tests (1) and (2). Fixes #18249 and brings nice metric decreases for `T17836` (-76%) and `T17836b` (-46%), as well as `T18478` (-8%) at the cost of a few very minor regressions (< +2%), potentially due to the fact that `generateInhabitingPatterns` does more work to suggest the minimal COMPLETE set. Metric Decrease: T17836 T17836b
* PmCheck - Comments only: Replace /~ by ≁Sebastian Graf2020-09-223-33/+33
|
* Fix the occurrence analyserSimon Peyton Jones2020-09-222-480/+581
| | | | | | | | | | | | | | | | | | | Ticket #18603 demonstrated that the occurrence analyser's handling of local RULES for imported Ids (which I now call IMP-RULES) was inadequate. It led the simplifier into an infnite loop by failing to label a binder as a loop breaker. The main change in this commit is to treat IMP-RULES in a simple and uniform way: as extra rules for the local binder. See Note [IMP-RULES: local rules for imported functions] This led to quite a bit of refactoring. The result is still tricky, but it's much better than before, and better documented I think. Oh, and it fixes the bug.
* Better eta-expansion (again) and don't specilise DFunsSimon Peyton Jones2020-09-229-571/+759
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes #18223, which made GHC generate an exponential amount of code. There are three quite separate changes in here 1. Re-engineer eta-expansion (again). The eta-expander was generating lots of intermediate stuff, which could be optimised away, but which choked the simplifier meanwhile. Relatively easy to kill it off at source. See Note [The EtaInfo mechanism] in GHC.Core.Opt.Arity. The main new thing is the use of pushCoArg in getArg_maybe. 2. Stop Specialise specalising DFuns. This is the cause of a huge (and utterly unnecessary) blowup in program size in #18223. See Note [Do not specialise DFuns] in GHC.Core.Opt.Specialise. I also refactored the Specialise monad a bit... it was silly, because it passed on unchanging values as if they were mutable state. 3. Do an extra Simplifer run, after SpecConstra and before late-Specialise. I found (investigating perf/compiler/T16473) that failing to do this was crippling *both* SpecConstr *and* Specialise. See Note [Simplify after SpecConstr] in GHC.Core.Opt.Pipeline. This change does mean an extra run of the Simplifier, but only with -O2, and I think that's acceptable. T16473 allocates *three* times less with this change. (I changed it to check runtime rather than compile time.) Some smaller consequences * I moved pushCoercion, pushCoArg and friends from SimpleOpt to Arity, because it was needed by the new etaInfoApp. And pushCoValArg now returns a MCoercion rather than Coercion for the argument Coercion. * A minor, incidental improvement to Core pretty-printing This does fix #18223, (which was otherwise uncompilable. Hooray. But there is still a big intermediate because there are some very deeply nested types in that program. Modest reductions in compile-time allocation on a couple of benchmarks T12425 -2.0% T13253 -10.3% Metric increase with -O2, due to extra simplifier run T9233 +5.8% T12227 +1.8% T15630 +5.0% There is a spurious apparent increase on heap residency on T9630, on some architectures at least. I tried it with -G1 and the residency is essentially unchanged. Metric Increase T9233 T12227 T9630 Metric Decrease T12425 T13253
* Disallow constraints in KindSigCtxtRyan Scott2020-09-211-40/+75
| | | | | | | | | | | | | | | | | | | This patch cleans up how `GHC.Tc.Validity` classifies `UserTypeCtxt`s that can only refer to kind-level positions, which is important for rejecting certain classes of programs. In particular, this patch: * Introduces a new `TypeOrKindCtxt` data type and `typeOrKindCtxt :: UserTypeCtxt -> TypeOrKindCtxt` function, which determines whether a `UserTypeCtxt` can refer to type-level contexts, kind-level contexts, or both. * Defines the existing `allConstraintsAllowed` and `vdqAllowed` functions in terms of `typeOrKindCtxt`, which avoids code duplication and ensures that they stay in sync in the future. The net effect of this patch is that it fixes #18714, in which it was discovered that `allConstraintsAllowed` incorrectly returned `True` for `KindSigCtxt`. Because `typeOrKindCtxt` now correctly classifies `KindSigCtxt` as a kind-level context, this bug no longer occurs.
* Remove unused ThBrackCtxt and ResSigCtxtRyan Scott2020-09-213-12/+0
| | | | Fixes #18715.
* Resolve shift/reduce conflicts with %shift (#17232)wip/parsing-shiftVladislav Zavialov2020-09-191-218/+332
|
* Remove GADT self-reference check (#11554, #12081, #12174, fixes #15942)Artyom Kuznetsov2020-09-191-18/+25
| | | | Reverts 430f5c84dac1eab550110d543831a70516b5cac8
* Export singleton function from Data.ListWander Hillen2020-09-197-15/+15
| | | | | | | | | | | | | | | Data.OldList exports a monomorphized singleton function but it is not re-exported by Data.List. Adding the export to Data.List causes a conflict with a 14-year old function of the same name and type by SPJ in GHC.Utils.Misc. We can't just remove this function because that leads to a problems when building GHC with a stage0 compiler that does not have singleton in Data.List yet. We also can't hide the function in GHC.Utils.Misc since it is not possible to hide a function from a module if the module does not export the function. To work around this, all places where the Utils.Misc singleton was used now use a qualified version like Utils.singleton and in GHC.Utils.Misc we are very specific about which version we export.
* Wire in constraint tuplesRyan Scott2020-09-196-54/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This wires in the definitions of the constraint tuple classes. The key changes are in: * `GHC.Builtin.Types`, where the `mk_ctuple` function is used to define constraint tuple type constructors, data constructors, and superclass selector functions, and * `GHC.Builtin.Uniques`. In addition to wiring in the `Unique`s for constraint tuple type and data constructors, we now must wire in the superclass selector functions. Luckily, this proves to be not that challenging. See the newly added comments. Historical note: constraint tuples used to be wired-in until about five years ago, when commit 130e93aab220bdf14d08028771f83df210da340b turned them into known-key names. This was done as part of a larger refactor to reduce the number of special cases for constraint tuples, but the commit message notes that the main reason that constraint tuples were made known-key (as opposed to boxed/unboxed tuples, which are wired in) is because it was awkward to wire in the superclass selectors. This commit solves the problem of wiring in superclass selectors. Fixes #18635. ------------------------- Metric Decrease: T10421 T12150 T12227 T12234 T12425 T13056 T13253-spj T18282 T18304 T5321FD T5321Fun T5837 T9961 Metric Decrease (test_env='x86_64-linux-deb9-unreg-hadrian'): T12707 Metric Decrease (test_env='x86_64-darwin'): T4029 -------------------------
* rts: Refactor foreign export trackingBen Gamari2020-09-181-10/+21
| | | | | | | | | This avoids calling `libc` in the initializers which are responsible for registering foreign exports. We believe this should avoid the corruption observed in #18548. See Note [Tracking foreign exports] in rts/ForeignExports.c for an overview of the new scheme.
* Remove pprPrec from Outputable (unused)Sylvain Henry2020-09-171-8/+1
|
* Add note about OutputablePSylvain Henry2020-09-171-9/+108
|
* Generalize OutputablePSylvain Henry2020-09-1719-111/+182
| | | | | Add a type parameter for the environment required by OutputableP. It avoids tying Platform with OutputableP.
* Introduce OutputablePSylvain Henry2020-09-1742-700/+777
| | | | | | | | | | | | | | | | | | | | | | | | | Some types need a Platform value to be pretty-printed: CLabel, Cmm types, instructions, etc. Before this patch they had an Outputable instance and the Platform value was obtained via sdocWithDynFlags. It meant that the *renderer* of the SDoc was responsible of passing the appropriate Platform value (e.g. via the DynFlags given to showSDoc). It put the burden of passing the Platform value on the renderer while the generator of the SDoc knows the Platform it is generating the SDoc for and there is no point passing a different Platform at rendering time. With this patch, we introduce a new OutputableP class: class OutputableP a where pdoc :: Platform -> a -> SDoc With this class we still have some polymorphism as we have with `ppr` (i.e. we can use `pdoc` on a variety of types instead of having a dedicated `pprXXX` function for each XXX type). One step closer removing `sdocWithDynFlags` (#10143) and supporting several platforms (#14335).
* Parser.y: clarify treatment of @{-# UNPACK #-}Vladislav Zavialov2020-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, we had this parser production: ftype : ... | ftype PREFIX_AT tyarg { ... } And 'tyarg' is defined as follows: tyarg : atype { ... } | unpackedness atype { ... } So one might get the (false) impression that that parser production is intended to parse things like: F @{-# UNPACK #-} X However, the lexer wouldn't produce PREFIX_AT followed by 'unpackedness', as the '@' operator followed by '{-' is not considered prefix. Thus there's no point using 'tyarg' after PREFIX_AT, and a simple 'atype' will suffice: ftype : ... | ftype PREFIX_AT atype { ... } This change has no user-facing consequences. It just makes the grammar a bit more clear.
* CosmeticLeif Metcalf2020-09-171-1/+1
|
* Make Z-encoding comment into a noteLeif Metcalf2020-09-172-2/+4
|
* Document IfaceTupleTyRichard Eisenberg2020-09-171-0/+5
|
* Do absence analysis on stable unfoldingsSimon Peyton Jones2020-09-173-10/+91
| | | | | | | | | Ticket #18638 showed that Very Bad Things happen if we fail to do absence analysis on stable unfoldings. It's all described in Note [Absence analysis for stable unfoldings and RULES]. I'm a bit surprised this hasn't bitten us before. Fortunately the fix is pretty simple.
* Introduce and use DerivClauseTys (#18662)Ryan Scott2020-09-1511-46/+141
| | | | | | | | | | | | This switches `deriv_clause_tys` so that instead of using a list of `LHsSigType`s to represent the types in a `deriving` clause, it now uses a sum type. `DctSingle` represents a `deriving` clause with no enclosing parentheses, while `DctMulti` represents a clause with enclosing parentheses. This makes pretty-printing easier and avoids confusion between `HsParTy` and the enclosing parentheses in `deriving` clauses, which are different semantically. Fixes #18662.
* Export enrichHie from GHC.Iface.Ext.AstZubin Duggal2020-09-151-1/+1
| | | | This is useful for `ghcide`
* Care with implicit-parameter superclassesSimon Peyton Jones2020-09-1510-81/+159
| | | | | | | | | | | | | | | | | | | | | | Two bugs, #18627 and #18649, had the same cause: we were not account for the fact that a constaint tuple might hide an implicit parameter. The solution is not hard: look for implicit parameters in superclasses. See Note [Local implicit parameters] in GHC.Core.Predicate. Then we use this new function in two places * The "short-cut solver" in GHC.Tc.Solver.Interact.shortCutSolver which simply didn't handle implicit parameters properly at all. This fixes #18627 * The specialiser, which should not specialise on implicit parameters This fixes #18649 There are some lingering worries (see Note [Local implicit parameters]) but things are much better.
* Hackily decouple the parser from the desugarerSebastian Graf2020-09-122-6/+37
| | | | | | | | | | | In a hopefully temporary hack, I re-used the idea from !1957 of using a nullary type family to break the dependency from GHC.Driver.Hooks on the definition of DsM ("Abstract Data"). This in turn broke the last dependency from the parser to the desugarer. More details in `Note [The Decoupling Abstract Data Hack]`. In the future, we hope to undo this hack again in favour of breaking the dependency from the parser to DynFlags altogether.
* Extract definition of DsM into GHC.HsToCore.TypesSebastian Graf2020-09-127-76/+95
| | | | | | | | | | | | | | | | | | `DsM` was previously defined in `GHC.Tc.Types`, along with `TcM`. But `GHC.Tc.Types` is in the set of transitive dependencies of `GHC.Parser`, a set which we aim to minimise. Test case `CountParserDeps` checks for that. Having `DsM` in that set means the parser also depends on the innards of the pattern-match checker in `GHC.HsToCore.PmCheck.Types`, which is the reason we have that module in the first place. In the previous commit, we represented the `TyState` by an `InertSet`, but that pulls the constraint solver as well as 250 more modules into the set of dependencies, triggering failure of `CountParserDeps`. Clearly, we want to evolve the pattern-match checker (and the desugarer) without being concerned by this test, so this patch includes a small refactor that puts `DsM` into its own module.
* Make `tcCheckSatisfiability` incremental (#18645)Sebastian Graf2020-09-124-50/+56
| | | | | | | | | | | | | | | | | By taking and returning an `InertSet`. Every new `TcS` session can then pick up where a prior session left with `setTcSInerts`. Since we don't want to unflatten the Givens (and because it leads to infinite loops, see !3971), we introduced a new variant of `runTcS`, `runTcSInerts`, that takes and returns the `InertSet` and makes sure not to unflatten the Givens after running the `TcS` action. Fixes #18645 and #17836. Metric Decrease: T17977 T18478
* Avoid iterating twice in `zipTyEnv` (#18535)theobat2020-09-122-2/+20
| | | | | | | | | | | | | | | | | | | | | | zipToUFM is a new function to replace `listToUFM (zipEqual ks vs)`. An explicit recursion is preferred due to the sensible nature of fusion. T12227 -6.0% T12545 -12.3% T5030 -9.0% T9872a -1.6% T9872b -1.6% T9872c -2.0% ------------------------- Metric Decrease: T12227 T12545 T5030 T9872a T9872b T9872c -------------------------
* PmCheck: Disattach COMPLETE pragma lookup from TyConsSebastian Graf2020-09-1214-431/+328
| | | | | | | | | | | | | | | | | | | By not attaching COMPLETE pragmas with a particular TyCon and instead assume that every COMPLETE pragma is applicable everywhere, we can drastically simplify the logic that tries to initialise available COMPLETE sets of a variable during the pattern-match checking process, as well as fixing a few bugs. Of course, we have to make sure not to report any of the ill-typed/unrelated COMPLETE sets, which came up in a few regression tests. In doing so, we fix #17207, #18277 and #14422. There was a metric decrease in #18478 by ~20%. Metric Decrease: T18478
View Lorry Controller Status