summaryrefslogtreecommitdiff
path: root/testsuite
Commit message (Collapse)AuthorAgeFilesLines
* Fix #20590 with another application of mkHsContextMaybeRyan Scott2021-11-023-0/+13
| | | | | | | | | | | | | | 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.
* HsToken for let/in (#19623)Vladislav Zavialov2021-11-023-7/+18
| | | | One more step towards the new design of EPA.
* Bignum: add missing ruleSylvain Henry2021-10-291-17/+11
| | | | Add missing "Natural -> Integer -> Word#" rule.
* Add test for T15547 (#15547)Sylvain Henry2021-10-293-0/+74
| | | | Fix #15547
* WorkWrap: Update Unfolding with WW'd body prior to `tryWW` (#20510)Sebastian Graf2021-10-294-3/+136
| | | | | | | | | | | | | | | | | | | | 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-294-0/+61
|
* Change CaseAlt and LambdaExpr to FunRhs in deriving Foldable and Traversable ↵Artyom Kuznetsov2021-10-264-0/+62
| | | | (#20496)
* Don't default type variables in type familiessheaf2021-10-2614-50/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-263-0/+11
| | | | (#20263)
* undefined: Neater CallStack in error messageJoachim Breitner2021-10-2414-21/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2412-19/+19
| | | | | This allows us to use an Anchor with a DeltaPos in it when exact printing.
* DmdAnal: Implement Boxity Analysis (#19871)Sebastian Graf2021-10-2451-438/+892
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* WorkWrap: `isRecDataCon` should not eta-reduce NewTyCon field tys (#20539)Sebastian Graf2021-10-222-1/+8
| | | | | | | | | | | | | 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.
* Refactor package importsSylvain Henry2021-10-2211-15/+23
| | | | | | | | | 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
* 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-2211-8/+55
| | | | | | | | | | | | | | | | | 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
* Bignum: allow Integer predicates to inline (#20361)Sylvain Henry2021-10-202-30/+35
| | | | | | | | | 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
* Make fields of GlobalRdrElt strictMatthew Pickering2021-10-201-1/+2
| | | | | | | | 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
* Fix #19884: add warning to tags command, drop T10989Emily Martins2021-10-194-24/+0
|
* Care about specificity in pattern type argsRichard Eisenberg2021-10-195-0/+34
| | | | 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.
* 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.
* Remove DT_Failed stateMatthew Pickering2021-10-1925-16/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-196-0/+20
| | | | | | | | | | | | | 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-1912-7/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* 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).
* Introduce Concrete# for representation polymorphism checkssheaf2021-10-17184-323/+2044
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | PHASE 1: we never rewrite Concrete# evidence. This patch migrates all the representation polymorphism checks to the typechecker, using a new constraint form Concrete# :: forall k. k -> TupleRep '[] Whenever a type `ty` must be representation-polymorphic (e.g. it is the type of an argument to a function), we emit a new `Concrete# ty` Wanted constraint. If this constraint goes unsolved, we report a representation-polymorphism error to the user. The 'FRROrigin' datatype keeps track of the context of the representation-polymorphism check, for more informative error messages. This paves the way for further improvements, such as allowing type families in RuntimeReps and improving the soundness of typed Template Haskell. This is left as future work (PHASE 2). fixes #17907 #20277 #20330 #20423 #20426 updates haddock submodule ------------------------- Metric Decrease: T5642 -------------------------
* ghci: Explicitly store and restore interface file cacheMatthew Pickering2021-10-176-0/+15
| | | | | | | | | | | | | | | | | | | | | In the old days the old HPT was used as an interface file cache when using ghci. The HPT is a `ModuleEnv HomeModInfo` and so if you were using hs-boot files then the interface file from compiling the .hs file would be present in the cache but not the hi-boot file. This used to be ok, because the .hi file used to just be a better version of the .hi-boot file, with more information so it was fine to reuse it. Now the source hash of a module is kept track of in the interface file and the source hash for the .hs and .hs-boot file are correspondingly different so it's no longer safe to reuse an interface file. I took the decision to move the cache management of interface files to GHCi itself, and provide an API where `load` can be provided with a list of interface files which can be used as a cache. An alternative would be to manage this cache somewhere in the HscEnv but it seemed that an API user should be responsible for populating and suppling the cache rather than having it managed implicitly. Fixes #20217
* Null eventlog writerOleg Grenrus2021-10-152-0/+11
|
* EPA: Preserve semicolon order in annotationsAlan Zimmerman2021-10-144-4/+2123
| | | | | | | | | Ensure the AddSemiAnn items appear in increasing order, so that if they are converted to delta format they are still in the correct order. Prior to this the exact printer sorted by Span, which is meaningless for EpaDelta locations.
* fuzzyLookup: More deterministic orderJoachim Breitner2021-10-149-15/+15
| | | | | | else the output may depend on the input order, which seems it may depend on the concrete Uniques, which is causing headaches when including test cases about that.
* Move BreakInfo into own moduleJoachim Breitner2021-10-142-2/+4
| | | | | | | | | | while working on GHCi stuff, e.g. `GHC.Runtime.Eval.Types`, I observed a fair amount of modules being recompiled that I didn’t expect to depend on this, from byte code interpreters to linkers. Turns out that the rather simple `BreakInfo` type is all these modules need from the `GHC.Runtime.Eval.*` hierarchy, so by moving that into its own file we make the dependency tree wider and shallower, which is probably worth it.
* Set logger flags in --backpack modesheaf2021-10-133-0/+30
| | | | | | | | | | Backpack used to initialise the logger before obtaining the DynFlags. This meant that logging options (such as dump flags) were not set. Initialising the logger after the session flags have been set fixes the issue. fixes #20396
* testsuite: remove 'req_smp' from testwsdequeZubin Duggal2021-10-131-1/+0
|
* hadrian: avoid building check-{exact,ppr} and count-deps when the tests ↵Zubin Duggal2021-10-132-147/+149
| | | | | | don't need them hadrian: build optional dependencies with test compiler
* ci: test in-tree compiler in hadrianZubin Duggal2021-10-132-4/+5
|
* testsuite: Run haddock tests on out of tree compilerZubin Duggal2021-10-131-4/+4
|
* hadrian, testsuite: Teach Hadrian to query the testsuite driver for dependenciesZubin Duggal2021-10-133-0/+36
| | | | Issues #19072, #17728, #20176
* Add GHCi recompilation performance testMatthew Pickering2021-10-123-0/+44
|
* testsuite: Clean up dynlib support predicatesBen Gamari2021-10-1218-44/+83
| | | | | | | | | | | | | | | | | | Previously it was unclear whether req_shared_libs should require: * that the platform supports dynamic library loading, * that GHC supports dynamic linking of Haskell code, or * that the dyn way libraries were built Clarify by splitting the predicate into two: * `req_dynamic_lib_support` demands that the platform support dynamic linking * `req_dynamic_hs` demands that the GHC support dynamic linking of Haskell code on the target platform Naturally `req_dynamic_hs` cannot be true unless `req_dynamic_lib_support` is also true.
* testsuite: Fix overzealous command-line manglingBen Gamari2021-10-121-1/+1
| | | | | Previously this attempt at suppressing make's -s flag would mangle otherwise valid arguments.
* testsuite: Move big-obj test from ghci/linking/dyn to ghci/linkingBen Gamari2021-10-127-9/+10
| | | | There was nothing dynamic about this test.
* testsuite: Make T12600 more robustBen Gamari2021-10-121-1/+1
| | | | | | Previously we would depend upon `grep ... | head -n1`. In principle this should work, but on Alpine Linux `grep` complains when its stdout stream has been closed.
* testsuite: Make recomp021 less environment-sensitiveBen Gamari2021-10-122-2/+2
| | | | | Suppress output from diff to eliminate unnecessary environmental-dependence.
* testsuite: Compile safeInfered tests with -v0Ben Gamari2021-10-1216-57/+14
| | | | | This eliminates some spurious platform-dependence due to static linking (namely in UnsafeInfered02 due to dynamic-too).
* testsuite: Mark T14931 as requiring dynamic linkingBen Gamari2021-10-121-1/+1
|
* testsuite: Mark all ghci/linking/dyn tests as requiring dynamic linkingBen Gamari2021-10-121-0/+2
|
* testsuite: Mark ghcilink00[25] as requiring dynamic linkingBen Gamari2021-10-121-2/+4
|
* testsuite: Mark T13702 as requiring share librariesBen Gamari2021-10-121-1/+1
| | | | | | | | | | | | | It fails on statically-built Alpine with ``` T13702.hs:1:1: error: Could not find module ‘Prelude’ Perhaps you haven't installed the "dyn" libraries for package ‘base-4.15.0.0’? Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 1 | {-# LANGUAGE ForeignFunctionInterface #-} | ^ ```
View Lorry Controller Status