Egregious bug in tcLHsConResTy

This terrible bug in tcLHsConTy is pretty much guaranteed to show up
on an program involving a GADT with more than one type parameter.

This bug isn't present in the STABLE branch.

Manuel: it is *not* necesary to merge this patch into the FC branch;
just ignore it.

Comments about improvements to SpecConstr

Remove HasBounds-instance and implement MArray.getBounds instead

Fix Array imports

Where we use $(GhcHcOpts), also add $(GhcStage1HcOpts)
This fixes building the compiler with -prof in $(GhcStage1HcOpts)

fixes to the stage2 build following removal of old FFI syntax

fix bug in task freeing

add some more options to stage 2

remove debugging code accidentally left in

remember that old FFI syntax has been dropped

only define GHCI if $(GhcWithInterpreter)=YES, also add -threaded

move altzone test to base package

remove unused FPTOOLS_CHECK_HTYPE macro

Remove the artifical cap on the number of workers
See #805.  This was here to catch bugs that resulted in an infinite
number of worker threads being created.  However, we can't put a
reasonable bound on the number of worker threads, because legitimate
programs may need to create large numbers of (probably blocked) worker
threads.  Furthermore, the OS probably has a bound on the number of
threads that a process can create in any case.

Remove old FFI syntax
See #815

make exit() overridable, for use in DLLs
See #753

More fixes to pre-matching and pre-subsumption

Actually this patch fixes two errors. one was a trivial typo in
tha last patch (b_ty should be b_tau), which led to an infinite loop
when compiling Data.Generic.Twins.

Fixing that revealed a more serious error in the same function.
I was sloppy about dealing robsutly with name-capture for nested
quantifiers in pre-subsumption and pre-matching; and sure enough
I got bitten.  Sigh.  I think it is right now.

Group exports so that all length functions are together; no semantic change

Check that lazy patterns are for lifted types

A lazy pattern match must be for a lifted type. This is illegal:

