GitLab

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

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

This deepseq update drops the redundant ghc-prim dependency for GHC>=7.6

Signed-off-by: Austin Seipp <austin@well-typed.com>

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

This got broken in commit 5258566e.

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

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

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

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

* 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

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

See Note [Don't normalise input filenames] in
`compiler/main/DriverPipeline.hs`. Fixes #2991.

Reviewers: austin

Differential Revision: https://phabricator.haskell.org/D701

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

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

Signed-off-by: Austin Seipp <austin@well-typed.com>

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

This is a follow-up to eb3661f2
re-exporting `<$` from `Prelude` as well.

Reviewed By: austin, ekmett

Differential Revision: https://phabricator.haskell.org/D681

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

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

Signed-off-by: Austin Seipp <austin@well-typed.com>

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

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

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

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

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

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

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

* 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.

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

Signed-off-by: Austin Seipp <austin@well-typed.com>

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

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

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

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

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.