GitLab

Trac #13135 showed that we were failing to apply the
correct substitution to the un-substituted tyvars during
type-family improvement using injectivity.  Specifically
in TcInteractlinjImproveEqns we need to use instFlexiX.

An outright bug, easy to fix.

Slight refactoring along the way.  The quantified tyars of the axiom are
readily to hand; we don't need to take the free tyvars of the LHS

For some reason, unless you have -fprint-explicit-coercions, when
printing an explicit coercion we were then going to special trouble to
suppress the unique of a hole (which only happens during debugging
anyway).  This is bizarre.

So I deleted three lines of code -- hooray.

Summary:
While thesing, I realized this part of the implementation
didn't make very much sense, so I started working on some
documentation updates to try to make things more explainable.

The new docs are organized around the idea of a
"never exported TyThing" (a non-implicit TyThing that never
occurs in the export list of a module).  I also removed
some outdated information that predated the change of
ModIface to store Names rather than OccNames.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Reviewers: simonpj, bgamari, austin

Subscribers: thomie

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

Forgot to handle these!  In they go, plus a test case.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
This reverts commit a0899b2f. This is because
removing these checks prompts panics in at least two different programs
reported in #12785.

Test Plan: ./validate

Reviewers: simonpj, goldfire, bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #12785

Currently we use `-Wl` which takes a list of
comma-separated options. Unfortunately that
breaks when you use it with `-rpath` and
a path that has commas in them.
Buck, the build system, produces paths with
commas in them.

`-Xlinker` doesn't have this disadvantage
and as far as I can tell is supported by
both `gcc` and `clang`. Anecdotally `nvcc`
supports `-Xlinker`, but not `-Wl`.

Test Plan: ./validate, harbourmaster

Reviewers: nomeata, simonmar, austin, bgamari, hvr

Reviewed By: simonmar, bgamari

Subscribers: thomie

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

Introduce a warning, -Wmissing-home-modules, to warn about home modules,
not listed in command line.

It is usefull for cabal when user fails to list a module in
`exposed-modules` and `other-modules`.

Test Plan: make TEST=MissingMod

Reviewers: mpickering, austin, bgamari

Reviewed By: bgamari

Subscribers: simonpj, mpickering, thomie

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

GHC Trac Issues: #13129

This fixes #12441, where definitions in a Haskell module and its boot
file which differed only in their quantifiers produced a confusing error
message. Here we teach GHC to always show quantifiers for these errors.

Reviewers: goldfire, simonmar, erikd, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: snowleopard, simonpj, mpickering, thomie

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

GHC Trac Issues: #12441

This commits relaxes the invariants of the Core syntax so that a
top-level variable can be bound to a primitive string literal of type
Addr#.

This commit:

* Relaxes the invatiants of the Core, and allows top-level bindings whose
  type is Addr# as long as their RHS is either a primitive string literal or
  another variable.

* Allows the simplifier and the full-laziness transformer to float out
  primitive string literals to the top leve.

* Introduces the new StgGenTopBinding type to accomodate top-level Addr#
  bindings.

* Introduces a new type of labels in the object code, with the suffix "_bytes",
  for exported top-level Addr# bindings.

* Makes some built-in rules more robust. This was necessary to keep them
  functional after the above changes.

This is a continuation of D2554.

Rebasing notes:
This had two slightly suspicious performance regressions:

* T12425: bytes allocated regressed by roughly 5%
* T4029: bytes allocated regressed by a bit over 1%
* T13035: bytes allocated regressed by a bit over 5%

These deserve additional investigation.

Rebased by: bgamari.

Test Plan: ./validate --slow

Reviewers: goldfire, trofi, simonmar, simonpj, austin, hvr, bgamari

Reviewed By: trofi, simonpj, bgamari

Subscribers: trofi, simonpj, gridaphobe, thomie

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

GHC Trac Issues: #8472

Reviewers: dfeuer, austin, bgamari, hvr

Subscribers: dfeuer, mpickering, RyanGlScott, ekmett, yav, lelf,
simonpj, thomie

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

GHC Trac Issues: #12162

Trac #13156 showed a lost opportunity for CSE. I found that it was
easy to fix, and it had the nice side effect of rendering a previous
nasty case, described in Note [Corner case for case expressions],
unnecessary.

Simpler code, does more.  Great.

This bug has been lurking for ages: Trac #13155

The important semantic change is to ensure that exprIsExpandable
returns False for primop calls.  Previously exprIsExpandable used
exprIsCheap' which always used primOpIsCheap.

I took the opportunity to combine the code for exprIsCheap' (two
variants: exprIsCheap and exprIsExpandable) with that for
exprIsWorkFree.  Result is simpler, tighter, easier to understand.
And correct (at least wrt this bug)!

Following e7985ed2. HasDebugCallStack now
appears in IdInfo, which requires `FlexibleContexts` to be enabled when built
with GHC 7.10.

This commit implements the proposal in
https://github.com/ghc-proposals/ghc-proposals/pull/29 and
https://github.com/ghc-proposals/ghc-proposals/pull/35.