f x = case g x of
                ~(# x,y #) -> ...

This commit fixes the problem.  Trac #845, test is tcfail159

Spelling in a comment

Remove srcSpanStartLine/srcSpanEndLine crash

srcSpanStartLine/srcSpanEndLine panic on UnhelpfulLoc. They should not
really be exported by SrcLoc at all, but unfortunately they are used in
Lexer.x, which knows enough to avoid the panic.

However the call in RnEnv didn't know, and the panic was triggered
by Template Haskell spliced code.  This patch fixes it by exporting
the predicate RnEnv wanted, namely isOneLineSpan.

Replace deprecated AC_TRY_COMPILE macro with the reccomended replcament
See: http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html

Add ghc and version number in .ident directive in NCG
Just because we can and because every other compiler does,
lets stick in an identifier directive: .ident "GHC x.y.z"
into the assembly output of the NCG.

Support the GNU non-exec stack annotation system
On recent GNU ELF systems one can mark an object file as not
requiring an executable stack. If all objects- linked into a
program have this note then the program will not use an executable
stack, which is good for security (and some distros have it as a
QA policy). GHC generated code does not need an executable stack
so add the note to the assembly output of the native code
generator (conditional on a configure test).

Complain more loudly if any of the hsc2hs phases fail
previously hsc2hs just exits with a non-zero exit code, now if any of
the compilation, linking or runing phases fail then we get a message
saying so and the failing command is printed.

Remember to free() memory on exit
Patch mostly from Lennart Augustsson in #803, with additions to
Task.c by me.

Fix pre-subsumption and pre-matching

The pre-subsuption and pre-matching functions should NEVER make bogus
bindings of type variables, although they are free to bale out and make
too few bindings.

I hadn't been thiking carefully enough about this, and there were two
separate bugs.

- Firstly, in pre-subsumption we must ignore the 'theta'
  part of any overloaded type.

- Second, in pre-matching, we must return the empty subustition
  on a mis-match, rather than returning the substitution so far.

This bug showed up when compiling Data.Generics.Schemes.hs, and is
imortalised in test tc206

Improve error message

Improve a little-used error message.  Given
f :: a -> a
f x y = e
the error says

The equations for f have two arguments
but its type `a -> a' has only one

(Before, it said "its type `a' has only one" which is bogus.

Pull out common removal code, and detect does-not-exist correctly

Create our own directory in the temporary directory to avoid various races

Merge SysTools import declarations

Don't freeze the dynamic flags used for filename generation before the pipeline starts

#807: Removed double fclose of prof_file
prof_file was being fclose'd in both gen_XML_logfile and hs_exit, leading
to glibc complaining of a double free.

Add -fextended-default-rules and -fmono-pat-binds

Add -fextended-deafult-rules (in response to Don Stewart's message below),
and document them.

Also doucument -fmono-pat-binds/-fno-mono-pat-binds, which has been in
GHC a few weeks now.

(The two are in one patch because the diffs were so close together
that Darcs combined them.)

Simon

From: Donald Bruce Stewart [mailto:dons@cse.unsw.edu.au]
Sent: 07 August 2006 10:52

While we're thinking about defaulting, I have a question..

ghci uses an extended defaulting system, to allow things like:
        Prelude> reverse []
        []
to work, and to have the right instance of Show found. The manual says:

    "..it is tiresome for the user to have to specify the type, so GHCi extends
    Haskell's type-defaulting rules (Section 4.3.4 of the Haskell 98 Report
    (Revised)) as follows. If the expression yields a set of type constraints
    that are all from standard classes (Num, Eq etc.), and at least one is
    either a numeric class or the Show, Eq, or Ord class, GHCi will try to use
    one of the default types, just as described in the Report. The standard
    defaulting rules require that one of the classes is numeric; the difference
    here is that defaulting is also triggered at least one is Show, Eq, or Ord."

Currently, there is no way to get at this "extended" defaulting for compiled
modules. However, I have a use case for in fact doing this.

With runtime evaluated Haskell, embedding 'interpreters' (over hs-plugins) is
easy. lambdabot, for example, implements a sandboxed haskell eval system. But
it doesn't have access to the defaulting mechanism of ghci, so we have:

    dons:: > reverse []
    lambdabot:: Add a type signature
    dons:: > reverse [] :: [()]
    lambdabot:: []

Which is annoying -- newbies wonder why they have to add these extra
constraints to get a Show instance.

I'm wondering, since the extended defaulting mechanisms are already
implemented, could they be made available to compiled modules as well,
perhaps using a flag, -fextended-defaulting?

add a comment

Do pre-subsumption in the main subsumption check

This patch improves the subsumption check (in TcUnify.tc_sub) so that
it does pre-subsumption first.  The key code is in the case with
guard (isSigmaTy actual_ty); note the new call to preSubType.

Shorn of details, the question is this.  Should this hold?

forall a. a->a   <=   Int -> (forall b. Int)

Really, it should; just instantiate 'a' to Int.  This is just what
the pre-subsumption phase (which used in function applications),
will do.

I did a bit of refactoring to achieve this.

Fixes Trac #821.  Test tc205 tests.

Make unification robust to a boxy type variable meeting itself

Previously, the implicit assumption in unification is that a boxy
type variable could never occur on both sides of the unification,
so that we'd never find
bx5 :=: bx5

But the pre-subsumption stuff really means that the same variable
can occur on both sides.  Consider
forall a. a->Int <= bx5->Int
Then pre-subumption will find a->bx5; and the full subsumption step
will find bx5:=bx5.

However, I think there is still no possiblity of a full occurs-check
failure; that is,
bx5 :=: Tree bx5
Although I can't quite see how to prove it!  So I've added a
DEBUG test in uMetaVar to check for this case.

Added cabal-setup

Don't include the package name in a cost centre's module name
This is mainly to restore the old behaviour, but also we shouldn't
normally need the package name in a cost centre because only the
"main" package normally has cost centres.

Add a new section "Getting the Source" to both HACKING and README. But what about win32 users?

savingOldConfig: add Exception.block for extra paranoia

Refactor ghc-pkg
This patch fixes a couple of issues with the
    Be lazier in user config creation, and don't fail on missing configs.
patch. It puts the createDirectoryIfMissing back in and removes assumptions
that the package.conf file already exists.

No functionality changes
Consistently used spaces rather than tabs.
Removed trailing whitespace.
Wrapped comments to fit in a standard terminal.

Add notes about unsafeCoerce

.hi-boot-5 is obsolete; the earliest GHC we support uses .hi-boot-6

update to match .lhs-boot

get ReadP from the right place.

Improve error message for deriving

Lazy patterns are like wild-cards for overlap warnings

MERGE TO STABLE

Fixes Trac #827
Test is should_compiler/ds058

fix some problems with wired-in packages

oops, remove old packages when updating

fix symbols for GHC.PrimopWrappers

a couple more symbols need package names

Add missing import

Make -fcontext-stack into a dynamic flag

  This allows you to put -fcontext-stack into an options pragma,
  as requested by Trac #829

  While I was at it, I added OptIntPrefix to the forms allowed
  in CmdLineParser.

Deal correctly with infix type constructors in GADT decls

Improve pretty printing of ConDecl

fix parse error (merge-o, I think)

fix DEBUG build

missed one symbol that needs a package name

change wired-in Haskell symbols to include the package name

Unbox the Unique stored in a Name
I measured that this makes the comiler allocate a bit more, but it
might also make it faster and reduce residency.  The extra allocation
is probably just because we're not inlining enough somewhere, so I
think this change is a step in the right direction.

optimisations to newUnique

It turned out that newUnique was wasting one node of the splittable
uniq supply per invocation: it took the current supply, split it, used
the unique from one half and stored the other half in the monad.  In
other words, the unique in the supply stored in the monad was never
used.

This optimisation fixes that and adds a bit of strictness, which
together lead to small reduction in allocations by the compiler, and
possibly an improvement in residency (hard to tell for sure when GCs
move around).

tiny bit of extra strictness

Make a SplitUniqSupply contain an Int# rather than an Int
The I# constructor is always removed when we make a unique later
anyway, so this just saves a bit of time and allocation.

Use -package-name rather than -ignore-package

Remove most of the conflict checking and auto-hiding
Now that the module restriction has been lifted, the auto-hiding is
mostly not required.  GHC itself automatically hides old versions of a
package.

Generalise Package Support

This patch pushes through one fundamental change: a module is now
identified by the pair of its package and module name, whereas
previously it was identified by its module name alone.  This means
that now a program can contain multiple modules with the same name, as
long as they belong to different packages.

This is a language change - the Haskell report says nothing about
packages, but it is now necessary to understand packages in order to
understand GHC's module system.  For example, a type T from module M
in package P is different from a type T from module M in package Q.
Previously this wasn't an issue because there could only be a single
module M in the program.

The "module restriction" on combining packages has therefore been
lifted, and a program can contain multiple versions of the same
package.

Note that none of the proposed syntax changes have yet been
implemented, but the architecture is geared towards supporting import
declarations qualified by package name, and that is probably the next
step.

It is now necessary to specify the package name when compiling a
package, using the -package-name flag (which has been un-deprecated).
Fortunately Cabal still uses -package-name.

Certain packages are "wired in".  Currently the wired-in packages are:
base, haskell98, template-haskell and rts, and are always referred to
by these versionless names.  Other packages are referred to with full
package IDs (eg. "network-1.0").  This is because the compiler needs
to refer to entities in the wired-in packages, and we didn't want to
bake the version of these packages into the comiler.  It's conceivable
that someone might want to upgrade the base package independently of
GHC.

Internal changes:

  - There are two module-related types:

        ModuleName      just a FastString, the name of a module
        Module          a pair of a PackageId and ModuleName

    A mapping from ModuleName can be a UniqFM, but a mapping from Module
    must be a FiniteMap (we provide it as ModuleEnv).

  - The "HomeModules" type that was passed around the compiler is now
    gone, replaced in most cases by the current package name which is
    contained in DynFlags.  We can tell whether a Module comes from the
    current package by comparing its package name against the current
    package.

  - While I was here, I changed PrintUnqual to be a little more useful:
    it now returns the ModuleName that the identifier should be qualified
    with according to the current scope, rather than its original
    module.  Also, PrintUnqual tells whether to qualify module names with
    package names (currently unused).

Docs to follow.

comment formatting

unused import

unused import

remove more Addr bits

unused import

add default cases

redundant import

unused imports

unused import

remove unused bits, mostly to do with the Addr type

In interface files, store FastStrings rather than OccNames where possible
In all cases the namespace is known from the context, so this saves 1
byte per variable binding/occurrence (a few percent per iface file).

Add -fmono-pat-binds, and make it the default

In Haskell 98, pattern bindings are generalised.  Thus in
(f,g) = (\x->x, \y->y)
both f and g will get polymorphic types.  I have become convinced
that generalisation for pattern-bound variables is just a bridge
toof far. It is (I claim) almost never needed, and it adds significant
complication.  (All the more so if we add bang patterns.)

So the flag -fmono-pat-binds switches off generalisation for pattern
bindings.  (A single variable is treated as a degnerate funtction
binding.)

Furthremore, as an experiment, I'm making it the default.  I want
to see how many progarms fail with monomorphic pattern bindings.

You can recover the standard behaviour with -fno-mono-pa-binds.

Fix RULES lossage

Don Stewart and Duncan Coutts encountered the following situation.
f = <rhs>
{-# RULES f ... #-}
where f is not exported, but appears in the inlinings of other
functions that are exported.  Then what happened was that the desugarer
produced this:
M.f = f
f = <rhs>
where the rules get attached to the M.f. But since M.f's RHS is trivial
(just f) it was unconditionally inlinined at all its call sites,
thereby losing the RULES attached to it.

This *is* a fragile aspect of rules. However this fix solves the
problem by instead generating
f = M.f
M.f = <rhs>

A pretty small chanage to the desugarer does the job.  It still feels
a little fragile, bt it's certainly more robust than before.

Fix broken regex
Don't know how I managed to use this before... maybe a different regex
library.

fix bug in sample code

fix eran error message by reordering a couple of tests

Use a recursive error handler in case the exception causes more exceptions.

Check for overlap-flag differences in hi files

MERGE TO STABLE

I'd forgotten to compare the per-instance overlap flag when
comparing interface files, and that meant that consequential
recompilations weren't being triggered when the only change
was to add -fallow-overlapping-instances

Fixes Trac bug #824

Add a clarification about overlapping instances in the manual

Comments and import trimming

Experimental flag -fdicts-cheap

This experimental flag, -fdicts-cheap, makes a let-binding that bind a
value of dictionary type look cheap.  That in turn leads to more
eta expansion.  Instead of
f = /\a. \(d1:Ord a). let d2:Ord [a] = dfOrd a d1 in
                 \(x:a). <stuff>
which has arity 1, you get
f = /\a. \(d1:Ord a). \(x:a).
         let d2:Ord [a] = dfOrd a d1 in <stuff>
Now f has arity 2.

This can cretainly waste dictionary-construction work, if f is
partially applied to its dictionary argument.  However it has knock-on
effects.  Because f has arity 2, we won't float (f Int d) out of
\x. h (f Int d)
Floating f out of this lambda makes it impossible for an h/f fusion
rule to fire; and this unexpected loss of RULE application was the
immediate reason for implementing this flag. (Roman Leshchinskiy came
across this when working on array fusion.)

I've implemented the change only in CoreUtils.arityType, which
only affects eta expansion.  I thought of putting the change in
exprIsCheap, which is a more systematic place (the former calls
the latter) but

a) I wanted this under flag control, and the flags
are not readily available to all callers of exprIsCheap

b) I'm not 100% convinced that this change is a good
idea, so it's reasonable to do the narrowest change
that solves the immediate problem.

