GitLab

unbreak stdcall handling (caused by recent change to Outputable instance for CCallConv)

Eliminate all vestiages of UsageTy, in preparation for
	Keith's new version.  Hurrah!

	Keith: LBVarInfo and usOnce,usMany are still there,
	because I know you have eliminated LBVarInfo, and I didn't
	want to cause unnecessary conflicts.

Merging the following onto the HEAD:

|   1.61.2.1  +2 -4      fptools/ghc/compiler/rename/RnHsSyn.lhs
|   1.135.2.1 +10 -0     fptools/ghc/compiler/rename/RnSource.lhs

Original comment (keithw):

Remove derivings FVs from tyClDeclFVs, because they aren't needed by
interface files.  Instead, we return these FVs from
finishSourceTyClDecl.

Take into account the patchlevel when figuring out if we're
bootstrapping or not.

Clean up the AbsC -> AbsC translation of array operations.

* MachOps MO_ReadOSBI and MO_WriteOSBI, which previously did
  array indexing, are gone.  We translate now just to plain
  memory references and explicit address computations.  This
  has the happy side effect that all MachOps now return exactly
  one result (previously it was 0 or 1), cleaning up various
  bits of code.

  As a result the Abstract C structure now contains an unneccessary
  restriction, which is that the result of a MachOp can only be
  assigned to a temporary.  This made sense when MachOps had variable
  numbers of results (0, 1 or 2, originally), but is no longer needed.
  MachOps applied to args could now be allowed to appear as
  arbitrary nodes in expression trees, but so far they are not.

* Get rid of CAddrMode constructor CMem, since it is a special case of
  CVal with a RegRelative of CIndex.

AbstractC is inconsistent and non-orthogonal.  The StixStmt + StixExpr
combination expresses a large part of what AbstractC does in a cleaner
and simpler way, IMO.

Import lookupModuleEnv inside #ifdef GHCI

Generalise types of minusUFM and intersectUFM_C (this was applied long
ago to FiniteMap, IIRC).

Untested: I haven't got a build tree handy, so please shoot me if this
2-line change to two type signatures is type-incorrect.  Sorry!

---------
		Main.main
		---------

A bunch of related fixes concerning 'main'

* Arrange that 'main' doesn't need to be defined in module Main;
  it can be imported.

* The typechecker now injects a binding
	Main.$main = PrelTopHandler.runMain main

  So the runtime system now calls Main.$main, not PrelMain.main.
  With z-encoding, this look like
		Main_zdmain_closure

* The function
  	PrelTopHandler.runMain :: IO a -> IO ()
  wraps the programmer's 'main' in an exception-cacthing wrapper.

* PrelMain.hs and Main.hi-boot are both removed from lib/std, along
  with multiple lines of special case handling in lib/std/Makefile.
  This is a worthwhile cleanup.

* Since we now pick up whatever 'main' is in scope, the ranamer gets
  in on the act (RnRnv.checkMain).  There is a little more info to
  get from the renamer to the typechecker, so I've defined a new type
  Rename.RnResult (c.f. TcModule.TcResult)

* With GHCi, it's now a warning, not an error, to omit the binding
  of main (RnEnv.checkMain)

* It would be easy to add a flag "-main-is foo"; the place to use
  that information is in RnEnv.checkMain.


-------

On the way I made a new type,
	type HscTypes.FixityEnv = NameEnv Fixity
and used it in various places I'd tripped over

Imports only

Imports only

Imports and comments only

Imports only

Also implement MO_32U_to_8U for sparc.  sigh.

Implement missing MachOp, MO_8U_to_32U, for sparc.  (duh!)

Expand out use of modifyIORef because 4.08.2 doesn't have that.

-----------------------------
	Improve type validity checking
	-----------------------------

Two main effects here

a) Type synonyms can be unboxed tuples
	tupe T = (# Int, Int #)

	f :: Int -> T

b) Hoisting works for implicit parameters

	f :: Int -> (?x::Int) => Int

Correct assertion

Tighten up syntax w.r.t. Haskell 98; this is disallowed:

	(a `op` b) = ...

since a parenthesised lhs must be followed by at least one parameter.

Foreign import/export declarations now conform to FFI Addendum Version 1.0

* The old form of foreign declarations is still supported, but generates
  deprecation warnings.

* There are some rather exotic old-style declarations which have become
  invalid as they are interpreted differently under the new scheme and there
  is no (easy) way to determine which style the programmer had in mind (eg,
  importing a C function with the name `wrapper' where the external name is
  explicitly given will not work in some situations - depends on whether an
  `unsafe' was specified and similar things).

* Some "new" old-style forms have been introduced to make parsing a little bit
  easier (ie, avoid shift/reduce conflicts between new-style and old-style
  grammar rules), but they are few, arcane, and don't really hurt (and I won't
  tell what they are, you need to find that out by yourself ;-)

* The FFI Addendum doesn't specify whether a header file that is requested for
  inclusion by multiple foreign declarations should be included only once or
  multiple times.  GHC at the moment includes an header as often as it appears
  in a foreign declaration.  For properly written headers, it doesn't make a
  difference anyway...

* Library object specifications are currently silently ignored.  The feature
  was mainly requested for external calls in .NET (ie, calls which invoke C
  routines when Haskell is compiled to ILX), but those don't seem to be
  supported yet.

* Foreign label declarations are currently broken, but they were already
  broken before I started messing with the stuff.