Here are some of the pieces of that proposal:

* Some of RuntimeRep's constructors have been shortened.

* TupleRep and SumRep are now parameterized over a list of RuntimeReps.
* This
means that two types with the same kind surely have the same
representation.
Previously, all unboxed tuples had the same kind, and thus the fact
above was
false.

* RepType.typePrimRep and friends now return a *list* of PrimReps. These
functions can now work successfully on unboxed tuples. This change is
necessary because we allow abstraction over unboxed tuple types and so
cannot
always handle unboxed tuples specially as we did before.

* We sometimes have to create an Id from a PrimRep. I thus split PtrRep
* into
LiftedRep and UnliftedRep, so that the created Ids have the right
strictness.

* The RepType.RepType type was removed, as it didn't seem to help with
* much.

* The RepType.repType function is also removed, in favor of typePrimRep.

* I have waffled a good deal on whether or not to keep VoidRep in
TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
represented in RuntimeRep, and typePrimRep will never return a list
including
VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
imagine another design choice where we have a PrimRepV type that is
PrimRep
with an extra constructor. That seemed to be a heavier design, though,
and I'm
not sure what the benefit would be.

* The last, unused vestiges of # (unliftedTypeKind) have been removed.

* There were several pretty-printing bugs that this change exposed;
* these are fixed.

* We previously checked for levity polymorphism in the types of binders.
* But we
also must exclude levity polymorphism in function arguments. This is
hard to check
for, requiring a good deal of care in the desugarer. See Note [Levity
polymorphism
checking] in DsMonad.

* In order to efficiently check for levity polymorphism in functions, it
* was necessary
to add a new bit of IdInfo. See Note [Levity info] in IdInfo.

* It is now safe for unlifted types to be unsaturated in Core. Core Lint
* is updated
accordingly.

* We can only know strictness after zonking, so several checks around
* strictness
in the type-checker (checkStrictBinds, the check for unlifted variables
under a ~
pattern) have been moved to the desugarer.

* Along the way, I improved the treatment of unlifted vs. banged
* bindings. See
Note [Strict binds checks] in DsBinds and #13075.

* Now that we print type-checked source, we must be careful to print
* ConLikes correctly.
This is facilitated by a new HsConLikeOut constructor to HsExpr.
Particularly troublesome
are unlifted pattern synonyms that get an extra void# argument.

* Includes a submodule update for haddock, getting rid of #.

* New testcases:
  typecheck/should_fail/StrictBinds
  typecheck/should_fail/T12973
  typecheck/should_run/StrictPats
  typecheck/should_run/T12809
  typecheck/should_fail/T13105
  patsyn/should_fail/UnliftedPSBind
  typecheck/should_fail/LevPolyBounded
  typecheck/should_compile/T12987
  typecheck/should_compile/T11736

* Fixed tickets:
  #12809
  #12973
  #11736
  #13075
  #12987

* This also adds a test case for #13105. This test case is
* "compile_fail" and
succeeds, because I want the testsuite to monitor the error message.
When #13105 is fixed, the test case will compile cleanly.

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #13132

Test Plan: build with ghc-7.10.1

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

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

GHC Trac Issues: #13120

Previously, `mkInlineUnfolding` took a `Maybe` argument indicating
whether the caller requested a specific arity.  This was not
self-documenting at call sites. Now we distinguish between
`mkInlineUnfolding` and `mkInlineUnfoldingWithArity`.

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: thomie

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

    In module ‘Prelude’:
      ‘True’ is a data constructor of ‘Bool’
    To import it use
      ‘import’ Prelude( Bool( True ) )

The quotes around `import` don't make any sense.

Test Plan: manual

Reviewers: austin, mpickering, bgamari

Reviewed By: mpickering, bgamari

Subscribers: dfeuer, thomie

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

These are producing StgWords so foldl' is the natural choice. I'm not
sure how I didn't notice this when I wrote D1041.

Test Plan: Validate

Reviewers: austin, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #7450