document that -fglasgow-exts is needed for RULES to work

do a better job of ignoring unrecognised pragmas

Don't z-encode module names in external-core output

re-add -fvia-C
There are still some fixes required to get the threaded RTS compilable
with the NCG, and apparently there are problems on 32-bit archs too.

Be lazier in user config creation, and don't fail on missing configs.

Z-Encode external-core output

HEAD doesn't z-encode external-core output (unlike 6.4). I suppose, that
this is unwanted behaviour. It probably results from this patch:

========================================================================
Fri Jan  6 17:30:19 CET 2006  simonmar
  * [project @ 2006-01-06 16:30:17 by simonmar]
  Add support for UTF-8 source files

[...]

Z-encoding has been moved right to the back end.  Previously we
used to Z-encode every identifier on the way in for simplicity,
and only decode when we needed to show something to the user.
Instead, we now keep every string in its UTF-8 encoding, and
Z-encode right before printing it out.

[...]
========================================================================

Greetings
Jan

Add %local-tag to external core output

Hello, this is my first patch contributed to GHC. If there are any
inadequacies about it (maybe like this introductory disclaimer), please
let me know about it.

So, the need for this patch arose, while I was involved with processing
hcr files (external core output) and I noticed, that the output didn't
fully conform to the specification [1].
No %local-tags were used, which turned out to be a real nuisance as it
was not possible to determine which VDEFs can be erased in a further
optimization process and which ones are exported by the module.

Since the specification does not define the meaning of the %local-tag, I
assume, it makes sense, that it tags all functions, that are not
exported by the module.

The patch does not fully comply to the specification, as in my
implementation a local tag may appear before a VDEF but not before a
VDEFG.

[1] An External Representation for the GHC Core Language
    (DRAFT for GHC5.02), page 3, line 1

Greetings
Jan

Remove bashisms from darcs-all

darcs-all may now be run with any POSIX-compatible /bin/sh.

Fix for warning message (bug #812)
say "{-# SOURCE #-}" rather than "{- SOURCE -}" in warning message.
Fixes http://hackage.haskell.org/trac/ghc/ticket/812

The dict-bindings in an IPBinds need not be in dependency order

This appears to be a long-standing bug, discovered by BlueSpec
(ravi@bluespec.com), Trac bug #795

The problem was that in an IP binding group, the dict bindings
aren't necessarily in dependency order; and if they aren't
we get a core-lint error.

Test tc203 checks this case.  (Though whether it shows up at
all depends a bit on accidental factors of binding ordering.)

x86 needs -fno-unit-at-a-time too
Fixes #809