GitLab

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

Thomas Miedema authored Jan 22, 2017 and Ben Gamari committed Jan 22, 2017

The `clean_cmd` and `extra_clean` setup functions don't do anything.
Remove them from .T files.

Created using https://github.com/thomie/refactor-ghc-testsuite. This
diff is a test for the .T-file parser/processor/pretty-printer in that
repository.

    find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;

Tests containing inline comments or multiline strings are not modified.

Preparation for #12223.

Test Plan: Harbormaster

Reviewers: austin, hvr, simonmar, mpickering, bgamari

Reviewed By: mpickering

Subscribers: mpickering

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

GHC Trac Issues: #12223

These are only failing on Darwin, strangely enough, but do so quite
reproducibly.

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

Yuras authored Jan 20, 2017 and Ben Gamari committed Jan 20, 2017

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

rwbarton authored Jan 20, 2017 and Ben Gamari committed Jan 20, 2017

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #13099

Phil de Joux authored Jan 20, 2017 and Ben Gamari committed Jan 20, 2017

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

takano-akio authored Jan 18, 2017 and Ben Gamari committed Jan 20, 2017

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

Oleg Grenrus authored Jan 19, 2017 and Ben Gamari committed Jan 20, 2017

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)!

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.

rwbarton authored Jan 18, 2017 and Ben Gamari committed Jan 18, 2017

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #13132

Daishi Nakajima authored Jan 18, 2017 and Ben Gamari committed Jan 18, 2017

Test Plan:
Added 2 test cases, verified that  ghc can suggest in the following
cases:

  - for misspelled flag containing '=', ghc suggests flags that doesn't
    contain '='
  - for misspelled flag containing '=', ghc suggests flags that
    contains '='

Reviewers: austin, dfeuer, bgamari

Reviewed By: dfeuer, bgamari

Subscribers: dfeuer, mpickering, thomie

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

GHC Trac Issues: #11789

The fix in D2964 wasn't quite right; the sleep was in the wrong place, as
pointed out by @gracjan.

Rufflewind authored Jan 17, 2017 and Ben Gamari committed Jan 17, 2017

    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

Unfortunately it's not clear why but this has been failing on Harbormaster.

Ben Gamari authored Jan 17, 2017 and Ben Gamari committed Jan 17, 2017

Some operating systems (e.g. Darwin) have very poor file timestamp
resolution.  On these systems GHC often fails to notice that B.hs
changes in this testsuite, leading to sporatic test failures. Add a
sleep to ensure the change is noticed.

Test Plan: Validate

Reviewers: ezyang, austin

Subscribers: mpickering, gracjan, thomie

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

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

Summary:
Add two missing test files for T13082.
The reason they were missing is because the .gitignore
contains a very harmful and broad wildcard `foo*`. Why?

Test Plan: make test TEST="T13082_good T13082_fail"

Reviewers: austin, bgamari, simonmar, erikd

Reviewed By: erikd

Subscribers: thomie

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

GHC Trac Issues: #13082

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

Summary:
This patch is courtesy of @awson.

Currently, whenever GHC catches a segfault on Windows, it simply reports the
somewhat uninformative message
`Segmentation fault/access violation in generated code`. This patch adds to
the message the type of violation (read/write/dep) and location information,
which should help debugging segfaults in the future.

Fixes #13108.

Test Plan: Build on Windows

Reviewers: austin, erikd, bgamari, simonmar, Phyx

Reviewed By: bgamari, Phyx

Subscribers: awson, thomie, #ghc_windows_task_force

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

GHC Trac Issues: #13108

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

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.

Summary:
A few related problems:

- CoAxioms, like DFuns, are implicit and never exported,
  so we have to make sure we treat them the same way as
  DFuns: in RnModIface we need to rename references to
  them with rnIfaceImplicit and in mergeSignatures we need
  to NOT check them directly for compatibility (the
  test on the type family will do this check for us.)

- But actually, we weren't checking if the axioms WERE
  consistent.  This is because we were forwarding all
  embedded CoAxiom references in the type family TyThing
  to the merged version, but that reference was what
  checkBootDeclM was using as a comparison point.
  This is similar to a problem we saw with DFuns.

  To fix this, I refactored the handling of implicit entities in TcIface
  for Backpack.  See Note [The implicit TypeEnv] for the gory details.
  Instead of passing the TypeEnv around explicitly, we stuffed it in
  IfLclEnv.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, simonpj, austin

Subscribers: thomie

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

Summary:
A basket of fixes and improvements:

- The permissible things that one can write in a type
  class definition in an hsig file has been reduced
  to encompass the following things:

    - Methods
    - Default method signatures (but NOT implementation)
    - MINIMAL pragma

  It is no longer necessary nor encouraged to specify
  that a method has a default if it is mentioned in
  a MINIMAL pragma; the MINIMAL pragma is assumed to
  provide the base truth as to what methods need to
  be implemented when writing instances of a type
  class.