The code is moderately tested.  All modules in lib/std/ and hslibs/lang/
(using old-style declarations) still compile fine and I have run a couple of
tests on the different forms of new-style declarations.

pprFCall: avoid/reduce name-capture problem (as was, safe calling
the C function id() would break.)

Include the patchlevel in the hi version number.

More wibbles on deriving with -fallow-undecidable-instances

Wibbles to yesterdays changes

Fix a classic bug: copying a Haskell string with one of the C string
functions (in this case strncpy()) is wrong when the string contains
'\0' characters.

The symptom in this case is that Happy parsers created with -ag don't
work in GHCi, because the state tables are encoded as strings
containing lots of '\0' elements.

-----------------------------
	Tidy up the top level of TcModule
	-----------------------------

This commit started life as sorting out the TcInstDcls thing that
we got wrong a few weeks back, but it spiraled out of control.

However, the result is a nice tidy up of TcModule.

typecheckModule/tcModule compiles a module from source code
typecheckIface/tcIface   compiles a module from its interface file
typecheckStmt		 compiles a Stmt
typecheckExpr		 compiles a Expr

tcExtraDecls is used by typecheckStmt/typecheckExpr
	to compile interface-file decls.
	It is just a wrapper for:

tcIfaceImports, which is used by tcExtraDecls and tcIface
	to compile interface file-file decls.

tcImports, is similar to tcIfaceImports, but is used only by tcModule

tcIfaceImports is used when compiling an interface, and can
	therefore be quite a bit simpler

Improved printing

comsetic only: shorten some lines.

Simplify the package story inside the compiler.  The new story is
this:

  The Finder no longer determines a module's package based on its
  filesystem location.  The filesystem location indicates only whether
  a given module is in the current package or not (i.e. found along
  the -i path ==> current package, found along the package path ==>
  other package).

  Hence a Module no longer contains a package name.  Instead it just
  contains PackageInfo, which is either ThisPackage or AnotherPackage.
  The compiler uses this information for generating cross-DLL calls
  and omitting certain version information from .hi files.

  The interface still contains the package name.  This isn't used for
  anything right now, but in the future (when we have hierarchical
  libraries) we might use it to automatically determine which packages
  a binary should be linked against.  When building a package, you
  should still use -package-name, but it won't be fatal if you don't.

The warning/error about package name mismatches has gone away.

Cleanup sweep, we can now use more of the std fptools build system
machinery in here.

Fix debug build.

Fix syntax error in printing indirect calls in sparc assembly.

cope with the fact that StgTickyHeader is no more

x86 only: remove special ccall support for calling PerformGC_wrapper
using dodgy-looking calling convention.  PerformGC_wrapper was last
seen alive in GHC 3.X, AFAIK.

sparc NCG fixes for f-i-dynamic.

Teach the NCG how to do f-i-dynamic.  Nothing unexpected.
sparc-side now needs fixing.

Allow constructors with non-ptr fields to be allocated in-line.

------------
	Rule phasing
	------------

This commit adds a little more control to when rules are enabled.

  {-# RULES
       "foo" [2] forall ...
       "baz" [~2] forall ...
  #-}

Rule "foo" is active in phase 2 and later.  The new thing is that the
"~2" means that Rule "baz" is active in phase 3 and earlier.
(Remember tha phases decrease towards zero.)

All the machinery was there to implement this, it just needed the syntax.


Why do this?  Peter Gammie (at UNSW) found that rules weren't firing
because of bindings of the form

	M.f = f
	f = ....

where the rules where on the M.f binding.  It turned out that an old
hack (which have for some time elicited the harmless "shortMeOut" debug
warnings) prevented this trivial construction from being correctly
simplified.  The hack in turn derived from a trick in the way the
foldr/build rule was implemented....and that hack is no longer necessary
now we can switch rules *off* as well as *on*.


There are consequential changes in the Prelude foldr/build RULE stuff.
It's a clean-up.... Instead of strange definitions like
	map = mapList
which we had before, we have an ordinary recursive defn of map, together
with rules to convert first to foldr/build form, and then (if nothing
happens) back again.

There's a fairly long comment about the general plan of attack in
PrelBase, near the defn of map.

Generate better code for lets whose RHS is a simple fn or constructor
application.  Details are in comment in code.

Catch up with recent changes in the middle end that changed the
assumptions about constructor applications: it is not necessarily the
case any more that constructor applications are always saturated in
the output from CorePrep.

For a non-saturated constructor application there is always a curried
worker function that can be called instead.  This change updates the
byte code generator to use the curried worker when necessary.

Also: a couple of micro-optimisations/cleanups.

----------------------
	Zero-constructor types
	----------------------

If we have

	data T
	data S = MkS !T

we were getting a crash in the compiler because ctrlRetConvAlg
didn't know what to do for zero-constructor types.

This fix arbitrarily says that they use a non-vectored return,
which fixes the crash.  (Since they only have bottom values,
the return never gets exercised, but GC and exception handling
should work.)

What is still unclear is how we handle data types that are defined
with zero constructors in an hi-boot file.  I think that Bad Things
may well happen if you do a 'seq' on them before we get up to the
definition.  (e.g. as a result of this fix we'll say "unvectored"
whereas the truth may be "vectored".)  This obviously doesn't happen
much (because at present we'd get a compiler crash in ctrlRetConvAlg,
but we should look into it.