summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Pmc: Do inhabitation test for unlifted vars (#20631)wip/T20631Sebastian Graf2021-11-074-17/+56
| | | | | | | | | | | 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.
* Don't default type variables in type familiessheaf2021-10-2624-101/+227
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-2610-3/+156
| | | | (#20263)
* Tweak descriptions of lines and unlinesViktor Dukhovni2021-10-251-19/+17
| | | | | It seems more clear to think of lines as LF-terminated rather than LF-separated.
* Remove stray reference to `dist-ghcconstants`John Ericson2021-10-251-1/+1
| | | | | I think this hasn't been a thing since 86054b4ab5125a8b71887b06786d0a428539fb9c, almost 10 years ago!
* Fix dangling reference to RtsConfig.hJohn Ericson2021-10-241-1/+1
| | | | | It hasn't existed since a2a67cd520b9841114d69a87a423dabcb3b4368e -- in 2009!
* undefined: Neater CallStack in error messageJoachim Breitner2021-10-2415-22/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Users of `undefined` don’t want to see ``` files.hs: Prelude.undefined: CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at file.hs:151:19 in main:Main ``` but want to see ``` files.hs: Prelude.undefined: CallStack (from HasCallStack): undefined, called at file.hs:151:19 in main:Main ``` so let’s make that so. The function for that is `withFrozenCallStack`, but that is not usable here (module dependencies, and also not representation-polymorphic). And even if it were, it could confuse GHC’s strictness analyzer, leading to big regressions in some perf tests (T10421 in particular). So after shuffling modules and definitions around, I eventually noticed that the easiest way is to just not call `error` here. Fixes #19886
* EPA: Use LocatedA for ModuleNameAlan Zimmerman2021-10-2422-58/+59
| | | | | This allows us to use an Anchor with a DeltaPos in it when exact printing.
* DmdAnal: Implement Boxity Analysis (#19871)Sebastian Graf2021-10-2465-963/+1883
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* WorkWrap: `isRecDataCon` should not eta-reduce NewTyCon field tys (#20539)Sebastian Graf2021-10-223-2/+11
| | | | | | | | | | | | | In #20539 we had a type ```hs newtype Measured a = Measured { unmeasure :: () -> a } ``` and `isRecDataCon Measured` recursed into `go_arg_ty` for `(->) ()`, because `unwrapNewTyConEtad_maybe` eta-reduced it. That triggered an assertion error a bit later. Eta reducing the field type is completely wrong to do here! Just call `unwrapNewTyCon_maybe` instead. Fixes #20539 and adds a regression test T20539.
* driver: Don't use the log queue abstraction when j = 1Matthew Pickering2021-10-221-23/+44
| | | | | | This simplifies the code path for -j1 by not using the log queue queue abstraction. The result is that trace output isn't interleaved with other dump output like it can be with -j<N>.
* Fix compilerConfig stagesHaochen Tong2021-10-221-1/+1
| | | | | Fix the call to compilerConfig because it accepts 1-indexed stage numbers. Also fixes `make stage=3`.
* Refactor package importsSylvain Henry2021-10-2236-196/+324
| | | | | | | | | Use an (Raw)PkgQual datatype instead of `Maybe FastString` to represent package imports. Factorize the code that renames RawPkgQual into PkgQual in function `rnPkgQual`. Renaming consists in checking if the FastString is the magic "this" keyword, the home-unit unit-id or something else. Bump haddock submodule
* Remove IndefiniteSylvain Henry2021-10-2214-89/+60
| | | | We no longer need it after previous IndefUnitId refactoring.
* Add test for #19641Sylvain Henry2021-10-223-0/+44
| | | | | | | Now that Bignum predicates are inlined (!6696), we only need to add a test. Fix #19641
* Use tcEqType in GHC.Core.Unify.uVarsheaf2021-10-2213-10/+73
| | | | | | | | | | | | | | | | | Because uVar used eqType instead of tcEqType, it was possible to accumulate a substitution that unified Type and Constraint. For example, a call to `tc_unify_tys` with arguments tys1 = [ k, k ] tys2 = [ Type, Constraint ] would first add `k = Type` to the substitution. That's fine, but then the second call to `uVar` would claim that the substitution also unifies `k` with `Constraint`. This could then be used to cause trouble, as per #20521. Fixes #20521
* Do not sign extend CmmInt's unless negative.Moritz Angermann2021-10-221-0/+5
| | | Might fix #20526.
* Document that `InScopeSet` is a superset of currently in-scope variablesZiyang Liu2021-10-222-2/+24
|
* instance Ord Name: Do not repeat default methodsJoachim Breitner2021-10-201-5/+1
| | | | | | it is confusing to see what looks like it could be clever code, only to see that it does precisely the same thing as the default methods. Cleaning this up, to spare future readers the confusion.
* ci: Move hlint jobs from quick-built into full-buildMatthew Pickering2021-10-201-1/+1
| | | | | | | | | This somewhat fixes the annoyance of not getting any "useful" feedback from a CI pipeline if you have a hlint failure. Now the hlint job runs in parallel with the other CI jobs so the feedback is recieved at the same time as other testsuite results. Fixes #20507
* Make sure ModIface values are still forced even if not writtenMatthew Pickering2021-10-202-4/+45
| | | | | | | | | | | | | | | | | | When we are not writing a ModIface to disk then the result can retain a lot of stuff. For example, in the case I was debugging the DocDeclsMap field was holding onto the entire HomePackageTable due to a single unforced thunk. Therefore, now if we're not going to write the interface then we still force deeply it in order to remove these thunks. The fields in the data structure are not made strict because when we read the field from the interface we don't want to load it immediately as there are parts of an interface which are unused a lot of the time. Also added a note to explain why not all the fields in a ModIface field are strict. The result of this is being able to load Agda in ghci and not leaking information across subsequent reloads.
* Bignum: allow Integer's signum to inline (#20361)Sylvain Henry2021-10-203-8/+0
| | | | | | | | Allow T12545 to increase because it only happens on CI with dwarf enabled and probably not related to this patch. Metric Increase: T12545
* Bignum: allow Integer predicates to inline (#20361)Sylvain Henry2021-10-205-104/+57
| | | | | | | | | T17516 allocations increase by 48% because Integer's predicates are inlined in some Ord instance methods. These methods become too big to be inlined while they probably should: this is tracked in #20516. Metric Increase: T17516
* Bignum: constant folding for bigNatCompareWord# (#20361)Sylvain Henry2021-10-203-2/+8
|
* Make fields of GlobalRdrElt strictMatthew Pickering2021-10-208-33/+50
| | | | | | | | In order to do this I thought it was prudent to change the list type to a bag type to avoid doing a lot of premature work in plusGRE because of ++. Fixes #19201
* Distribute HomeModInfo cache before starting upsweepMatthew Pickering2021-10-201-15/+13
| | | | | | | | | | This change means the HomeModInfo cache isn't retained until the end of upsweep and each cached interface can be collected immediately after its module is compiled. The result is lower peak memory usage when using GHCi. For Agda it reduced peak memory usage from about 1600M to 1200M.
* Fix perf-nofib CI jobMatthew Pickering2021-10-202-8/+8
| | | | | | | | The main change is to install the necessary build dependencies into an environment file using `caball install --lib`. Also updates the nofib submodule with a few fixes needed for the job to work.
* hadrian: Fix binary-dist support for cross-compilersBen Gamari2021-10-203-8/+15
| | | | | | | | | Previously the logic which called ghc-pkg failed to account for the fact that the executable name may be prefixed with a triple. Moreover, the call must occur before we delete the settings file as ghc-pkg needs the latter. Fixes #20267.
* hadrian/doc: Add margin to staged-compilation figureBen Gamari2021-10-201-177/+203
|
* Add note about heap invariants [skip ci]Matthew Pickering2021-10-202-0/+31
| | | | | At the moment the note just covers three important invariants but now there is a place to add more to if we think of them.
* hadrian: Fix quoting in binary distribution installation MakefileBen Gamari2021-10-191-4/+4
| | | | | Previously we failed to quote various paths in Hadrian's installation Makefile, resulting in #20506.
* Fix #19884: add warning to tags command, drop T10989Emily Martins2021-10-195-24/+2
|
* Don't print Shake Diagnostic messages (#20484)Zubin Duggal2021-10-191-0/+5
|
* Care about specificity in pattern type argsRichard Eisenberg2021-10-196-4/+40
| | | | Close #20443.
* Add performance test for ghci, -fno-code and reloading (#20509)Matthew Pickering2021-10-193-0/+48
| | | | | | This test triggers the bad code path identified by #20509 where an entry into the EPS caused by importing Control.Applicative will retain a stale HomePackageTable.
* Temporary fix for leak with -fno-code (#20509)Matthew Pickering2021-10-192-10/+13
| | | | | | | | | | | | | | | | | | This hack inserted for backpack caused a very bad leak when using -fno-code where EPS entries would end up retaining stale HomePackageTables. For any interactive user, such as HLS, this is really bad as once the entry makes it's way into the EPS then it's there for the rest of the session. This is a temporary fix which "solves" the issue by filtering the HPT to only the part which is needed for the hack to work, but in future we want to separate out hole modules from the HPT entirely to avoid needing to do this kind of special casing. ------------------------- Metric Decrease: MultiLayerModulesDefsGhci -------------------------
* Make the fields of Target and TargetId strictMatthew Pickering2021-10-191-6/+8
| | | | | | | | | | | Targets are long-lived through GHC sessions so we don't want to end up retaining In particular in 'guessTarget', the call to `unitIdOrHomeUnit` was retaining reference to an entire stale HscEnv, which in turn retained reference to a stale HomePackageTable. Making the fields strict forces that place promptly and helps ensure that mistakes like this don't happen again.
* Add test for T20509Matthew Pickering2021-10-199-0/+80
| | | | | | This test checks to see whether a signature can depend on another home module. Whether it should or not is up for debate, see #20509 for more details.
* InteractiveContext: Smarter caching when rebuilding the ic_rn_gbl_envJoachim Breitner2021-10-195-37/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | The GlobalRdrEnv of a GHCI session changes in odd ways: New bindings are not just added "to the end", but also "in the middle", namely when changing the set of imports: These are treated as if they happened before all bindings from the prompt, even those that happened earlier. Previously, this meant that the `ic_rn_gbl_env` is recalculated from the `ic_tythings`. But this wasteful if `ic_tythings` has many entries that define the same unqualified name. By separately keeping track of a `GlobalRdrEnv` of all the locally defined things we can speed this operation up significantly. This change improves `T14052Type` by 60% (It used to be 70%, but it looks that !6723 already reaped some of the rewards). But more importantly, it hopefully unblocks #20455, becaues with this smarter caching, the change needed to fix that issue will no longer make `T14052` explode. I hope. It does regress `T14052` by 30%; caching isn’t free. Oh well. Metric Decrease: T14052Type Metric Increase: T14052
* Remove DT_Failed stateMatthew Pickering2021-10-1932-151/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment if `-dynamic-too` fails then we rerun the whole pipeline as if we were just in `-dynamic` mode. I argue this is a misfeature and we should remove the so-called `DT_Failed` mode. In what situations do we fall back to `DT_Failed`? 1. If the `dyn_hi` file corresponding to a `hi` file is missing completely. 2. If the interface hash of `dyn_hi` doesn't match the interface hash of `hi`. What happens in `DT_Failed` mode? * The whole compiler pipeline is rerun as if the user had just passed `-dynamic`. * Therefore `dyn_hi/dyn_o` files are used which don't agree with the `hi/o` files. (As evidenced by `dynamicToo001` test). * This is very confusing as now a single compiler invocation has produced further `hi`/`dyn_hi` files which are different to each other. Why should we remove it? * In `--make` mode, which is predominately used `DT_Failed` does not work (#19782), there can't be users relying on this functionality. * In `-c` mode, the recovery doesn't fix the root issue, which is the `dyn_hi` and `hi` files are mismatched. We should instead produce an error and pass responsibility to the build system using `-c` to ensure that the prerequisites for `-dynamic-too` (dyn_hi/hi) files are there before we start compiling. * It is a misfeature to support use cases like `dynamicToo001` which allow you to mix different versions of dynamic/non-dynamic interface files. It's more likely to lead to subtle bugs in your resulting programs where out-dated build products are used rather than a deliberate choice. * In practice, people are usually compiling with `-dynamic-too` rather than separately with `-dynamic` and `-static`, so the build products always match and `DT_Failed` is only entered due to compiler bugs (see !6583) What should we do instead? * In `--make` mode, for home packages check during recompilation checking that `dyn_hi` and `hi` are both present and agree, recompile the modules if they do not. * For package modules, when loading the interface check that `dyn_hi` and `hi` are there and that they agree but fail with an error message if they are not. * In `--oneshot` mode, fail with an error message if the right files aren't already there. Closes #19782 #20446 #9176 #13616
* driver: Correct output of -fno-code and -dynamic-tooMatthew Pickering2021-10-197-11/+30
| | | | | | | | | | | | | Before we would print [1 of 3] Compiling T[boot] ( T.hs-boot, nothing, T.dyn_o ) Which was clearly wrong for two reasons. 1. No dynamic object file was produced for T[boot] 2. The file would be called T.dyn_o-boot if it was produced. Fixes #20300
* driver: Cleanups related to ModLocationMatthew Pickering2021-10-1929-203/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ModLocation is the data type which tells you the locations of all the build products which can affect recompilation. It is now computed in one place and not modified through the pipeline. Important locations will now just consult ModLocation rather than construct the dynamic object path incorrectly. * Add paths for dynamic object and dynamic interface files to ModLocation. * Always use the paths from mod location when looking for where to find any interface or object file. * Always use the paths in a ModLocation when deciding where to write an interface and object file. * Remove `dynamicOutputFile` and `dynamicOutputHi` functions which *calculated* (incorrectly) the location of `dyn_o` and `dyn_hi` files. * Don't set `outputFile_` and so-on in `enableCodeGenWhen`, `-o` and hence `outputFile_` should not affect the location of object files in `--make` mode. It is now sufficient to just update the ModLocation with the temporary paths. * In `hscGenBackendPipeline` don't recompute the `ModLocation` to account for `-dynamic-too`, the paths are now accurate from the start of the run. * Rename `getLocation` to `mkOneShotModLocation`, as that's the only place it's used. Increase the locality of the definition by moving it close to the use-site. * Load the dynamic interface from ml_dyn_hi_file rather than attempting to reconstruct it in load_dynamic_too. * Add a variety of tests to check how -o -dyno etc interact with each other. Some other clean-ups * DeIOify mkHomeModLocation and friends, they are all pure functions. * Move FinderOpts into GHC.Driver.Config.Finder, next to initFinderOpts. * Be more precise about whether we mean outputFile or outputFile_: there were many places where outputFile was used but the result shouldn't have been affected by `-dyno` (for example the filename of the resulting executable). In these places dynamicNow would never be set but it's still more precise to not allow for this possibility. * Typo fixes suffices -> suffixes in the appropiate places.
* WW: Use module name rather than filename for absent error messagesMatthew Pickering2021-10-193-11/+12
| | | | | | | | | | | | | WwOpts in WorkWrap.Utils initialised the wo_output_file field with the result of outputFile dflags. This is misguided because outputFile is only set when -o is specified, which is barely ever (and never in --make mode). It seems this is just used to add more context to an error message, a more appropriate thing to use I think would be a module name. Fixes #20438
* Add test for implicit dynamic tooMatthew Pickering2021-10-195-0/+61
| | | | | This test checks that we check for missing dynamic objects if dynamic-too is enabled implicitly by the driver.
* dynamic-too: Check the dynamic-too status in hscPipelineMatthew Pickering2021-10-191-9/+9
| | | | | This "fixes" DT_Failed in --make mode, but only "fixes" because I still believe DT_Failed is pretty broken.
* driver: Update cached DynFlags in ModSummary if we are enabling -dynamic-tooMatthew Pickering2021-10-191-3/+4
|
* driver: Check the correct flag to see if dynamic-too is enabled.Matthew Pickering2021-10-191-4/+4
| | | | | We just need to check the flag here rather than read the variable which indicates whether dynamic-too compilation has failed.
* dynamic-too: Expand GHC.Iface.Recomp comment about the backpack hackMatthew Pickering2021-10-191-4/+11
|
* tests: Remove $(CABAL_MINIMAL_CONFIGURATION) from T16219Matthew Pickering2021-10-192-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | There is a latent issue in T16219 where -dynamic-too is enabled when compiling a signature file which causes us to enter the DT_Failed state because library-a-impl doesn't generate dyn_o files. Somehow this used to work in 8.10 (that also entered the DT_Failed state) We don't need dynamic object files when compiling a signature file but the code loads interfaces, and if dynamic-too is enabled then it will also try to load the dyn_hi file and check the two are consistent. There is another hack to do with this in `GHC.Iface.Recomp`. The fix for this test is to remove CABAL_MINIMAL_CONFIGURATION, which stops cabal building shared libraries by default. I'm of the opinion that the DT_Failed state indicates an error somewhere so we should hard fail rather than this confusing (broken) rerun logic. Whether this captures the original intent of #16219 is debateable, but it's not clear how it was supposed to work in the first place if the libraries didn't build dynamic object files. Module C imports module A, which is from a library where shared objects are not built so the test would never have worked anyway (if anything from A was used in a TH splice).
View Lorry Controller Status