- Handling of default method signatures in hsig was
  previously buggy, as these identifiers were not exported,
  so we now treat them similarly to DFuns.

- Default methods are merged, where methods with defaults
  override those without.

- MINIMAL pragmas are merged by ORing together pragmas.

- Matching has been relaxed: a method with a default can
  be used to fill a signature which did not declare the
  method as having a default, and a more relaxed MINIMAL
  pragma can be used (we check if the signature pragma
  implies the final implementation pragma, on the way
  fixing a bug with BooleanFormula.implies, see #13073)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #13041

Summary:
Two major bug-fixes:

    - Check that fixities match between hsig and implementation

    - Merge and preserve fixities when merging signatures
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, simonpj, austin

Subscribers: thomie

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

GHC Trac Issues: #13066

Summary:
This won't stop people from attempting to use this identifier
(since it is still always going to be in the export list), but
having an explicit reference to something people shouldn't
use is a smell, so warn about it.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

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

Summary:
If you use an inherited signature from another package in your own code,
the only valid PVP bound you can specify for this package is an *exact*
version bound.  This is because the signature is used both covariantly
(it provides declarations for import) and contravariantly (it specifies
what is required).  However, this is a bit distressing if you want to
use a PVP-style bound that allows for upgrading a package.  So there is
a dichotomy:

    1. Any signatures that come from packages with exact bounds
    (this includes, in particular, signature packages, who are
    included solely to make declarations available), can be
    used without problem by modules, but

    2. Any signatures that come from packages that are version
    bounded (i.e., any package that also provides modules) must
    NOT be used, because if they were used, they could break
    under a PVP policy that allows relaxations in the needed
    requirements.

To help users avoid situation (2), I've added a warning to all
signature declarations that come solely from (2).  This is not
perfect; you might still end up relying on some type identity
specified by a signature in a version-bounded package, but it
should help catch major errors.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie

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

Summary:
Generally speaking, it's not possible to "hide" a requirement from a
package you include, because if there is some module relying on that
requirement, well, you can't just wish it out of existence.

However, some packages don't have any modules.  For these, we can
validly thin out requirements; indeed, this is very convenient if
someone has published a large signature package but you only want
some of the definitions.

This patchset tweaks the interpretation of export lists in
signatures: in particular, they no longer need to refer to
entities that are defined locally; they range over both the current
signature as well as any signatures that were inherited from
signature packages (defined by having zero exposed modules.)

In the process of doing this, I cleaned up a number of other
things:

* rnModIface and rnModExports now report errors that occurred
  during renaming and can propagate these to the TcM monad.
  This is important because in the current semantics, you can
  thin out a type which is referenced by a value you keep;
  in this situation, we need to error (to ensure that all
  types in signatures are rooted, so that we can determine
  their identities).

* I ended up introducing a new construct 'dependency signature;
  to bkp files, to make it easier to tell if we were depending
  on a signature package.  It's not difficult for Cabal to
  figure this out (I already have a patch for it.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, austin, bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #12994

David Feuer authored Jan 10, 2017 and David Feuer committed Jan 10, 2017

Suppose we have

```
data Node a = Node2 !Int a a | Node3 !Int a a a
instance Traversable Node where
  traverse f (Node2 s x y) = Node2 s <$> f x <*> f y
  ...

```

Since `Node2` is partially applied, we wouldn't inline its
wrapper.  The result was that we'd box up the `Int#` to put
the box in the closure passed to `fmap`. We now allow the wrapper
to inline when partially applied, so GHC stores the `Int#`
directly in the closure.

Reviewers: rwbarton, mpickering, simonpj, austin, bgamari

Reviewed By: simonpj, bgamari

Subscribers: mpickering, thomie

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

GHC Trac Issues: #12990

takano-akio authored Jan 10, 2017 and Ben Gamari committed Jan 10, 2017

When fusion rules successfully fire, we are left with calls to
*FB functions. They are higher-order functions, and therefore they
often benefit from inlining. This is particularly important when
then final consumer is a strict fold (foldl', length, etc.), because
not inlining these functions means allocating a function closure
for each element in the list, which often is more costly than what
fusion eliminates.

Nofib shows a slight increase in the binary size:

------------------------------------------------------------------------
       Program           Size    Allocs   Runtime   Elapsed  TotalMem
------------------------------------------------------------------------
   gen_regexps          -0.3%      0.0%     0.000     0.000      0.0%
        puzzle          +0.8%      0.0%     0.089     0.090      0.0%
       reptile          +0.8%     -0.0%     0.008     0.008      0.0%
------------------------------------------------------------------------
           Min          -0.3%     -0.0%     -7.3%     -7.1%      0.0%
           Max          +0.8%     +0.0%     +7.8%     +7.7%     +1.8%
Geometric Mean          +0.0%     -0.0%     +0.2%     +0.2%     +0.0%
------------------------------------------------------------------------

Reviewers: simonpj, austin, hvr, bgamari

Reviewed By: simonpj

Subscribers: simonpj, thomie

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

GHC Trac Issues: #13001