summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Delete compiler/MachDeps.hJohn Ericson2021-11-121-119/+0
| | | | | | | This was accidentally added back in 28334b475a109bdeb8d53d58c48adb1690e2c9b4 after it is was no longer needed by the compiler proper in 20956e5784fe43781d156dd7ab02f0bff4ab41fb.
* Get the in-scope set right in simplArgSimon Peyton Jones2021-11-121-2/+5
| | | | | This was a simple (but long standing) error in simplArg, revealed by #20639
* Implement -Wforall-identifier (#20609)Vladislav Zavialov2021-11-1211-8/+60
| | | | | | | | | | In accordance with GHC Proposal #281 "Visible forall in types of terms": For three releases before this change takes place, include a new warning -Wforall-identifier in -Wdefault. This warning will be triggered at definition sites (but not use sites) of forall as an identifier. Updates the haddock submodule.
* Use local instances with least superclass depthRichard Eisenberg2021-11-127-82/+180
| | | | | | | | | | See new Note [Use only the best local instance] in GHC.Tc.Solver.Interact. This commit also refactors the InstSC/OtherSC mechanism slightly. Close #20582.
* Improve redundant-constraints warningRichard Eisenberg2021-11-128-93/+158
| | | | | | | | | | | | | | Previously, we reported things wrong with f :: (Eq a, Ord a) => a -> Bool f x = x == x saying that Eq a was redundant. This is fixed now, along with some simplification in Note [Replacement vs keeping]. There's a tiny bit of extra complexity in setImplicationStatus, but it's explained in Note [Tracking redundant constraints]. Close #20602
* Make: Do not generate ghc.* headers in stage0John Ericson2021-11-121-1/+1
| | | | | GHC should get everything it needs from the RTS, which for stage0 is the "old" RTS that comes from the bootstrap compiler.
* Turn GHC.Data.Graph.Base.Graph into a newtypeSimon Jakobi2021-11-121-1/+1
|
* Only pass -pie, -no-pie when linkingMatthew Bauer2021-11-112-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, these flags were passed when both compiling and linking code. However, `-pie` and `-no-pie` are link-time-only options. Usually, this does not cause issues, but when using Clang with `-Werror` set results in errors: clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument] This is unused by Clang because this flag has no effect at compile time (it’s called `-nopie` internally by Clang but called `-no-pie` in GHC for compatibility with GCC). Just passing these flags at linking time resolves this. Additionally, update #15319 hack to look for `-pgml` instead. Because of the main change, the value of `-pgmc` does not matter when checking for the workaround of #15319. However, `-pgml` *does* still matter as not all `-pgml` values support `-no-pie`. To cover all potential values, we assume that no custom `-pgml` values support `-no-pie`. This means that we run the risk of not using `-no-pie` when it is otherwise necessary for in auto-hardened toolchains! This could be a problem at some point, but this workaround was already introduced in 8d008b71 and we might as well continue supporting it. Likewise, mark `-pgmc-supports-no-pie` as deprecated and create a new `-pgml-supports-no-pie`.
* driver: Use shared transitive dependency calculation in hptModulesBelowMatthew Pickering2021-11-111-23/+10
| | | | | | | | | | This saves a lot of repeated work on big dependency graphs. ------------------------- Metric Decrease: MultiLayerModules T13719 -------------------------
* driver: Cache the transitive dependency calculation in ModuleGraphMatthew Pickering2021-11-113-106/+135
| | | | | | | | Two reasons for this change: 1. Avoid computing the transitive dependencies when compiling each module, this can save a lot of repeated work. 2. More robust to forthcoming changes to support multiple home units.
* Fix Note [Function types]Richard Eisenberg2021-11-101-37/+29
| | | | Close #19938.
* Flesh out Note [The stupid context] and reference itRyan Scott2021-11-0913-40/+78
| | | | | | `Note [The stupid context]` in `GHC.Core.DataCon` talks about stupid contexts from `DatatypeContexts`, but prior to this commit, it was rather outdated. This commit spruces it up and references it from places where it is relevant.
* deriving: infer DatatypeContexts from data constructors, not type constructorRyan Scott2021-11-091-13/+24
| | | | | | | | | | | | | | Previously, derived instances that use `deriving` clauses would infer `DatatypeContexts` by using `tyConStupidTheta`. But this sometimes causes redundant constraints to be included in the derived instance contexts, as the constraints that appear in the `tyConStupidTheta` may not actually appear in the types of the data constructors (i.e., the `dataConStupidTheta`s). For instance, in `data Show a => T a = MkT deriving Eq`, the type of `MkT` does not require `Show`, so the derived `Eq` instance should not require `Show` either. This patch makes it so with some small tweaks to `inferConstraintsStock`. Fixes #20501.
* SpecConstr - Attach evaldUnfolding to known evaluated arguments.Andreas Klebinger2021-11-091-31/+153
|
* Default kind vars in tyfams with -XNoPolyKindssheaf2021-11-089-108/+319
| | | | | | | | | | | | | | | We should still default kind variables in type families in the presence of -XNoPolyKinds, to avoid suggesting enabling -XPolyKinds just because the function arrow introduced kind variables, e.g. type family F (t :: Type) :: Type where F (a -> b) = b With -XNoPolyKinds, we should still default `r :: RuntimeRep` in `a :: TYPE r`. Fixes #20584
* Pmc: Do inhabitation test for unlifted vars (#20631)Sebastian Graf2021-11-072-17/+30
| | | | | | | | | | | Although I thought we were already set to handle unlifted datatypes correctly, it appears we weren't. #20631 showed that it's wrong to assume `vi_bot=IsNotBot` for `VarInfo`s of unlifted types from their inception if we don't follow up with an inhabitation test to see if there are any habitable constructors left. We can't trigger the test from `emptyVarInfo`, so now we instead fail early in `addBotCt` for variables of unlifted types. Fixed #20631.
* Print the Type kind qualified when ambiguous (#20627)Vladislav Zavialov2021-11-073-18/+52
| | | | | | | | | | | | | | | The Type kind is printed unqualified: ghci> :set -XNoStarIsType ghci> :k (->) (->) :: Type -> Type -> Type This is the desired behavior unless the user has defined their own Type: ghci> data Type Then we want to resolve the ambiguity by qualification: ghci> :k (->) (->) :: GHC.Types.Type -> GHC.Types.Type -> GHC.Types.Type
* Don't undersaturate join points through eta-reduction.Andreas Klebinger2021-11-072-2/+13
| | | | | | | | In #20599 I ran into an issue where the unfolding for a join point was eta-reduced removing the required lambdas. This patch adds guards that should prevent this from happening going forward.
* Refactor HdkM using deriving viaVladislav Zavialov2021-11-061-27/+14
| | | | | | * No more need for InlineHdkM, mkHdkM * unHdkM is now just a record selector * Update comments
* Make Word64 use Word64# on every architectureSylvain Henry2021-11-062-22/+5
|
* Remove target dependent CPP for Word64/Int64 (#11470)Sylvain Henry2021-11-063-97/+48
| | | | | | | | | | | | | | | | | | | | | | | | | Primops types were dependent on the target word-size at *compiler* compilation time. It's an issue for multi-target as GHC may not have the correct primops types for the target. This patch fixes some primops types: if they take or return fixed 64-bit values they now always use `Int64#/Word64#`, even on 64-bit architectures (where they used `Int#/Word#` before). Users of these primops may now need to convert from Int64#/Word64# to Int#/Word# (a no-op at runtime). This is a stripped down version of !3658 which goes the all way of changing the underlying primitive types of Word64/Int64. This is left for future work. T12545 allocations increase ~4% on some CI platforms and decrease ~3% on AArch64. Metric Increase: T12545 Metric Decrease: T12545
* Fix Int64ToInt/Word64ToWord rules on 32-bit architecturesSylvain Henry2021-11-062-16/+17
| | | | | | When the input literal was larger than 32-bit it would crash in a compiler with assertion enabled because it was creating an out-of-bound word-sized literal (32-bit).
* Add missing Int64/Word64 constant-folding rulesSylvain Henry2021-11-061-0/+16
|
* i386: fix codegen of 64-bit comparisonsSylvain Henry2021-11-061-14/+21
|
* Export `withTcPlugins` and `withHoleFitPlugins`Ziyang Liu2021-11-061-0/+2
|
* Fix boolean confusion with Opt_NoLlvmMangler flagMatthew Pickering2021-11-051-2/+2
| | | | | | | I accidently got the two branches of the if expression the wrong way around when refactoring. Fixes #20567
* Avoid GHC_STAGE and other include bitsJohn Ericson2021-11-058-15/+25
| | | | | | | | | We should strive to make our includes in terms of the RTS as much as possible. One place there that is not possible, the llvm version, we make a new tiny header Stage numbers are somewhat arbitrary, if we simple need a newer RTS, we should say so.
* Allow CApi FFI calls in GHCiMatthew Pickering2021-11-051-1/+2
| | | | | | | | At some point in the past this started working. I noticed this when working on multiple home units and couldn't load GHC's dependencies into the interpreter. Fixes #7388
* Remove record field from SoloSimon Peyton Jones2021-11-052-8/+12
| | | | | | | | | | | | | | Ticket #20562 revealed that Solo, which is a wired-in TyCon, had a record field that wasn't being added to the type env. Why not? Because wired-in TyCons don't have record fields. It's not hard to change that, but it's tiresome for this one use-case, and it seems easier simply to make `getSolo` into a standalone function. On the way I refactored the handling of Solo slightly, to put it into wiredInTyCons (where it belongs) rather than only in knownKeyNames
* Fix deferOutOfScopeVariables for qualified #20472CarrieMY2021-11-051-10/+4
|
* Tiny renamings and doc updatesRichard Eisenberg2021-11-042-54/+55
| | | | Close #20433
* Generalize the type of wrapLocSndMAVladislav Zavialov2021-11-031-4/+13
|
* EPA: Get rid of bare SrcSpan's in the ParsedSourceAlan Zimmerman2021-11-0232-257/+259
| | | | | | | | | | | | | The ghc-exactPrint library has had to re-introduce the relatavise phase. This is needed if you change the length of an identifier and want the layout to be preserved afterwards. It is not possible to relatavise a bare SrcSpan, so introduce `SrcAnn NoEpAnns` for them instead. Updates haddock submodule.
* Fix #20590 with another application of mkHsContextMaybeRyan Scott2021-11-021-17/+15
| | | | | | | | | | | | | | We were always converting empty GADT contexts to `Just []` in `GHC.ThToHs`, which caused the pretty-printer to always print them as `() => ...`. This is easily fixed by using the `mkHsContextMaybe` function when converting GADT contexts so that empty contexts are turned to `Nothing`. This is in the same tradition established in commit 4c87a3d1d14f9e28c8aa0f6062e9c4201f469ad7. In the process of fixing this, I discovered that the `Cxt` argument to `mkHsContextMaybe` is completely unnecessary, as we can just as well check if the `LHsContext GhcPs` argument is empty. Fixes #20590.
* Treat generated RTS headers in a more consistent mannerJohn Ericson2021-11-021-2/+0
| | | | We can depend on all of them at once the same way.
* Remove `includes_GHCCONSTANTS` from make build systemJohn Ericson2021-11-021-1/+0
| | | | It is dead code.
* HsToken for let/in (#19623)Vladislav Zavialov2021-11-0217-56/+58
| | | | One more step towards the new design of EPA.
* Update comment in Lint.hs Andreas Klebinger2021-11-011-1/+1
| | | mkWwArgs has been renamed to mkWorkerArgs.
* ghc: Bump Cabal-Version to 1.22Ben Gamari2021-10-311-1/+1
| | | | This is necessary to use reexported-modules
* ghci: Make getModBreaks robust against DotO UnlinkedBen Gamari2021-10-301-1/+6
| | | | | | | | Previously getModBreaks assumed that an interpreted linkable will have only a single `BCOs` `Unlinked` entry. However, in general an object may also contain `DotO`s; ignore these. Fixes #20570.
* make build system: RTS should use dist-install not distJohn Ericson2021-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This is the following find and replace: - `rts/dist` -> `rts/dist-install` # for paths - `rts_dist` -> `rts_dist-install` # for make rules and vars - `,dist` -> `,dist-install` # for make, just in rts/ghc.mk` Why do this? Does it matter when the RTS is just built once? The answer is, yes, I think it does, because I want the distdir--stage correspondence to be consistent. In particular, for #17191 and continuing from d5de970dafd5876ef30601697576167f56b9c132 I am going to make the headers (`rts/includes`) increasingly the responsibility of the RTS (hence their new location). However, those headers are current made for multiple stages. This will probably become unnecessary as work on #17191 progresses and the compiler proper becomes more of a freestanding cabal package (e.g. a library that can be downloaded from Hackage and built without any autoconf). However, until that is finished, we have will transitional period where the RTS and headers need to agree on dirs for multiple stages. I know the make build system is going away, but it's not going yet, so I need to change it to unblock things :).
* WorkWrap: Update Unfolding with WW'd body prior to `tryWW` (#20510)Sebastian Graf2021-10-293-92/+98
| | | | | | | | | | | | | | | | | | | | We have a function in #20510 that is small enough to get a stable unfolding in WW: ```hs small :: Int -> Int small x = go 0 x where go z 0 = z * x go z y = go (z+y) (y-1) ``` But it appears we failed to use the WW'd RHS as the stable unfolding. As a result, inlining `small` would expose the non-WW'd version of `go`. That appears to regress badly in #19727 which is a bit too large to extract a reproducer from that is guaranteed to reproduce across GHC versions. The solution is to simply update the unfolding in `certainlyWillInline` with the WW'd RHS. Fixes #20510.
* Show family TyCons in mk_dict_error in the case of a single matchZiyang Liu2021-10-291-2/+26
|
* Compiler dosen't need to know about certain settings from fileJohn Ericson2021-10-274-21/+0
| | | | | | | | | | | | - RTS and libdw - SMP - RTS ways I am leaving them in the settings file because `--info` currently prints all the fields in there, but in the future I do believe we should separate the info GHC actually needs from "extra metadata". The latter could go in `+RTS --info` and/or a separate file that ships with the RTS for compile-time inspection instead.
* Change CaseAlt and LambdaExpr to FunRhs in deriving Foldable and Traversable ↵Artyom Kuznetsov2021-10-261-3/+8
| | | | (#20496)
* Don't default type variables in type familiessheaf2021-10-269-48/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes the following defaulting of type variables in type and data families: - type variables of kind RuntimeRep defaulting to LiftedRep - type variables of kind Levity defaulting to Lifted - type variables of kind Multiplicity defaulting to Many It does this by passing "defaulting options" to the `defaultTyVars` function; when calling from `tcTyFamInstEqnGuts` or `tcDataFamInstHeader` we pass options that avoid defaulting. This avoids wildcards being defaulted, which caused type families to unexpectedly fail to reduce. Note that kind defaulting, applicable only with -XNoPolyKinds, is not changed by this patch. Fixes #17536 ------------------------- Metric Increase: T12227 -------------------------
* Warn if unicode bidirectional formatting characters are found in the source ↵Zubin Duggal2021-10-266-3/+127
| | | | (#20263)
* EPA: Use LocatedA for ModuleNameAlan Zimmerman2021-10-249-33/+34
| | | | | This allows us to use an Anchor with a DeltaPos in it when exact printing.
* DmdAnal: Implement Boxity Analysis (#19871)Sebastian Graf2021-10-2413-525/+977
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes some abundant reboxing of `DynFlags` in `GHC.HsToCore.Match.Literal.warnAboutOverflowedLit` (which was the topic of #19407) by introducing a Boxity analysis to GHC, done as part of demand analysis. This allows to accurately capture ad-hoc unboxing decisions previously made in worker/wrapper in demand analysis now, where the boxity info can propagate through demand signatures. See the new `Note [Boxity analysis]`. The actual fix for #19407 is described in `Note [No lazy, Unboxed demand in demand signature]`, but `Note [Finalising boxity for demand signature]` is probably a better entry-point. To support the fix for #19407, I had to change (what was) `Note [Add demands for strict constructors]` a bit (now `Note [Unboxing evaluated arguments]`). In particular, we now take care of it in `finaliseBoxity` (which is only called from demand analaysis) instead of `wantToUnboxArg`. I also had to resurrect `Note [Product demands for function body]` and rename it to `Note [Unboxed demand on function bodies returning small products]` to avoid huge regressions in `join004` and `join007`, thereby fixing #4267 again. See the updated Note for details. A nice side-effect is that the worker/wrapper transformation no longer needs to look at strictness info and other bits such as `InsideInlineableFun` flags (needed for `Note [Do not unbox class dictionaries]`) at all. It simply collects boxity info from argument demands and interprets them with a severely simplified `wantToUnboxArg`. All the smartness is in `finaliseBoxity`, which could be moved to DmdAnal completely, if it wasn't for the call to `dubiousDataConInstArgTys` which would be awkward to export. I spent some time figuring out the reason for why `T16197` failed prior to my amendments to `Note [Unboxing evaluated arguments]`. After having it figured out, I minimised it a bit and added `T16197b`, which simply compares computed strictness signatures and thus should be far simpler to eyeball. The 12% ghc/alloc regression in T11545 is because of the additional `Boxity` field in `Poly` and `Prod` that results in more allocation during `lubSubDmd` and `plusSubDmd`. I made sure in the ticky profiles that the number of calls to those functions stayed the same. We can bear such an increase here, as we recently improved it by -68% (in b760c1f). T18698* regress slightly because there is more unboxing of dictionaries happening and that causes Lint (mostly) to allocate more. Fixes #19871, #19407, #4267, #16859, #18907 and #13331. Metric Increase: T11545 T18698a T18698b Metric Decrease: T12425 T16577 T18223 T18282 T4267 T9961
* driver: Export wWarningFlagMapBen Gamari2021-10-242-5/+6
| | | | | | | | | | A new feature requires Ghcide to be able to convert warnings to CLI flags (WarningFlag -> String). This is most easily implemented in terms of the internal function flagSpecOf, which uses an inefficient implementation based on linear search through a linked list. This PR derives Ord for WarningFlag, and replaces that list with a Map. Closes #19087.
View Lorry Controller Status