GitLab

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

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.

Patch mostly from Lennart Augustsson in #803, with additions to
Task.c by me.

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 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.

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

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? 

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.

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.

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.

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.

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

	MERGE TO STABLE

Fixes Trac #827
Test is should_compiler/ds058

  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.

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.

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