GitLab

This fixes Trac #11947.  See TcSimplify
Note [No defaulting in the ambiguity check]

Now that warnIf takes a "reason", we can test the reason
in warnIf rather than in the caller.  Less code, and less
risk of getting the test and the reason out of sync.

Richard isn't sure why it's there and removing it didn't change
anything.

This is from Simon's suggestion:

* `tyCoVarsOfTypesAcc` is a terrible name for a function with a
  perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
  Similarly others

* `runFVList` is also terrible, but also has a decent type.
  Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).

* `someVars` could be `mkFVs :: [Var] -> FV`.

My validate didn't catch this one; it is fallout
(actually an improvement) from
  353d8a SCC analysis for instances as well as types/classes

This adds the tyvars of the domain of the substitution into the in-scope
set as well.
What I'm not sure here is if the kinds can have any free vars that
should be in the in-scope set as well.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie, simonmar

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

GHC Trac Issues: #11371

varSetElemsWellScoped introduces unnecessary non-determinism and it's possible
to do the same thing deterministically for the same price.

Test Plan: ./validate

Reviewers: austin, simonmar, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

These are corner cases in
   17eb2419 Refactor computing dependent type vars
and I couldn't even come up with a test case

* In TcSimplify.simplifyInfer, in the promotion step, be sure
  to promote kind variables as well as type variables.

* In TcType.spiltDepVarsOfTypes, the CoercionTy case, be sure
  to get the free coercion variables too.

This big patch is in pursuit of Trac #11348.

It is largely the work of Alex Veith (thank you!), with some
follow-up simplification and refactoring from Simon PJ.

The main payload is described in RnSource
  Note [Dependency analysis of type, class, and instance decls]
which is pretty detailed.

* There is a new data type HsDecls.TyClGroup, for a strongly
  connected component of type/class/instance/role decls.

  The hs_instds field of HsGroup disappears, in consequence

  This forces some knock-on changes, including a minor
  haddock submodule update

Smaller, weakly-related things

* I found that both the renamer and typechecker were building an
  identical env for RoleAnnots, so I put common code for
  RoleAnnotEnv in RnEnv.

* I found that tcInstDecls1 had very clumsy error handling, so I
  put it together into TcInstDcls.doClsInstErrorChecks

I want it for subsequent commits

Several things here

* GHC no longer allows user-written Typeable instances,
  so remove them from hs-boot files.

* Generally, reduce the use of instances in hs-boot files. They are
  hard to track.  Mainly this involves using pprType, pprKind etc
  instead of just ppr.  There were a lot of instances in hs-boot
  files that weren't needed at all.

* Take TyThing out of Eq; it was used in exactly one place (in
  InteractiveEval), and equality is too big a hammer for that.

Install files necessary for --hyperlinked-source. Fixes #11949.

NB: this needs 91ee5090

GHC can't infer this module safe due to the `GHC.Types (Char, Int)`
and the  (dummy) `GHC.Integer ()` import.

If only `GHC.Types` was marked Trustworthy or Safe...

This bumps the hsc2hs version to 0.68

This is just tidying up.

This patch finishes off Trac #11450.  Following debate on that ticket,
the patch tightens up the rules for what the instances of an
associated type can look like.  Now they must match the instance
header exactly. Eg

   class C a b where
    type T a x b

With this class decl, if we have an instance decl
  instance C ty1 ty2 where ...
then the type instance must look like
     type T ty1 v ty2 = ...
with exactly
  - 'ty1' for 'a'
  -  'ty2' for 'b', and
  - a variable for 'x'

For example:

  instance C [p] Int
    type T [p] y Int = (p,y,y)

Previously we allowed multiple instance equations and now, in effect,
we don't since they would all overlap.  If you want multiple cases,
use an auxiliary type family.

This is consistent with the treatment of generic-default instances,
and the user manual always said "WARNING: this facility (multiple
instance equations may be withdrawn in the future".

I also improved error messages, and did other minor refactoring.

There should be no change in behaviour here

* Move splitDepVarsOfType(s) from Type to TcType

* Define data type TcType.TcDepVars, document what it means,
  and use it where appropriate, notably in splitDepVarsOfType(s)

* Use it in TcMType.quantifyTyVars and friends

This just defines a useful helper function that was being
duplicated in several places

The v1.2.6.1 release uploaded to Hackage is broken, we don't
want to bundle a release that's non-installable from Hackage

Reviewers: austin

Subscribers: thomie

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

This prevents us from entering an infinite loop in the event of a
hitting bad unwinding information.

This macro is doubly redundant, first off all, ancient GCCs prior to
version 3.0 are not supported anymore, but more importantly, we require
a ISO C99 compliant compiler, so we can use the proper ISO C syntax
without worrying about compatibility.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: carter, thomie

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

Saves us a CPP #if in MachDeps.h since we now can always rely on a
64-bit type being available.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, erikd

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

Test Plan: Read it

Reviewers: hvr, austin

Subscribers: carter, thomie

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

GHC Trac Issues: #11744

The version of `haddock` that ghc has as a submodule has an option
for generating linkified sources. I don't think it hurts to have this
and they are great for exploring the codebase.

I'd be nice if harbormaster or travis published them somewhere, but
I don't know how to do that yet.

Test Plan:
uncomment, run `make` and look at the
nicely linkified sources in `compiler/stage2/doc/html/ghc/`

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, simonmar

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

This fixes a build-failure on OSX

Summary:
Systools makes some pretty hard assumptions about where GHC is on Windows.
One of these is that ghc be in a folder named `bin` and that `../lib` exists.

This pattern doesn't hold for symlinks as a link `C:\ghc-bin\`
pointing to `C:\ghc\ghc-7.10.3\bin` will break this assumption.

This patch resolves symlinks by finding where they point to and uses that location
as the base for GHC.

This uses an API that's been introduced in Vista. For older systems it falls back to
the current behavior of not resolving symlinks.

Test Plan:
1) Create symlink to GHC's bin folder.
2) Run GHC from that folder.

Reviewers: austin, bgamari

Reviewed By: austin

Subscribers: #ghc_windows_task_force, thomie

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

GHC Trac Issues: #11759

Test Plan:
 - Run tests on x86_64/linux, x86_64/darwin and powerpc/linux
 - Cross compile rts/Linker.c with the i686-w64-mingw32-gcc and
   x86_64-w64-mingw32-gcc Linux to Windows cross-compilers.

Reviewers: hvr, austin, thomie, bgamari, simonmar, Phyx

Reviewed By: Phyx

Subscribers: thomie

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

Prevent shared objects from being unloaded if cost centre stacks point
at the object. This will prevent segfault in #11776, but also prevents
objects from ever being unloaded when profiling. Pruning CCS tree will
enable that in another diff.

Test Plan: make TEST=linker_profiled, examine linker_profiled.run.stderr

Reviewers: austin, simonmar, bgamari

Reviewed By: simonmar, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11776