summaryrefslogtreecommitdiff
path: root/testsuite/tests
Commit message (Collapse)AuthorAgeFilesLines
* 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: Disable T4334 in nonmoving_thr waywip/alp/hadrian-ci-metricsfileBen Gamari2019-11-111-2/+3
|
* testsuite: Use small allocation area when measuring residencyBen Gamari2019-11-104-83/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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-0815-37/+34
| | | | | 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
* Fix running of ratio test casetaylorfausak2019-11-011-1/+1
|
* Add tests for rounding ratiostaylorfausak2019-11-012-0/+42
|
* Whitespace forward compatibility for proposal #229Vladislav Zavialov2019-10-3014-43/+23
| | | | | | | | GHC Proposal #229 changes the lexical rules of Haskell, which may require slight whitespace adjustments in certain cases. This patch changes formatting in a few places in GHC and its testsuite in a way that enables it to compile under the proposed rules.
* testsuite: Fix quoting of $(TEST_HC) in T12674Ben Gamari2019-10-291-2/+2
| | | | I have no idea how this went unnoticed until now.
* Attach API Annotations for {-# SOURCE #-} import pragmaAlan Zimmerman2019-10-284-0/+48
| | | | | | | Attach the API annotations for the start and end locations of the {-# SOURCE #-} pragma in an ImportDecl. Closes #17388
* Refactor TcDeriv to validity-check less in anyclass/via deriving (#13154)Ryan Scott2019-10-286-1/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the way `DerivEnv` is currently structured, there is an invariant that every derived instance must consist of a class applied to a non-empty list of argument types, where the last argument *must* be an application of a type constructor to some arguments. This works for many cases, but there are also some design patterns in standalone `anyclass`/`via` deriving that are made impossible due to enforcing this invariant, as documented in #13154. This fixes #13154 by refactoring `TcDeriv` and friends to perform fewer validity checks when using the `anyclass` or `via` strategies. The highlights are as followed: * Five fields of `DerivEnv` have been factored out into a new `DerivInstTys` data type. These fields only make sense for instances that satisfy the invariant mentioned above, so `DerivInstTys` is now only used in `stock` and `newtype` deriving, but not in other deriving strategies. * There is now a `Note [DerivEnv and DerivSpecMechanism]` describing the bullet point above in more detail, as well as explaining the exact requirements that each deriving strategy imposes. * I've refactored `mkEqnHelp`'s call graph to be slightly less complicated. Instead of the previous `mkDataTypeEqn`/`mkNewTypeEqn` dichotomy, there is now a single entrypoint `mk_eqn`. * Various bits of code were tweaked so as not to use fields that are specific to `DerivInstTys` so that they may be used by all deriving strategies, since not all deriving strategies use `DerivInstTys`.
* Fix #15344: use fail when desugaring applicative-doJosef Svenningsson2019-10-288-9/+234
| | | | | | | | | | | | | | | | Applicative-do has a bug where it fails to use the monadic fail method when desugaring patternmatches which can fail. See #15344. This patch fixes that problem. It required more rewiring than I had expected. Applicative-do happens mostly in the renamer; that's where decisions about scheduling are made. This schedule is then carried through the typechecker and into the desugarer which performs the actual translation. Fixing this bug required sending information about the fail method from the renamer, through the type checker and into the desugarer. Previously, the desugarer didn't have enough information to actually desugar pattern matches correctly. As a side effect, we also fix #16628, where GHC wouldn't catch missing MonadFail instances with -XApplicativeDo.
* Parenthesize nullary constraint tuples using sigPrec (#17403)Ryan Scott2019-10-274-0/+12
| | | | | | | | | We were using `appPrec`, not `sigPrec`, as the precedence when determining whether or not to parenthesize `() :: Constraint`, which lead to the parentheses being omitted in function contexts like `(() :: Constraint) => String`. Easily fixed. Fixes #17403.
* testsuite: Skip regalloc_unit_tests unless have_ncgBen Gamari2019-10-261-0/+1
| | | | | This is a unit test for the native code generator's register allocator; naturally. the NCG is required.
* Fix #14690 - :steplocal panics after break-on-errorRoland Senn2019-10-264-0/+19
| | | | | | | | | | | | | | `:steplocal` enables only breakpoints in the current top-level binding. When a normal breakpoint is hit, then the module name and the break id from the `BRK_FUN` byte code allow us to access the corresponding entry in a ModBreak table. From this entry we then get the SrcSpan (see compiler/main/InteractiveEval.hs:bindLocalsAtBreakpoint). With this source-span we can then determine the current top-level binding, needed for the steplocal command. However, if we break at an exception or at an error, we don't have an BRK_FUN byte-code, so we don't have any source information. The function `bindLocalsAtBreakpoint` creates an `UnhelpfulSpan`, which doesn't allow us to determine the current top-level binding. To avoid a `panic`, we have to check for `UnhelpfulSpan` in the function `ghc/GHCi/UI.hs:stepLocalCmd`. Hence a :steplocal command after a break-on-exception or a break-on-error is not possible.
* Implement shrinkSmallMutableArray# and resizeSmallMutableArray#.Andrew Martin2019-10-263-0/+90
| | | | | | | | | | | | | | | | | | | | | This is a part of GHC Proposal #25: "Offer more array resizing primitives". Resources related to the proposal: - Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/121 - Proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0025-resize-boxed.rst Only shrinkSmallMutableArray# is implemented as a primop since a library-space implementation of resizeSmallMutableArray# (in GHC.Exts) is no less efficient than a primop would be. This may be replaced by a primop in the future if someone devises a strategy for growing arrays in-place. The library-space implementation always copies the array when growing it. This commit also tweaks the documentation of the deprecated sizeofMutableByteArray#, removing the mention of concurrency. That primop is unsound even in single-threaded applications. Additionally, the non-negativity assertion on the existing shrinkMutableByteArray# primop has been removed since this predicate is trivially always true.
* testsuite: Use fragile modifier in TH_foreignInterruptibleBen Gamari2019-10-251-2/+1
| | | | It looks like this use of `skip` snuck through my previous refactoring.
* testsuite: Mark T13786 as fragile in unreg buildBen Gamari2019-10-251-1/+3
| | | | Due to #17018.
* Mark promoted InfixT names as IsPromoted (#17394)Ryan Scott2019-10-243-0/+19
| | | | | We applied a similar fix for `ConT` in #15572 but forgot to apply the fix to `InfixT` as well. This patch fixes #17394 by doing just that.
* Make isTcLevPoly more conservative with newtypes (#17360)Ryan Scott2019-10-243-0/+18
| | | | | | | | | | | | `isTcLevPoly` gives an approximate answer for when a type constructor is levity polymorphic when fully applied, where `True` means "possibly levity polymorphic" and `False` means "definitely not levity polymorphic". `isTcLevPoly` returned `False` for newtypes, which is incorrect in the presence of `UnliftedNewtypes`, leading to #17360. This patch tweaks `isTcLevPoly` to return `True` for newtypes instead. Fixes #17360.
* Parenthesize GADT return types in pprIfaceConDecl (#17384)Ryan Scott2019-10-244-0/+16
| | | | | | | We were using `pprIfaceAppArgs` instead of `pprParendIfaceAppArgs` in `pprIfaceConDecl`. Oops. Fixes #17384.
View Lorry Controller Status