- 20 Mar, 2015 3 commits
-
-
Herbert Valerio Riedel authored
This major version bump was made necessary by f44333ea which changed the type signatures of prefetch primops, as well as other changes such as 051d694f turning `Any` into an abstract closed type family. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D743
-
Simon Peyton Jones authored
The TH output contains uniques which change too much. So I took the length of the string instead. Crude, perhaps too crude, but it'll still show up most significant output changes
-
Herbert Valerio Riedel authored
This deepseq update drops the redundant ghc-prim dependency for GHC>=7.6
-
- 19 Mar, 2015 1 commit
-
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 17 Mar, 2015 2 commits
-
-
Thomas Miedema authored
Summary: BAD: "." ++ "/" ++ "/absolute/path" == ".//absolute/path" GOOD: "." </> "/absolute/path" == "/absolute path" Also replace `++ ".ext"` with `<.> "ext"`. Although it doesn't fix any bugs in this instance, it might in some other. As a general rule it's better not to use (++) on FilePaths. Reviewed By: austin, hvr Differential Revision: https://phabricator.haskell.org/D703 GHC Trac Issues: #10138
-
Thomas Miedema authored
This got broken in commit 5258566e.
-
- 16 Mar, 2015 3 commits
-
-
Thomas Miedema authored
Parsing of static and mode flags happens before any session is started, i.e., before the first call to 'GHC.withGhc'. Therefore, to report errors for invalid usage of these two types of flags, we can not call any function that needs DynFlags, as there are no DynFlags available yet (unsafeGlobalDynFlags is not set either). So we always print "on the commandline" as the location, which is true except for Api users, which is probably ok. When reporting errors for invalid usage of dynamic flags we /can/ make use of DynFlags, and we do so explicitly in DynFlags.parseDynamicFlagsFull. Before, we called unsafeGlobalDynFlags when an invalid (combination of) flag(s) was given on the commandline, resulting in panics (#9963). This regression was introduced in 1d6124de. Also rename showSDocSimple to showSDocUnsafe, to hopefully prevent this from happening again. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D730 GHC Trac Issues: #9963
-
Thomas Miedema authored
This should have been part of commit 5258566e, to allow expansion of '{hp2ps}' in a command string to `config.hp2ps`. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D734
-
Simon Peyton Jones authored
-
- 13 Mar, 2015 1 commit
-
-
Thomas Miedema authored
If one runs the testsuite with a profiling compiler, during the import of `testlib.py`, `testlib.py` sets the global variable `gs_working`. To do so, it executes a few statements which require the function `strip_quotes` to be in scope. But that function only gets defined at the very end of testlib.py. This patch moves the definition of `strip_quotes` to testutil.py, which is imported at the very top of testlib.py. This unbreaks the nightly builders. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D728
-
- 11 Mar, 2015 2 commits
-
-
Thomas Miedema authored
The ghci script tests were using different RTS flags from the normal ghci tests. This commit makes them use the same flags. Reviewers: austin Differential Revision: https://phabricator.haskell.org/D724
-
Thomas Miedema authored
* Use format strings instead of string concatenation. * Wrap `config.compiler`, `config.hpc` etc. in quotes in `mk/test.mk`, so we don't have to in .T scripts and driver/testlib.py. Update hpc submodule (test cleanup) Reviewers: austin Differential Revision: https://phabricator.haskell.org/D718
-
- 10 Mar, 2015 2 commits
-
-
Edward Z. Yang authored
Summary: This function generalizes the normaliseBytestringPackage and other similar one-off functions into normalise_version() with takes a package name to normalize against. This JUST manages package versions; we also could use a normalize for keys. In the process, I modified all the normalization functions to be accumulative; I don't think this makes a difference for current test cases but I think it makes things nicer. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D725
-
Herbert Valerio Riedel authored
-
- 09 Mar, 2015 1 commit
-
-
Thomas Miedema authored
See Note [Don't normalise input filenames] in `compiler/main/DriverPipeline.hs`. Fixes #2991. Reviewers: austin Differential Revision: https://phabricator.haskell.org/D701
-
- 07 Mar, 2015 6 commits
-
-
Alexander Vershilov authored
Summary: This is a draft of the patch that is sent for review. In this patch required changes in linter were introduced and actual check: - new helper function: primRepSizeB - primRep check for floating - Add access to dynamic flags in linter. - Implement additional lint rules. Reviewers: austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D637 GHC Trac Issues: #9122
-
Rufflewind authored
Summary: Tools such as `ghc-pkg` and `runghc` are no longer required to be in the same directory as `ghc` when running tests, provided that `TEST_HC` is not explicitly set and an in-tree compiler is not used. Fixes #10126. Reviewers: thomie, austin Reviewed By: thomie, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D705 GHC Trac Issues: #10126
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
Iavor S. Diatchki authored
Summary: This implements the new `Typeable` solver: when GHC sees `Typeable` constraints it solves them on the spot. The current implementation creates `TyCon` representations on the spot. Pro: No overhead at all in code that does not use `Typeable` Cons: Code that uses `Typeable` may create multipe `TyCon` represntations. We have discussed an implementation where representations of `TyCons` are computed once, in the module, where a datatype is declared. This would lead to more code being generated: for a promotable datatype we need to generate `2 + number_of_data_cons` type-constructro representations, and we have to do that for all programs, even ones that do not intend to use typeable. I added code to emit warning whenevar `deriving Typeable` is encountered--- the idea being that this is not needed anymore, and shold be fixed. Also, we allow `instance Typeable T` in .hs-boot files, but they result in a warning, and are ignored. This last one was to avoid breaking exisitng code, and should become an error, eventually. Test Plan: 1. GHC can compile itself. 2. I compiled a number of large libraries, including `lens`. - I had to make some small changes: `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance 3. I also run some code that uses `syb` to traverse a largish datastrucutre. I didn't notice any signifiant performance difference between the 7.8.3 version, and this implementation. Reviewers: simonpj, simonmar, austin, hvr Reviewed By: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D652 GHC Trac Issues: #9858
-
Herbert Valerio Riedel authored
This is a follow-up to eb3661f2 re-exporting `<$` from `Prelude` as well. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D681
-
Herbert Valerio Riedel authored
Whether to re-export the `<$>` non-method operator from `Prelude` wasn't explicitly covered in the original AMP proposal[1], but it turns out that not doing so forces most code that makes use of applicatives to import `Data.Functor` or `Control.Applicative` just to get that operator into scope. To this end, it was proposed to add `<$>` to Prelude as well[2]. The down-side is that this increases the amount of redundant-import warnings triggered, as well as the relatively minor issue of stealing the `<$>` operator from the default namespace for good (although at this point `<$>` is supposed to be ubiquitous anyway due to `Applicative` being implicitly required into the next Haskell Report) [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal [2]: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/24161 Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D680
-
- 06 Mar, 2015 2 commits
-
-
Thomas Miedema authored
Summary: Allow `cmd_wrapper` to return a format string that can refer to config values. Very useful! This allows for many tests to be defined in pure Python, instead of in an additional script or Makefile. Example: def Thpc(cmd): return(cmd + ' && {hpc} report Thpc.tix') test('Thpc', [cmd_wrapper(Thpc), only_ways['hpc']), compile_and_run, ['']) The `{hpc}` is replaced by the value of `config.hpc`. The result is that the module `Thpc` first gets compiled, then the binary `Thpc` is run, and then the `hpc report` command is run. The output of all of this is redirected (and later appended) to Thpc.run.stdout/stderr as normally. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D706
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 04 Mar, 2015 2 commits
-
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes
-
- 03 Mar, 2015 3 commits
-
-
Oleg Grenrus authored
Summary: Add Functor instances for Dual, Sum and Product Add Foldable instances for Dual, Sum and Product Add Traversable instances for Dual, Sum and Product Add Foldable and Traversable instances for First and Last Add Applicative, Monad instances to Dual, Sum, Product Add MonadFix to Data.Monoid wrappers Derive Data for Identity Add Data instances to Data.Monoid wrappers Add Data (Alt f a) instance Reviewers: ekmett, dfeuer, hvr, austin Reviewed By: dfeuer, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D673 GHC Trac Issues: #10107
-
Thomas Miedema authored
Summary: Ticket #10104 dealt with showing the '#'s on types with unboxed fields. This commit pretty prints the '#'s on unboxed literals in core output. Test Plan: simplCore/should_compile/T8274 Reviewers: jstolarek, simonpj, austin Reviewed By: simonpj, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D678 GHC Trac Issues: #8274
-
Tamar Christina authored
Summary: On Windows, the default action for things like division by zero and segfaults is to pop up a Dr. Watson error reporting dialog if the exception is unhandled by the user code. This is a pain when we are SSHed into a Windows machine, or when we want to debug a problem with gdb (gdb will get a first and second chance to handle the exception, but if it doesn't the pop-up will show). veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which will catch such exceptions in the entire process and die by printing a message and calling `stg_exit(1)`. Previously this code was handled using SEH (Structured Exception Handlers) however each compiler and platform have different ways of dealing with SEH. `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the compiler generate the appropriate SEH handler code for you. `MinGW` compilers have no such keywords and require you to manually set the SEH Handlers, however because SEH is implemented differently in x86 and x64 the methods to use them in GCC differs. `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`. On startup one would only need to add a new handler there. This has a number of issues such as hard to share handlers and it can be exploited. `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers are statically compiled and added to the .pdata section by the compiler. Instead of being thread global they can now be Image global since you have to specify the `RVA` of the region of code that the handlers govern. You can on x64 Dynamically allocate SEH handlers, but it seems that (based on experimentation and it's very under-documented) that the dynamic calls cannot override static SEH handlers in the .pdata section. Because of this and because GHC no longer needs to support < windows XP, the better alternative for handling errors would be using the in XP introduced VEH. The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API is the same for both x86 and x64 (note that the Context object does contain CPU specific structures) and the calls are the same cross compilers. Which means this file can be simplified quite a bit. Using VEH also means we don't have to worry about the dynamic code generated by GHCi. Test Plan: Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows. To reproduce the issue on x64: 1) open ghci 2) import GHC.Base 3) run: 1 `divInt` 0 which should lead to ghci crashing an a watson error box displaying. After applying the patch, run: make TEST="derefnull divbyzero" on both x64 and x86 builds of ghc to verify fix. Reviewers: simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D691 GHC Trac Issues: #6079
-
- 02 Mar, 2015 5 commits
-
-
Thomas Miedema authored
Summary: Currently, running `make test` in: / runs fast testsuite /testsuite doesn't work /testsuite/tests runs slow testsuite This commit: * changes `make test` in the ghc root directory to run the slow testsuite, just like it already does in `testsuite/tests` * adds some simple targets to `/testsuite`, that all delegate to `/testsuite/tests` * adds a new target `fasttest` to the toplevel Makefile, with a shorthand name `fast` (for consistency with /testsuite and /testsuite/tests) * declares some more targets PHONY for safety Wiki pages that need updating: * Building/StandardTargets * Buliding/RunningTests Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D685
-
Thomas Miedema authored
Summary: Fallout from AMP, recent addition of -fwarn-redundant-constraints and others. Some of these tests need `mtl` or `syb` to run. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D684
-
Thomas Miedema authored
Summary: The 2010 report mentions: "The result of `show` is a syntactically correct Haskell expression ... Parenthesis are only added where needed, //ignoring associativity//". Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D669 GHC Trac Issues: #2530
-
Simon Peyton Jones authored
* The original fix was to improve the documentation, in line with the suggestions on Trac #10122 * But in doing so I realised that the kind generalisation in TcRnDriver.tcRnType was completely wrong. So I fixed that and updated Note [Kind-generalise in tcRnType] to explain.
-
Simon Peyton Jones authored
-
- 23 Feb, 2015 6 commits
-
-
Oleg Grenrus authored
Summary: New flags: -fwarn-unused-top-binds -fwarn-unused-local-binds -fwarn-unused-pattern-binds Test Plan: `tests/rename/should_compile/T17` tests Correct other tests Reviewers: austin, rwbarton Reviewed By: austin, rwbarton Subscribers: rwbarton, carter, thomie Differential Revision: https://phabricator.haskell.org/D591 GHC Trac Issues: #17
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
Thomas Miedema authored
Test Plan: deriving/should_run/T10104 Reviewers: austin, jstolarek Reviewed By: austin, jstolarek Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D672 GHC Trac Issues: #10104
-
Thomas Miedema authored
Summary: Given: a Makefile with a non-PHONY target called `target` If: after running `make target`, a file exists with the same name as `target` (it was either already there, or it was created by running `make target`) And: `target` has no dependencies, such as `clean`, that modify or delete that file Then: subsequent invocations of `make target` will not have any effect. Solution: make `target` PHONY. BAD: ``` foo: ... ./foo ``` BETTER: ``` foo: ... ./foo .PHONY: foo ``` Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D670
-
Thomas Miedema authored
Summary: The user package database was already ignored for systems that `have_subprocess`. To [wiki:Debugging/InstallingPackagesInplace install] a package inplace: `cabal install --with-compiler=<inplace-ghc> --with-package-db=<inplace-package-db>` <package> Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D668
-
Thomas Miedema authored
Summary: GHC does 2 validation checks for module `Main`: * does `main` exist * is `main` exported (#414) The second check is done in ghc as well as in ghci (and runghc and ghc -e). The first check however is currently not done in ghci, to prevent "'main' is not in scope" errors when loading simple scripts. See commit d28ba8c8 for more information. This commit tightens the special case for ghci. When the file does not contain a main function, but does contain an explicit module header (i.e. "module Main where"), then /do/ raise an error in ghci (and runghc and ghc -e) as well Test Plan: module/T7765: a module Main with an explicit module header but without a main function should be an error for all Ways. Additionaly: delete test module/mod174. It was added in commit 5a54c38e, but it is a duplicate of module/T414. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D649 GHC Trac Issues: #7765
-
- 20 Feb, 2015 1 commit
-
-
Simon Peyton Jones authored
David Feuer managed to tickle a corner case in the code generator. See Note [Scrutinising VoidRep] in StgCmmExpr. I rejigged the comments in that area of the code generator Note [Dodgy unsafeCoerce 1] Note [Dodgy unsafeCoerce 2] but I can't say I fully understand them, alas.
-