summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* More support for optional home-unitSylvain Henry2021-11-2015-133/+170
| | | | | | | | | This is a preliminary refactoring for #14335 (supporting plugins in cross-compilers). In many places the home-unit must be optional because there won't be one available in the plugin environment (we won't be compiling anything in this environment). Hence we replace "HomeUnit" with "Maybe HomeUnit" in a few places and we avoid the use of "hsc_home_unit" (which is partial) in some few others.
* Remove unused module import syntax from .bkp modeMatthew Pickering2021-11-203-27/+7
| | | | | | | | | | | | | | | .bkp mode had this unused feature where you could write module A and it would go looking for A.hs on the file system and use that rather than provide the definition inline. This isn't use anywhere in the testsuite and the code to find the module A looks dubious. Therefore to reduce .bkp complexity I propose to remove it. Fixes #20701
* Add one line of comments (c.f. !5706)Simon Peyton Jones2021-11-181-0/+1
| | | | | | | Ticket #19815 suggested changing coToMCo to use isReflexiveCo rather than isReflCo. But perf results weren't encouraging. This patch just adds a comment to point to the data, such as it is.
* Improve handling of import statements in GHCi (#20473)Morrow2021-11-171-4/+10
| | | | | | | | | | | | | | | | Currently in GHCi, when given a line of user input we: 1. Attempt to parse and handle it as a statement 2. Otherwise, attempt to parse and handle a single import 3. Otherwise, check if there are imports present (and if so display an error message) 4. Otherwise, attempt to parse a module and only handle the declarations This patch simplifies the process to: Attempt to parse and handle it as a statement Otherwise, attempt to parse a module and handle the imports and declarations This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).
* Pmc: Don't case split on wildcard matches (#20642)Sebastian Graf2021-11-172-41/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 8.10, when formatting a pattern match warning, we'd case split on a wildcard match such as ```hs foo :: [a] -> [a] foo [] = [] foo xs = ys where (_, ys@(_:_)) = splitAt 0 xs -- Pattern match(es) are non-exhaustive -- In a pattern binding: -- Patterns not matched: -- ([], []) -- ((_:_), []) ``` But that's quite verbose and distracts from which part of the pattern was actually the inexhaustive one. We'd prefer a wildcard for the first pair component here, like it used to be in GHC 8.8. On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the different constructors we could've matched on: ```hs f :: Bool -> () f x = case x of {} -- Pattern match(es) are non-exhaustive -- In a pattern binding: -- Patterns not matched: -- False -- True ``` The solution is to communicate that we want a top-level case split to `generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what this patch arranges. Details in `Note [Case split inhabiting patterns]`. Fixes #20642.
* Increase type sharingBen Gamari2021-11-1723-265/+453
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #20541 by making mkTyConApp do more sharing of types. In particular, replace * BoxedRep Lifted ==> LiftedRep * BoxedRep Unlifted ==> UnliftedRep * TupleRep '[] ==> ZeroBitRep * TYPE ZeroBitRep ==> ZeroBitType In each case, the thing on the right is a type synonym for the thing on the left, declared in ghc-prim:GHC.Types. See Note [Using synonyms to compress types] in GHC.Core.Type. The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely in the same spirit as the other ones. (These synonyms are mainly for internal use, though the programmer can use them too.) I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be compatible with the "zero-bit" nomenclature above. See discussion on !6806. There is a tricky wrinkle: see GHC.Core.Types Note [Care using synonyms to compress types] Compiler allocation decreases by up to 0.8%.
* Make: Get rid of `BUILD_.*_INCLUDE_DIRS`John Ericson2021-11-161-10/+2
| | | | | | | | | | | | | | | First, we improve some of the rules around -I include dirs, and CPP opts. Then, we just specify the RTS's include dirs normally (locally per the package and in the package conf), and then everything should work normally. The primops.txt.pp rule needs no extra include dirs at all, as it no longer bakes in a target platfom. Reverts some of the extra stage arguments I added in 05419e55cab272ed39790695f448b311f22669f7, as they are no longer needed.
* Fix windres invocationSylvain Henry2021-11-151-6/+5
| | | | | I've already fixed this 7 months ago in the comments of #16780 but it never got merged. Now we need this for #20657 too.
* Delete dead code knobs for building GHC itselfJohn Ericson2021-11-152-83/+0
| | | | | As GHC has become target agnostic, we've left behind some now-useless logic in both build systems.
* Make: Get rid of GHC_INCLUDE_DIRSJohn Ericson2021-11-151-5/+4
| | | | | | These dirs should not be included in all stages. Instead make the per-stage `BUILD_*_INCLUDE_DIR` "plural" to insert `rts/include` in the right place.
* Instantiate field types properly in stock-derived instancesRyan Scott2021-11-157-244/+400
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the `deriving` machinery was very loosey-goosey about how it used the types of data constructor fields when generating code. It would usually just consult `dataConOrigArgTys`, which returns the _uninstantiated_ field types of each data constructor. Usually, you can get away with this, but issues #20375 and #20387 revealed circumstances where this approach fails. Instead, when generated code for a stock-derived instance `C (T arg_1 ... arg_n)`, one must take care to instantiate the field types of each data constructor with `arg_1 ... arg_n`. The particulars of how this is accomplished is described in the new `Note [Instantiating field types in stock deriving]` in `GHC.Tc.Deriv.Generate`. Some highlights: * `DerivInstTys` now has a new `dit_dc_inst_arg_env :: DataConEnv [Type]` field that caches the instantiated field types of each data constructor. Whenever we need to consult the field types somewhere in `GHC.Tc.Deriv.*` we avoid using `dataConOrigArgTys` and instead look it up in `dit_dc_inst_arg_env`. * Because `DerivInstTys` now stores the instantiated field types of each constructor, some of the details of the `GHC.Tc.Deriv.Generics.mkBindsRep` function were able to be simplified. In particular, we no longer need to apply a substitution to instantiate the field types in a `Rep(1)` instance, as that is already done for us by `DerivInstTys`. We still need a substitution to implement the "wrinkle" section of `Note [Generating a correctly typed Rep instance]`, but the code is nevertheless much simpler than before. * The `tyConInstArgTys` function has been removed in favor of the new `GHC.Core.DataCon.dataConInstUnivs` function, which is really the proper tool for the job. `dataConInstUnivs` is much like `tyConInstArgTys` except that it takes a data constructor, not a type constructor, as an argument, and it adds extra universal type variables from that data constructor at the end of the returned list if need be. `dataConInstUnivs` takes care to instantiate the kinds of the universal type variables at the end, thereby avoiding a bug in `tyConInstArgTys` discovered in https://gitlab.haskell.org/ghc/ghc/-/issues/20387#note_377037. Fixes #20375. Fixes #20387.
* Refactoring: Move DataConEnv to GHC.Core.DataConRyan Scott2021-11-152-2/+5
| | | | | `DataConEnv` will prove to be useful in another place besides `GHC.Core.Opt.SpecConstr` in a follow-up commit.
* Refactoring: Consolidate some arguments with DerivInstTysRyan Scott2021-11-155-141/+135
| | | | | | | | | | | Various functions in GHC.Tc.Deriv.* were passing around `TyCon`s and `[Type]`s that ultimately come from the same `DerivInstTys`. This patch moves the definition of `DerivInstTys` to `GHC.Tc.Deriv.Generate` so that all of these `TyCon` and `[Type]` arguments can be consolidated into a single `DerivInstTys`. Not only does this make the code easier to read (in my opinion), this will also be important in a subsequent commit where we need to add another field to `DerivInstTys` that will also be used from `GHC.Tc.Deriv.Generate` and friends.
* Remove bit about size_t in ghc-llvm-version.hJohn Ericson2021-11-121-2/+0
| | | | | This shouldn't be here. It wasn't causing a problem because this header was only used from Haskell, but still.
* 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.
View Lorry Controller Status