summaryrefslogtreecommitdiff
path: root/compiler/GHC
Commit message (Collapse)AuthorAgeFilesLines
* Improve exprOkForSpeculation for classopswip/T22745Simon Peyton Jones2023-01-3118-80/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes #22745 and #15205, which are about GHC's failure to discard unnecessary superclass selections that yield coercions. See GHC.Core.Utils Note [exprOkForSpeculation and type classes] The main changes are: * Write new Note [NON-BOTTOM_DICTS invariant] in GHC.Core, and refer to it * Define new function isTerminatingType, to identify those guaranteed-terminating dictionary types. * exprOkForSpeculation has a new (very simple) case for ClassOpId * ClassOpId has a new field that says if the return type is an unlifted type, or a terminating type. This was surprisingly tricky to get right. In particular note that unlifted types are not terminating types; you can write an expression of unlifted type, that diverges. Not so for dictionaries (or, more precisely, for the dictionaries that GHC constructs). Metric Decrease: LargeRecord
* Take account of loop breakers in specLookupRuleSimon Peyton Jones2023-01-309-49/+69
| | | | | | | | | | | | | | | | | | | | The key change is that in GHC.Core.Opt.Specialise.specLookupRule we were using realIdUnfolding, which ignores the loop-breaker flag. When given a loop breaker, rule matching therefore looped infinitely -- #22802. In fixing this I refactored a bit. * Define GHC.Core.InScopeEnv as a data type, and use it. (Previously it was a pair: hard to grep for.) * Put several functions returning an IdUnfoldingFun into GHC.Types.Id, namely idUnfolding alwaysActiveUnfoldingFun, whenActiveUnfoldingFun, noUnfoldingFun and use them. (The are all loop-breaker aware.)
* Fix two bugs in TypeData TH reificationRyan Scott2023-01-301-6/+22
| | | | | | | | | | | This patch fixes two issues in the way that `type data` declarations were reified with Template Haskell: * `type data` data constructors are now properly reified using `DataConI`. This is accomplished with a special case in `reifyTyCon`. Fixes #22818. * `type data` type constructors are now reified in `reifyTyCon` using `TypeDataD` instead of `DataD`. Fixes #22819.
* Handle `type data` properly in tyThingParent_maybeRyan Scott2023-01-302-8/+24
| | | | | | | | | | | | Unlike most other data constructors, data constructors declared with `type data` are represented in `TyThing`s as `ATyCon` rather than `ADataCon`. The `ATyCon` case in `tyThingParent_maybe` previously did not consider the possibility of the underlying `TyCon` being a promoted data constructor, which led to the oddities observed in #22817. This patch adds a dedicated special case in `tyThingParent_maybe`'s `ATyCon` case for `type data` data constructors to fix these oddities. Fixes #22817.
* compiler: fix data section alignment in the wasm NCGCheng Shao2023-01-301-10/+10
| | | | | | | | | | | | | Previously we tried to lower the alignment requirement as far as possible, based on the section kind inferred from the CLabel. For info tables, .p2align 1 was applied given the GC should only need the lowest bit to tag forwarding pointers. But this would lead to unaligned loads/stores, which has a performance penalty even if the wasm spec permits it. Furthermore, the test suite has shown memory corruption in a few cases when compacting gc is used. This patch takes a more conservative approach: all data sections except C strings align to word size.
* nativeGen: Disable asm-shortcutting on DarwinBen Gamari2023-01-301-0/+15
| | | | | | | | | | | | | Asm-shortcutting may produce relative references to symbols defined in other compilation units. This is not something that MachO relocations support (see #21972). For this reason we disable the optimisation on Darwin. We do so without a warning since this flag is enabled by `-O2`. Another way to address this issue would be to rather implement a PLT-relocatable jump-table strategy. However, this would only benefit Darwin and does not seem worth the effort. Closes #21972.
* compiler: properly handle ForeignHints in the wasm NCGCheng Shao2023-01-281-13/+52
| | | | | Properly handle ForeignHints of ccall arguments/return value, insert sign extends and truncations when handling signed subwords. Fixes #22852.
* Assorted changes to avoid Data.List.{head,tail}Bodigrim2023-01-285-9/+9
|
* compiler: fix lowering of CmmBlock in the wasm NCGCheng Shao2023-01-281-0/+2
| | | | | | | The CmmBlock datacon was not handled in lower_CmmLit, since I thought it would have been eliminated after proc-point splitting. Turns out it still occurs in very rare occasions, and this patch is needed to fix T9329 for wasm.
* compiler: fix subword literal narrowing logic in the wasm NCGCheng Shao2023-01-284-20/+15
| | | | | | This patch fixes the W8/W16 literal narrowing logic in the wasm NCG, which used to lower it to something like i32.const -1, without properly zeroing-out the unused higher bits. Fixes #22608.
* Convert diagnostics in GHC.Rename.Bind to proper TcRnMessage (#20115)Andrei Borzenkov2023-01-284-94/+314
| | | | | | | | | | | | | | | | I removed all occurrences of TcRnUnknownMessage in GHC.Rename.Bind module. Instead, these TcRnMessage messages were introduced: TcRnMultipleFixityDecls TcRnIllegalPatternSynonymDecl TcRnIllegalClassBiding TcRnOrphanCompletePragma TcRnEmptyCase TcRnNonStdGuards TcRnDuplicateSigDecl TcRnMisplacedSigDecl TcRnUnexpectedDefaultSig TcRnBindInBootFile TcRnDuplicateMinimalSig
* CApiFFI: add ConstPtr for encoding const-qualified pointer return typesnineonine2023-01-282-5/+19
| | | | | | | | | | | | | Previously, when using `capi` calling convention in foreign declarations, code generator failed to handle const-cualified pointer return types. This resulted in CC toolchain throwing `-Wincompatible-pointer-types-discards-qualifiers` warning. `Foreign.C.Types.ConstPtr` newtype was introduced to handle these cases - special treatment was put in place to generate appropritetly qualified C wrapper that no longer triggers the above mentioned warning. Fixes #22043.
* Revert "CApiFFI: add ConstPtr for encoding const-qualified pointer return ↵Ben Gamari2023-01-282-19/+5
| | | | | | types (#22043)" This reverts commit 99aca26b652603bc62953157a48e419f737d352d.
* Accept an orphan declaration (sadly)Simon Peyton Jones2023-01-272-0/+8
| | | | | | | | | | This accepts the orphan type family instance type instance DsForeignHook = ... in GHC.HsToCore.Types. See Note [The Decoupling Abstract Data Hack] in GHC.Driver.Hooks
* Avoid orphans in the parserSimon Peyton Jones2023-01-272-5/+6
| | | | | This moves Anno instances for PatBuilder from GHC.Parser.PostProcess to GHC.Parser.Types to avoid orphans.
* Avoid orphans in STGSimon Peyton Jones2023-01-277-111/+146
| | | | | | | This patch removes some orphan instances in the STG namespace by introducing the GHC.Stg.Lift.Types module, which allows various type family instances to be moved to GHC.Stg.Syntax, avoiding orphan instances.
* Report family instance orphans correctlySimon Peyton Jones2023-01-2715-147/+193
| | | | | | | | | | | | | | | | | This fixes the fact that we were not reporting orphan family instances at all. The fix here is easy, but touches a bit of code. I refactored the code to be much more similar to the way that class instances are done: - Add a fi_orphan field to FamInst, like the is_orphan field in ClsInst - Make newFamInst initialise this field, just like newClsInst - And make newFamInst report a warning for an orphan, just like newClsInst - I moved newFamInst from GHC.Tc.Instance.Family to GHC.Tc.Utils.Instantiate, just like newClsInst. - I added mkLocalFamInst to FamInstEnv, just like mkLocalClsInst in InstEnv - TcRnOrphanInstance and SuggestFixOrphanInstance are now parametrised over class instances vs type/data family instances. Fixes #19773
* Detect family instance orphans correctlySimon Peyton Jones2023-01-276-20/+24
| | | | | | | | | We were treating a type-family instance as a non-orphan if there was a type constructor on its /right-hand side/ that was local. Boo! Utterly wrong. With this patch, we correctly check the /left-hand side/ instead! Fixes #22717
* Replace errors from badOrigBinding with new one (#22839)Andrei Borzenkov2023-01-274-54/+29
| | | | | | | | | | | | | | | | | | | | Problem: in 02279a9c the type-level [] syntax was changed from a built-in name to an alias for the GHC.Types.List constructor. badOrigBinding assumes that if a name is not built-in then it must have come from TH quotation, but this is not necessarily the case with []. The outdated assumption in badOrigBinding leads to incorrect error messages. This code: data [] Fails with "Cannot redefine a Name retrieved by a Template Haskell quote: []" Unfortunately, there is not enough information in RdrName to directly determine if the name was constructed via TH or by the parser, so this patch changes the error message instead. It unifies TcRnIllegalBindingOfBuiltIn and TcRnNameByTemplateHaskellQuote into a new error TcRnBindingOfExistingName and changes its wording to avoid guessing the origin of the name.
* Do newtype unwrapping in the canonicaliser and rewriterRichard Eisenberg2023-01-266-79/+193
| | | | | | See Note [Unwrap newtypes first], which has the details. Close #22519.
* Strict fields in ModNodeKey (otherwise retains HomeModInfo)Matthew Pickering2023-01-261-2/+2
| | | | Towards #22530
* Force OccName in tidyTopNameMatthew Pickering2023-01-261-1/+2
| | | | | | | This occname has just been derived from an `Id`, so need to force it promptly so we can release the Id back to the world. Another symptom of the bug caused by #19619
* Force more in NFData Name instanceMatthew Pickering2023-01-261-1/+1
| | | | | | | | | | | Doesn't force the lazy `OccName` field (#19619) which is already known as a really bad source of leaks. When we slam the hammer storing Names on disk (in interface files or the like), all this should be forced as otherwise a `Name` can easily retain an `Id` and hence the entire world. Fixes #22833
* Store dehydrated data structures in CgModBreaksMatthew Pickering2023-01-265-14/+54
| | | | | | | | | This fixes a tricky leak in GHCi where we were retaining old copies of HscEnvs when reloading. If not all modules were recompiled then these hydrated fields in break points would retain a reference to the old HscEnv which could double memory usage. Fixes #22530
* Factorize hptModulesBelowSylvain Henry2023-01-262-35/+33
| | | | | Create and use moduleGraphModulesBelow in GHC.Unit.Module.Graph that doesn't need anything from the driver to be used.
* Fix in-scope set in specImportsSimon Peyton Jones2023-01-251-35/+51
| | | | | | | | | Nothing deep here; I had failed to bring some floated dictionary binders into scope. Exposed by -fspecialise-aggressively Fixes #22715.
* compiler: fix handling of MO_F_Neg in wasm NCGCheng Shao2023-01-253-4/+29
| | | | | | | | In the wasm NCG, we used to compile MO_F_Neg to 0.0-x. It was an oversight, there actually exists f32.neg/f64.neg opcodes in the wasm spec and those should be used instead! The old behavior almost works, expect when GHC compiles the -0.0 literal, which will incorrectly become 0.0.
* CmmToC: fix CmmRegOff for 64-bit register on a 32-bit targetCheng Shao2023-01-241-2/+2
| | | | | | | | | | | | | | | | | We used to print the offset value to a platform word sized integer. This is incorrect when the offset is negative (e.g. output of cmm constant folding) and the register is 64-bit but on a 32-bit target, and may lead to incorrect runtime result (e.g. #22607). The fix is simple: just treat it as a proper MO_Add, with the correct width info inferred from the register itself. Metric Increase: T12707 T13379 T4801 T5321FD T5321Fun
* Fix Lint check for duplicate external namesKrzysztof Gogolewski2023-01-241-6/+5
| | | | | | | | | | Lint was checking for duplicate external names by calling removeDups, which needs a comparison function that is passed to Data.List.sortBy. But the comparison was not a valid ordering - it returned LT if one of the names was not external. For example, the previous implementation won't find a duplicate in [M.x, y, M.x]. Instead, we filter out non-external names before looking for duplicates.
* Debug: Print full NodeKey when pretty printing ModuleGraphNodeMatthew Pickering2023-01-241-1/+1
| | | | This is helpful when debugging multiple component issues.
* Finder: Look in current unit before looking in any home package dependenciesMatthew Pickering2023-01-241-1/+4
| | | | | | | | | | | | | | In order to preserve existing behaviour it's important to look within the current component before consideirng a module might come from an external component. This already happened by accident in `downsweep`, (because roots are used to repopulated the cache) but in the `Finder` the logic was the wrong way around. Fixes #22680 ------------------------- Metric Decrease: MultiComponentModules MultiComponentModulesRecomp -------------------------p
* Key ModSummary cache by UnitId as well as FilePathMatthew Pickering2023-01-241-9/+10
| | | | | | | | | | | | | | | Multiple units can refer to the same files without any problem. Just another assumption which needs to be updated when we may have multiple home units. However, there is the invariant that within each unit each file only maps to one module, so as long as we also key the cache by UnitId then we are all good. This led to some confusing behaviour in GHCi when reloading, multipleHomeUnits_shared distils the essence of what can go wrong. Fixes #22679
* Improve driver diagnostic messages by including UnitId in messageMatthew Pickering2023-01-243-15/+16
| | | | | | | | | | Currently the driver diagnostics don't give any indication about which unit they correspond to. For example `-Wmissing-home-modules` can fire multiple times for each different home unit and gives no indication about which unit it's actually reporting about. Perhaps a longer term fix is to generalise the providence information away from a SrcSpan so that these kind of whole project errors can be reported with an accurate provenance. For now we can just include the `UnitId` in the error message. Fixes #22678
* Don't write o-boot files in Interactive modeMatthew Pickering2023-01-241-15/+27
| | | | | | | | We should not be producing object files when in interactive mode but we still produced the dummy o-boot files. These never made it into a `Linkable` but then confused the recompilation checker. Fixes #22669
* Recompilation checking: Don't try to find artefacts for Interactive & ↵Matthew Pickering2023-01-243-62/+74
| | | | | | | | | | hs-boot combo In interactive mode we don't produce any linkables for hs-boot files. So we also need to not going looking for them when we check to see if we have all the right objects needed for recompilation. Ticket #22669
* Use NodeKey rather than ModuleName in pruneCacheMatthew Pickering2023-01-241-3/+10
| | | | | | | | | | | The `pruneCache` function assumes that the list of `CachedInfo` all have unique `ModuleName`, this is not true: * In normal compilation, the same module name can appear for a file and it's boot file. * In multiple home unit compilation the same ModuleName can appear in different units The fix is to use a `NodeKey` as the actual key for the interfaces which includes `ModuleName`, `IsBoot` and `UnitId`. Fixes #22677
* Augment target filepath by working directory when checking if module ↵Matthew Pickering2023-01-241-1/+1
| | | | | | | | | | | | satisfies target This fixes a spurious warning in -Wmissing-home-modules. This is a simple oversight where when looking for the target in the first place we augment the search by the -working-directory flag but then fail to do so when checking this warning. Fixes #22676
* Fix recompilation checking for multiple home unitsMatthew Pickering2023-01-245-21/+41
| | | | | | | | | | | | | | | The key part of this change is to store a UnitId in the `UsageHomeModule` and `UsageHomeModuleInterface`. * Fine-grained dependency tracking is used if the dependency comes from any home unit. * We actually look up the right module when checking whether we need to recompile in the `UsageHomeModuleInterface` case. These scenarios are both checked by the new tests ( multipleHomeUnits_recomp and multipleHomeUnits_recomp_th ) Fixes #22675
* Fix #22742Simon Peyton Jones2023-01-231-4/+7
| | | | | | | | | | | | | runtimeRepLevity_maybe was panicing unnecessarily; and the error printing code made use of the case when it should return Nothing rather than panicing. For some bizarre reason perf/compiler/T21839r shows a 10% bump in runtime peak-megagbytes-used, on a single architecture (alpine). See !9753 for commentary, but I'm going to accept it. Metric Increase: T21839r
* EPA: Add SourceText to HsOverLabelAlan Zimmerman2023-01-2310-22/+35
| | | | | | To be able to capture string literals with possible escape codes as labels. Close #22771
* Set "since: 9.8" for TypeAbstractions and -Wterm-variable-captureVladislav Zavialov2023-01-231-1/+1
| | | | | These flags did not make it into the 9.6 release series, so the "since" annotations must be corrected.
* Fix printing of promoted MkSolo datacon (#22785)Andrei Borzenkov2023-01-185-10/+14
| | | | | | | | | | | | Problem: In 2463df2f, the Solo data constructor was renamed to MkSolo, and Solo was turned into a pattern synonym for backwards compatibility. Since pattern synonyms can not be promoted, the old code that pretty-printed promoted single-element tuples started producing ill-typed code: t :: Proxy ('Solo Int) This fails with "Pattern synonym ‘Solo’ used as a type" The solution is to track the distinction between type constructors and data constructors more carefully when printing single-element tuples.
* nativeGen/X86: MFENCE is unnecessary for release semanticsBen Gamari2023-01-181-1/+1
| | | | | | | | | | | In #22764 a user noticed that a program implementing a simple atomic counter via an STRef regressed significantly due to the introduction of necessary atomic operations in the MutVar# primops (#22468). This regression was caused by a bug in the NCG, which emitted an unnecessary MFENCE instruction for a release-ordered atomic write. MFENCE is rather only needed to achieve sequentially consistent ordering. Fixes #22764.
* ghc package does not have to depend on terminfoBodigrim2023-01-181-22/+7
|
* Minor corrections to commentsAdam Gundry2023-01-181-4/+4
|
* Refactor warning flag parsing to add missing flagsAdam Gundry2023-01-183-92/+112
| | | | | | | | This adds `-Werror=<group>` and `-fwarn-<group>` flags for warning groups as well as individual warnings. Previously these were defined on an ad hoc basis so for example we had `-Werror=compat` but not `-Werror=unused-binds`, whereas we had `-fwarn-unused-binds` but not `-fwarn-compat`. Fixes #22182.
* Add PrimCallConv support to GHCiLuite Stegeman2023-01-188-129/+346
| | | | | | | | | | | | | This adds support for calling Cmm code from bytecode using the native calling convention, allowing modules that use `foreign import prim` to be loaded and debugged in GHCi. This patch introduces a new `PRIMCALL` bytecode instruction and a helper stack frame `stg_primcall`. The code is based on the existing functionality for dealing with unboxed tuples in bytecode, which has been generalised to handle arbitrary calls. Fixes #22051
* Add missing parenthesizeHsType in cvtSigTypeKindRyan Scott2023-01-181-1/+1
| | | | | | | | We need to ensure that the output of `cvtSigTypeKind` is parenthesized (at precedence `sigPrec`) so that any type signatures with an outermost, explicit kind signature can parse correctly. Fixes #22784.
* Enable -Wstar-is-type by default (#22759)Vladislav Zavialov2023-01-182-3/+2
| | | | | | | | | | | | | Following the plan in GHC Proposal #143 "Remove the * kind syntax", which states: In the next release (or 3 years in), enable -fwarn-star-is-type by default. The "next release" happens to be 9.6.1 I also moved the T21583 test case from should_fail to should_compile, because the only reason it was failing was -Werror=compat in our test suite configuration.
* Document the semantics of pattern bindings a bit betterSimon Peyton Jones2023-01-172-29/+80
| | | | This MR is in response to the discussion on #22719
View Lorry Controller Status