An unboxed tuple such as

    (# | b | | | | | #)

Ends up in the parser via `tup_exprs` as

    Sum 2 7 lexp

where `lexp` is a `LHsExpr`

From an API annotation perspective, the 5 `AnnVbar`s after the `b` were attached
to `lexp`, but the leading `AnnVbar`s did not have a home.

This patch attaches them all to the the parent tuple expression. The first (alt
- 1) of them come before `lexp`, and the remaining (arity - alt) come after.

Test Plan: ./validate

Reviewers: osa1, austin, bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #12417

This patch implements two related changes, both inspired by
the discussion on Trac #13027, comment:23:

* exprOkForSpeculation (op# a1 .. an), where op# is a primop,
  now skips over arguments ai of lifted type.  See the comments
  at Note [Primops with lifted arguments] in CoreUtils.

  There is no need to treat dataToTag# specially any more.

* dataToTag# is now treated as a can-fail primop.  See
  Note [dataToTag#] in primops.txt.pp

I don't expect this to have a visible effect on anything, but
it's much more solid than before.

Summary:
This flag causes a dump of the ParsedSource as an AST in textual form, similar
to the ghc-dump-tree on hackage.

Test Plan: ./validate

Reviewers: mpickering, bgamari, austin

Reviewed By: mpickering

Subscribers: nominolo, thomie

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

GHC Trac Issues: #11140

This change is requred for llvm 4.0. GHC doesn't use that version yet,
but this change is just as valid for versions eariler than 4.0.

Two changes needed:

* Previously, GHC defined a `topN` node in the TBAA heiarchy and some IR
  instructions referenced that node. With LLVM 4.0 the root node can no
  longer be referenced by IR instructions, so we introduce a new element
  `rootN` and make `topN` a child of that.

* Previously the root TBAA node was rendered as "!0 = !{!"root", null}".
  With LLVM 4.0 that needs to be "!0 = !{!"root"}" which is also
  accepted by earlier versions.

Test Plan: Build with quick-llvm BuildFlavor and run tests

Reviewers: bgamari, drbo, austin, angerman, michalt, DemiMarie

Reviewed By: DemiMarie

Subscribers: mpickering, DemiMarie, thomie

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

This reverts commit 6b976eb8.

Ben, Ryan and I decided to revert this for now due to T12234 failing
and causing all harbormaster builds to fail.

Summary:
Apparently `sysErrorBelch` doesn't terminate the program anymore making
previously unreachable code now execute. If a dll is not found the error
message we return needs to be a heap value.

Secondly also allow the pattern `lib<name>` to be allowed for finding an
import library with the name `lib<name>.dll.a`.

Test Plan: ./validate, new tests T13082_good and T13082_fail

Reviewers: austin, RyanGlScott, hvr, erikd, simonmar, bgamari

Reviewed By: RyanGlScott, bgamari

Subscribers: thomie, #ghc_windows_task_force

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

GHC Trac Issues: #13082

Summary:
D2917 added a change that will make paths on Windows response files
use DOS 8.3 shortnames to get around the fact that `libiberty` assumes
a one byte per character encoding.

This is actually not the problem, the actual problem is that GCC on
Windows doesn't seem to support Unicode at all.

This comes down to how unicode characters are handled between POSIX and
Windows. On Windows, Unicode is only supported using a multibyte character
encoding such as `wchar_t` with calls to the appropriate wide version of
APIs (name post-fixed with the `W` character). On Posix I believe the standard
`char` is used and based on the value it is decoded to the correct string.

GCC doesn't seem to make calls to the Wide version of the Windows APIs,
and even if it did, it's character representation would be wrong. So I
believe GCC just does not support utf-8 paths on Windows.

So the hack in D2917 is the only way to get Unicode support. The problem is
however that `GCC` is not the only tool with this issue and we don't use response
files for every invocation of the tools. Most of the tools probably don't support it.

Furthermore, DOS 8.1 shortnames only exist when the path or file physically exists on
disk. We pass lots of paths to GCC that don't exist yet, like the output file.
D2917 works around this by splitting the path from the file and try shortening that.

But this may not always work.

In short, even if we do Unicode correctly (which we don't atm, the GCC driver we build
uses `char` instead of `wchar_t`) we won't be able to compile using unicode paths that
need to be passed to `GCC`. So not sure about the point of D2917.

What we can do is support the most common non-ascii characters by writing the response
files out using the `latin1` code page.

Test Plan: compile + make test TEST=T12971

Reviewers: austin, bgamari, erikd

Reviewed By: bgamari

Subscribers: thomie, #ghc_windows_task_force

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

GHC Trac Issues: #12971

Summary:
Using makeStatic instead of applications of the StaticPtr data
constructor makes possible linting core when unboxing strict
fields.

Test Plan: ./validate

Reviewers: simonpj, goldfire, austin, bgamari, hvr

Reviewed By: simonpj

Subscribers: RyanGlScott, mboes, thomie

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

GHC Trac Issues: #12622

In Trac #13027, comment:20, I noticed that wrappers created after
demand analysis weren't recording the evaluated-ness of strict
constructor arguments.  In the ticket that led to a (debatable)
Lint error but in general the more we know about evaluated-ness
the better we can optimise.

This commit adds that info both in the worker (on args) and in
the wrapper (on CPR result patterns).

See Note [Record evaluated-ness in worker/wrapper] in WwLib

On the way I defined Id.setCaseBndrEvald, and used it to shorten
the code in a few other places

Some out-of-scope errors were not being reported if anyone
throws an un-caught exception in the TcM monad.  That led to

  ghc: panic! (the 'impossible' happened)
	initTc: unsolved constraints

I fixed this

* Splitting captureConstraints to use an auxilliary
  tryCaptureConstraints (which never fails)

* Define a new TcSimplify.captureTopConstraints (replacing
  the old TcRnMonad.captureTopConstraints), which reports
  any unsolved out-of-scope constraints before propagating
  the exception

That in turn allowed me to do some tidying up of the static-constraint
machinery, reducing duplication.

Also solves #13106.

No change in behaviour

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>