GitLab

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

Test Plan: validate

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, ezyang, carter

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

This patch set makes us no longer assume that a package key is a human
readable string, leaving Cabal free to "do whatever it wants" to allocate
keys; we'll look up the PackageId in the database to display to the user.
This also means we have a new level of qualifier decisions to make at the
package level, and rewriting some Safe Haskell error reporting code to DTRT.

Additionally, we adjust the build system to use a new ghc-cabal output
Make variable PACKAGE_KEY to determine library names and other things,
rather than concatenating PACKAGE/VERSION as before.

Adds a new `-this-package-key` flag to subsume the old, erroneously named
`-package-name` flag, and `-package-key` to select packages by package key.

RFC: The md5 hashes are pretty tough on the eye, as far as the file
system is concerned :(

ToDo: safePkg01 test had its output updated, but the fix is not really right:
the rest of the dependencies are truncated due to the fact the we're only
grepping a single line, but ghc-pkg is wrapping its output.

ToDo: In a later commit, update all submodules to stop using -package-name
and use -this-package-key.  For now, we don't do it to avoid submodule
explosion.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, carter

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

The general approach is to add a new field to the package database,
reexported-modules, which considered by the module finder as possible
module declarations.  Unlike declaring stub module files, multiple
reexports of the same physical package at the same name do not
result in an ambiguous import.

Has submodule updates for Cabal and haddock.

NB: When a reexport renames a module, that renaming is *not* accessible
from inside the package.  This is not so much a deliberate design choice
as for implementation expediency (reexport resolution happens only when
a package is in the package database.)

TODO: Error handling when there are duplicate reexports/etc is not very
well tested.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Conflicts:
	compiler/main/HscTypes.lhs
	testsuite/.gitignore
	utils/haddock

Summary:
Previously, both Cabal and GHC defined the type PackageId, and we expected
them to be roughly equivalent (but represented differently).  This refactoring
separates these two notions.

A package ID is a user-visible identifier; it's the thing you write in a
Cabal file, e.g. containers-0.9.  The components of this ID are semantically
meaningful, and decompose into a package name and a package vrsion.

A package key is an opaque identifier used by GHC to generate linking symbols.
Presently, it just consists of a package name and a package version, but
pursuant to #9265 we are planning to extend it to record other information.
Within a single executable, it uniquely identifies a package.  It is *not* an
InstalledPackageId, as the choice of a package key affects the ABI of a package
(whereas an InstalledPackageId is computed after compilation.)  Cabal computes
a package key for the package and passes it to GHC using -package-name (now
*extremely* misnamed).

As an added bonus, we don't have to worry about shadowing anymore.

As a follow on, we should introduce -current-package-key having the same role as
-package-name, and deprecate the old flag.  This commit is just renaming.

The haddock submodule needed to be updated.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonpj, simonmar, hvr, austin

Subscribers: simonmar, relrod, carter

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

Conflicts:
	compiler/main/HscTypes.lhs
	compiler/main/Packages.lhs
	utils/haddock

Summary:
As a security precaution, GHCi helpfully refuses to run a .ghci file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways.
This means that .ghci files installed in a global location, say under /usr/local/, can now be read.

Fixes #9324

Test Plan:
```
$ sudo touch .ghci
$ ghci
```
Notice that the warning about the file being owned by someone else is now gone.

Reviewers: austin

Reviewed By: austin

Subscribers: phaskell, simonmar, carter, nomeata, relrod

Projects: #ghc

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

Summary:
Currently, if the same identifier is imported via multiple modules, ghci
shows multiple completions for it. Use the nub of the completions
instead so that it only shows up once.
Signed-off-by: Shachaf Ben-Kiki <shachaf@gmail.com>

Test Plan: by hand

Reviewers: simonmar, austin, hvr

Reviewed By: austin, hvr

Subscribers: hvr, simonmar, relrod, carter

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

All the initial work on this was done fy 'archblob' (fcsernik@gmail.com);
thank you!

I reviewed the patch, started some tidying, up and then ended up in a huge
swamp of changes, not all of which I can remember now.  But:

* To suppress kind arguments when we have -fno-print-explicit-kinds,
    - IfaceTyConApp argument types are in a tagged list IfaceTcArgs

* To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType.

* When printing data/type family instances for the user, I've made them
  print out an informative RHS, which is a new feature. Thus
        ghci> info T
        data family T a
        data instance T Int = T1 Int Int
        data instance T Bool = T2

* In implementation terms, pprIfaceDecl has just one "context" argument,
  of type IfaceSyn.ShowSub, which says
       - How to print the binders of the decl
         see note [Printing IfaceDecl binders] in IfaceSyn
       - Which sub-comoponents (eg constructors) to print

* Moved FastStringEnv from RnEnv to OccName

It all took a ridiculously long time to do.  But it's done!

This replaces the previous `default-extensions` by per-file declared
`{-# LANGUAGE ... #-}` pragmas.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

The user explicitly requested this script on the command-line, so it's
unnecessary to require that the script is also owned by the user.
Also, it is currently impossible to make a GHCi wrapper that invokes a
custom script without first making a copy of the script to circumvent
the permissions check, which seems wrong.

GHCi didn't reset the multiline prompt when an exception (in particular,
the UserInterrupt exception) occured. This commit uses `finally` to
reset the prompt in all cases.

Fixes Trac #8640

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

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

This changes the prefix-based lookup to prefer macros over builtins only if
the macro name matches an existing builtin name. See #8305 for more details.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Fixes: #7685

It's deprecated

* The main change is to suppress printing (in types) of
     kind for-alls
     kind applications
  The new flag -fprint-explicit-kinds prints them as before
  (by analogy with the existing -fprint-explicit-foralls)

* I also took advantage of the fact that SDoc now has access
  to DynFlags, to tidy up the way in which explicit for-alls
  are printed.  Instead of passing a boolean flag around, we
  now simply consult the DynFlags.  Much neater.

I still need to add documentation for the flag

Also a small formatting change in GHCi :help

This commit addresses #8051 by fixing

 - Incorrect column indices reported in error messages for
   single-line and multi-line input,

 - incorrect line numbers reported in error messages for
   expressions entered in multi-line input, and

 - inhibiting the confusing interaction between `:{` and `:set +m`
   causing the triggering of implicit multi-line continuation
   mode right after `:}` terminates the multi-line entry block.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

`:show paths` dumps the current working directory as well
as the current value of the `importPaths` dynamic flags field.

This addresses #8172
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

An unbuffered handle is very slow to output to and there doesn't seem to
be any reason to have these handles unbuffered.

This restores the original behaviour that was broken accidentally during
the refactoring peformed via 4f764d06.

This has been broken effectively for all GHC 7.6.x releases.

This commit also updates the GHC user guide section
regarding the `set prompt` command and closes #8047.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This commit changes the syntax and story around overlapping type
family instances. Before, we had "unbranched" instances and
"branched" instances. Now, we have closed type families and
open ones.

The behavior of open families is completely unchanged. In particular,
coincident overlap of open type family instances still works, despite
emails to the contrary.

A closed type family is declared like this:
> type family F a where
>   F Int = Bool
>   F a   = Char
The equations are tried in order, from top to bottom, subject to
certain constraints, as described in the user manual. It is not
allowed to declare an instance of a closed family.

Clang doesn't like whitespace between macro and arguments.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Now that we share stdin with the program, we have to check for
handle-closed as well as EOF, as the program might have closed
stdin.