summaryrefslogtreecommitdiff
path: root/testsuite
Commit message (Collapse)AuthorAgeFilesLines
* Whitespace-sensitive bang patterns (#1087, #17162)wip/whitespace-and-lookaheadVladislav Zavialov2019-11-27158-372/+513
| | | | | | | | | | | | | | | | | | This patch implements a part of GHC Proposal #229 that covers five operators: * the bang operator (!) * the tilde operator (~) * the at operator (@) * the dollar operator ($) * the double dollar operator ($$) Based on surrounding whitespace, these operators are disambiguated into bang patterns, lazy patterns, strictness annotations, type applications, splices, and typed splices. This patch doesn't cover the (-) operator or the -Woperator-whitespace warning, which are left as future work.
* Make warnings for TH splices opt-inSebastian Graf2019-11-273-8/+17
| | | | | | | | | | | | | | | | | | | | | | | In #17270 we have the pattern-match checker emit incorrect warnings. The reason for that behavior is ultimately an inconsistency in whether we treat TH splices as written by the user (`FromSource :: Origin`) or as generated code (`Generated`). This was first reported in #14838. The current solution is to TH splices as `Generated` by default and only treat them as `FromSource` when the user requests so (-fenable-th-splice-warnings). There are multiple reasons for opt-in rather than opt-out: * It's not clear that the user that compiles a splice is the author of the code that produces the warning. Think of the situation where she just splices in code from a third-party library that produces incomplete pattern matches. In this scenario, the user isn't even able to fix that warning. * Gathering information for producing the warnings (pattern-match check warnings in particular) is costly. There's no point in doing so if the user is not interested in those warnings. Fixes #17270, but not #14838, because the proper solution needs a GHC proposal extending the TH AST syntax.
* Remove prefix arrow support for GADTs (#17211)Krzysztof Gogolewski2019-11-252-7/+0
| | | | | | | This reverts the change in #9096. The specialcasing done for prefix (->) is brittle and does not support VTA, type families, type synonyms etc.
* Fix typosBrian Wignall2019-11-233-3/+3
|
* Stricten functions ins GHC.NaturalSebastian Graf2019-11-231-1/+1
| | | | | This brings `Natural` on par with `Integer` and fixes #17499. Also does some manual CSE for 0 and 1 literals.
* Prevent -optc arguments from being duplicated in reverse order (#17471)Ryan Scott2019-11-234-0/+20
| | | | | | | | | | | | | | | | | This reverts a part of commit 7bc5d6c6578ab9d60a83b81c7cc14819afef32ba that causes all arguments to `-optc` (and `-optcxx`) to be passed twice to the C/C++ compiler, once in reverse order and then again in the correct order. While passing duplicate arguments is usually harmless it can cause breakage in this pattern, which is employed by Hackage libraries in the wild: ``` ghc Foo.hs foo.c -optc-D -optcFOO ``` As `FOO -D -D FOO` will cause compilers to error. Fixes #17471.
* Take care to not eta-reduce jumps in CorePrepMatheus Magalhães de Alcantara2019-11-232-0/+24
| | | | | | | | | | | | | | CorePrep already had a check to prevent it from eta-reducing Ids that respond true to hasNoBinding (foreign calls, constructors for unboxed sums and products, and Ids with compulsory unfoldings). It did not, however, consider join points as ids that 'must be saturated'. Checking whether the Id responds True to 'isJoinId' should prevent CorePrep from turning saturated jumps like the following (from #17429) into undersaturated ones: (\ eta_XP -> join { mapped_s1vo _ = lvl_s1vs } in jump mapped_s1vo eta_XP)
* rts: Expose interface for configuring EventLogWritersBen Gamari2019-11-234-0/+55
| | | | | | This exposes a set of interfaces from the GHC API for configuring EventLogWriters. These can be used by consumers like [ghc-eventlog-socket](https://github.com/bgamari/ghc-eventlog-socket).
* Strip parentheses in expressions contexts in error messagesVladislav Zavialov2019-11-1914-26/+26
| | | | This makes error messages a tad less noisy.
* hpc: Fix encoding issues. Add test for and fix #17073Alexey Kuleshevich2019-11-194-0/+30
| | | | | | | | | | | | | * Make sure files are being read/written in UTF-8. Set encoding while writing HTML output. Also set encoding while writing and reading .tix files although we don't yet have a ticket complaining that this poses problems. * Set encoding in html header to utf8 * Upgrade to new version of 'hpc' library and reuse `readFileUtf8` and `writeFileUtf8` functions * Update git submodule for `hpc` * Bump up `hpc` executable version Co-authored-by: Ben Gamari <ben@smart-cactus.org>
* testsuite: Increase width of stack003 testBen Gamari2019-11-191-5/+11
| | | | | | Previously the returned tuple seemed to fit in registers on amd64. This meant that non-moving collector bug would cause the test to fail on i386 yet not amd64.
* Give seq a more precise type and remove magicBen Gamari2019-11-197-36/+36
| | | | | | | | | | | | | | | | | | | | | `GHC.Prim.seq` previously had the rather plain type: seq :: forall a b. a -> b -> b However, it also had a special typing rule to applications where `b` is not of kind `Type`. Issue #17440 noted that levity polymorphism allows us to rather give it the more precise type: seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b This allows us to remove the special typing rule that we previously required to allow applications on unlifted arguments. T9404 contains a non-Type application of `seq` which should verify that this works as expected. Closes #17440.
* Make test 16916 more stable across runsIvan Kasatenko2019-11-171-2/+2
|
* testsuite: Don't collect residency for T4801Ben Gamari2019-11-171-1/+0
| | | | | | I previously increased the size of the acceptance window from 2% to 5% but this still isn't enough. Regardless, measuring bytes allocated should be sufficient to catch any regressions.
* testsuite: Increase acceptance window of T4801Ben Gamari2019-11-151-1/+1
| | | | This statistic is rather unstable. Hopefully fixes #17475.
* base: Bump version to 4.14.0.0Ben Gamari2019-11-1410-17/+14
| | | | | Metric Increase: T4801
* Print name prefixly in the Outputable instance for StandaloneKindSigRyan Scott2019-11-133-0/+18
| | | | | | | | | Issue #17461 was occurring because the `Outputable` instance for standalone kind signatures was simply calling `ppr` on the name in the kind signature, which does not add parentheses to infix names. The solution is simple: use `pprPrefixOcc` instead. Fixes #17461.
* testsuite: Add test for #17458Ben Gamari2019-11-133-0/+59
| | | | | | As noted in #17458, QuantifiedConstraints and UndecideableInstances could previously be used to write programs which can loop at runtime. This was fixed in !1870.
* testsuite: don't collect compiler stats in collect_runtime_residencyAlp Mestanogullari2019-11-121-1/+1
| | | | | | | | | | | | | | | | | | | We instead want to collect the runtime stats (with collect_stats, instead of collect_compiler_stats). This should fix a number of perf tests failures we have been seeing, where we suddenly started measuring metrics we didn't intend to measure, which tend to fall outside of the acceptance window. Metric Decrease: lazy-bs-alloc T3586 Metric Increase: space_leak_001 T4801 T5835 T12791
* testsuite: Disable T4334 in nonmoving_thr waywip/alp/hadrian-ci-metricsfileBen Gamari2019-11-111-2/+3
|
* testsuite: Don't check_stats at runtime if not requestedwip/T17387Ben Gamari2019-11-101-4/+9
| | | | | | Previously we would call check_stats to check the runtime metrics even if the test definition hadn't requested it. This would result in an error since the .stats file doesn't exist.
* testsuite: Use small allocation area when measuring residencyBen Gamari2019-11-105-83/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | As suggested in #17387; this helps reduce the variance in our residency sampling. Metric Increase: T10370 T3586 lazy-bs-alloc Metric Decrease 'compile_time/peak_megabytes_allocated': T1969 Metric Decrease 'runtime/bytes allocated': space_leak_001 Metric Increase 'compile_time/bytes allocated': T1969 Metric Increase 'runtime/peak_megabytes_allocated': space_leak_001 Metric Decrease: T3064 T9675
* testsuite: Mark tests fragile in threaded2 as fragile in all concurrent waysBen Gamari2019-11-102-2/+2
|
* Fix #17405 by not checking imported equationsRichard Eisenberg2019-11-1012-73/+116
| | | | | | | | | | | | | Previously, we checked all imported type family equations for injectivity. This is very silly. Now, we check only for conflicts. Before I could even imagine doing the fix, I needed to untangle several functions that were (in my opinion) overly complicated. It's still not quite as perfect as I'd like, but it's good enough for now. Test case: typecheck/should_compile/T17405
* Improve SPECIALIZE pragma error messages (Fixes #12126)Alina Banerjee2019-11-102-2/+2
|
* Use the right type in :forceSimon Peyton Jones2019-11-094-0/+26
| | | | | | | | A missing prime meant that we were considering the wrong type in the GHCi debugger, when doing :force on multiple arguments (issue #17431). The fix is trivial.
* testsuite: Mark T16219 as fragile on WindowsBen Gamari2019-11-091-1/+2
| | | | | | As noted in #17452, this test produces very long file paths which exceed the Windows MAX_PATH limitation. Mark the test as fragile for not until we can come up with a better solution.
* testsuite: Drop T7995Ben Gamari2019-11-093-12/+0
| | | | | | | | | | | This test is quite sensitive to the build configuration as it requires that ghc have unfoldings, which isn't true in the quick build flavours. I considered various options to make the test more robust but none of them seemed particularly appealing. Moreover, Simon PJ was a bit skeptical of the value of the test to begin with and I strongly suspect that any regression in #7995 would be accompanied by failures in our other compiler performance tests. Closes #17399.
* testsuite: Fix putStrLn in saks028Ben Gamari2019-11-091-1/+2
| | | | | | | | | | | | | | | | | Bizarrely, `saks028` previously failed reliably, but only on Windows (#17450). The test would exit with a zero exit code but simply didn't emit the expected text to stderr. I believe this was due to the fact that the test used `putStrLn`, resulting in the output ending up on stdout. This worked on other platforms since (apparently) we redirect stdout to stderr when evaluating splices. However, on Windows it seems that the redirected output wasn't flushed as it was on other platforms. Anyways, it seems like the right thing to do here is to be explicit about our desire for the output to end up on stderr. Closes #17450.
* testsuite: Ignore stderr in PartialDownsweepBen Gamari2019-11-093-35/+1
| | | | | | | | | As described in #17449, PartialDownsweep is currently fragile due to its dependence on the error messages produced by the C preprocessor. To eliminate this dependence we simply ignore stderr output, instead relying on the fact that the test will exit with a non-zero exit code on failure. Fixes #17449.
* testsuite: Remove redundant cleaning logic from T16511Ben Gamari2019-11-091-3/+0
| | | | | | | | | | | | The GHCi script for T16511 had some `rm` commands to clean up output from previous runs. This should be harmless since stderr was redirected to /dev/null; however, it seems that this redirection doesn't work on Windows (perhaps because GHCi uses `cmd` to execute the command-line; I'm not sure). I tried to fix it but was unable to find a sensible solution. Regardless, the cleaning logic is quite redundant now that we run each test in a hermetic environment. Let's just remove it.
* testsuite: Mark T16219 as unbrokenBen Gamari2019-11-091-2/+1
| | | | This was previously broken due to #16386 yet it passes for me locally.
* testsuite: Mark T11627b as fragileBen Gamari2019-11-091-2/+1
| | | | | It was previously marked as broken due to #12236 however it passes for me locally while failing on CI.
* testsuite: Mark T13676 as broken on Darwin and WindowsBen Gamari2019-11-091-2/+3
| | | | Due to #17447.
* testsuite: Fix header #include order on WindowsBen Gamari2019-11-091-2/+3
| | | | <Rts.h> must always come first.
* testsuite: Skip T14931 on WindowsBen Gamari2019-11-091-1/+3
| | | | This test uses -dynamic-too, which is not supported on Windows.
* testsuite: Skip T16916 on WindowsBen Gamari2019-11-091-1/+2
| | | | The event manager is not supported on Windows.
* testsuite: Fix Windows cleanup pathBen Gamari2019-11-091-2/+2
| | | | This was a regression introduced with the Path refactoring.
* testsuite: Run tests in nonmoving_thr in speed==slowBen Gamari2019-11-081-0/+2
|
* SetLevels: Don't set context level when floating casesBen Gamari2019-11-083-1/+20
| | | | | | | | | | | When floating a single-alternative case we previously would set the context level to the level where we were floating the case. However, this is wrong as we are only moving the case and its binders. This resulted in #16978, where the disrepancy caused us to unnecessarily abstract over some free variables of the case body, resulting in shadowing and consequently Core Lint failures. (cherry picked from commit a2a0e6f3bb2d02a9347dec4c7c4f6d4480bc2421)
* Testsuite: Introduce req_rts_linkerStefan Schulze Frielinghaus2019-11-0816-37/+38
| | | | | Some tests depend on the RTS linker. Introduce a modifier to skip such tests, in case the RTS linker is not available.
* Clean up TH's treatment of unary tuples (or, #16881 part two)Ryan Scott2019-11-0711-30/+98
| | | | | | | | | | | | | | !1906 left some loose ends in regards to Template Haskell's treatment of unary tuples. This patch ends to tie up those loose ends: * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]` and `TupP [pat]` also now produce unary tuples. * I have added various special cases in GHC's pretty-printers to ensure that explicit 1-tuples are printed using the `Unit` type. See `testsuite/tests/th/T17380`. * The GHC 8.10.1 release notes entry has been tidied up a little. Fixes #16881. Fixes #17371. Fixes #17380.
* Check EmptyCase by simply adding a non-void constraintSebastian Graf2019-11-0525-33/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | We can handle non-void constraints since !1733, so we can now express the strictness of `-XEmptyCase` just by adding a non-void constraint to the initial Uncovered set. For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }` is non-empty. This is conceptually simpler than the plan outlined in #17376, because it talks to the oracle directly. In order for this patch to pass the testsuite, I had to fix handling of newtypes in the pattern-match checker (#17248). Since we use a different code path (well, the main code path) for `-XEmptyCase` now, we apparently also handle #13717 correctly. There's also some dead code that we can get rid off now. `provideEvidence` has been updated to provide output more in line with the old logic, which used `inhabitationCandidates` under the hood. A consequence of the shift away from the `UncoveredPatterns` type is that we don't report reduced type families for empty case matches, because the pretty printer is pure and only knows the match variable's type. Fixes #13717, #17248, #17386
* testsuite: skip test requiring RTS linker on PowerPCPeter Trommler2019-11-0513-31/+21
| | | | | | | | | | The RTS linker is not available on 64-bit PowerPC. Instead of marking tests that require the RTS linker as broken on PowerPC 64-bit skip the respective tests on all platforms where the RTS linker or a statically linked external interpreter is not available. Fixes #11259
* Separate `LPat` from `Pat` on the type-levelSebastian Graf2019-11-021-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the Trees That Grow effort started, we had `type LPat = Pat`. This is so that `SrcLoc`s would only be annotated in GHC's AST, which is the reason why all GHC passes use the extension constructor `XPat` to attach source locations. See #15495 for the design discussion behind that. But now suddenly there are `XPat`s everywhere! There are several functions which dont't cope with `XPat`s by either crashing (`hsPatType`) or simply returning incorrect results (`collectEvVarsPat`). This issue was raised in #17330. I also came up with a rather clean and type-safe solution to the problem: We define ```haskell type family XRec p (f :: * -> *) = r | r -> p f type instance XRec (GhcPass p) f = Located (f (GhcPass p)) type instance XRec TH f = f p type LPat p = XRec p Pat ``` This is a rather modular embedding of the old "ping-pong" style, while we only pay for the `Located` wrapper within GHC. No ping-ponging in a potential Template Haskell AST, for example. Yet, we miss no case where we should've handled a `SrcLoc`: `hsPatType` and `collectEvVarsPat` are not callable at an `LPat`. Also, this gets rid of one indirection in `Located` variants: Previously, we'd have to go through `XPat` and `Located` to get from `LPat` to the wrapped `Pat`. Now it's just `Located` again. Thus we fix #17330.
* Make CSE delay inlining lessSimon Peyton Jones2019-11-017-5/+23
| | | | | | | | | CSE delays inlining a little bit, to avoid losing vital specialisations; see Note [Delay inlining after CSE] in CSE. But it was being over-enthusiastic. This patch makes the delay only apply to Ids with specialisation rules, which avoids unnecessary delay (#17409).
* testsuite: Add test for #17423Ben Gamari2019-11-012-0/+38
|
* template-haskell: require at least 1 GADT constructor name (#17379)Adam Sandberg Eriksson2019-11-015-0/+26
|
* testsuite: Make ExplicitForAllRules1 more robustBen Gamari2019-11-012-11/+15
| | | | Previously the test relied on `id` not inlining. Fix this.
* Add another test for #17267Simon Peyton Jones2019-11-013-0/+41
| | | | This one came in a comment from James Payor
View Lorry Controller Status