1. 14 Apr, 2001 2 commits
  2. 13 Apr, 2001 4 commits
    • panne's avatar
      [project @ 2001-04-13 21:37:42 by panne] · 21c60059
      panne authored
      First steps toward a better typing of f.e.d. and friends: Make FunPtr
      a fully-fledged data type, not a renaming for Ptr. This is necessary,
      because the FFI "looks through" newtypes, which we don't want in this
    • lewie's avatar
      [project @ 2001-04-13 17:49:23 by lewie] · d37c0740
      lewie authored
      Add new test for IP.
    • panne's avatar
      [project @ 2001-04-13 13:37:24 by panne] · 486c94ae
      panne authored
      To keep people debugging GHC sane, disable CSE in *every* module using
      GLOBAL_VARs. This solves the problem with the strange -M output, where
      some global IORefs were commoned up (again). CSE seems to be really
      broken, but a comment in ghc/Makefile promises a fix.  Anybody out
      there with this fix on his/her hard disk: Please commit soon!
    • dsyme's avatar
      [project @ 2001-04-13 03:50:52 by dsyme] · 1276e713
      dsyme authored
      More changes to the ILX code generator, currently only relevant to Don
  3. 12 Apr, 2001 4 commits
  4. 11 Apr, 2001 6 commits
  5. 10 Apr, 2001 4 commits
  6. 09 Apr, 2001 2 commits
  7. 08 Apr, 2001 1 commit
  8. 07 Apr, 2001 4 commits
  9. 06 Apr, 2001 4 commits
    • sewardj's avatar
      [project @ 2001-04-06 16:15:39 by sewardj] · 77cdc77c
      sewardj authored
      Commit the following change:
      > > Why the default libdir is /usr/local/lib
      > > and not /usr/local/lib/ghc-<version>?
      > Great question.  I end up running config with the likes of
      > `--libdir=/usr/local/lib/ghc-5.0' every time, which gets to
      > be annoying ;-)
      I've been meaning to fix this for a while, but couldn't see a good way
      to do it.  I found a (mildly-hacky) way to do it today: in
      fptools/ghc, we override $(libdir) to be
      $(libdir)/$(ProjectNameShort)-$(ProjectVersion), so everything inside
      fptools/ghc will be installed in the subdirectory.  fptools/hslibs is
      a bit more of a hack.
    • sewardj's avatar
      [project @ 2001-04-06 10:53:08 by sewardj] · 6a48b75e
      sewardj authored
    • lewie's avatar
      [project @ 2001-04-06 04:28:53 by lewie] · f752bd00
      lewie authored
      More Version Blues.
    • lewie's avatar
      [project @ 2001-04-06 01:07:23 by lewie] · 38bb4252
      lewie authored
      Fix a bad case of the Version Change Blues ;-)
  10. 05 Apr, 2001 9 commits
    • sewardj's avatar
      [project @ 2001-04-05 14:45:29 by sewardj] · 08a58bed
      sewardj authored
      Denouncements for 5.0.
    • sewardj's avatar
      [project @ 2001-04-05 13:48:22 by sewardj] · 59c4fee7
      sewardj authored
      Now 5.00.
    • sewardj's avatar
      [project @ 2001-04-05 13:47:27 by sewardj] · 822fbcdc
      sewardj authored
      Advance the version number to 5.00.  Wahey!  Not that this means we're
      official _at_ 5.0 yet, tho.
    • simonpj's avatar
      [project @ 2001-04-05 11:54:37 by simonpj] · 197a5ee7
      simonpj authored
      Make type synonyms work right in H98
    • simonpj's avatar
      [project @ 2001-04-05 11:48:59 by simonpj] · 06776c85
      simonpj authored
      Add tc120
    • simonpj's avatar
      [project @ 2001-04-05 11:48:26 by simonpj] · 4b96a23a
      simonpj authored
      Remove tcfail081; it is moving to should_compile
    • simonpj's avatar
      [project @ 2001-04-05 11:31:26 by simonpj] · 11197236
      simonpj authored
      	Better grouping for ty/cls decls
      When finding mutually-recursive groups of type and class decls,
      we shouldn't include classes mentioned in a deriving clause as
      edges. E.g.
      	class Eq a where ...
      	data Bool = True | False deriving( Eq )
      Eq and Bool are not mutually recursive.
      The edges are computed by RnHsSyn.tyClDeclFVs, so we remove the
      derivings from there.
      There a consequential fix in RnSource.rnSourceDecl
    • simonpj's avatar
      [project @ 2001-04-05 11:28:53 by simonpj] · b58e1155
      simonpj authored
      Improve error reporting
    • simonpj's avatar
      [project @ 2001-04-05 11:28:36 by simonpj] · f05b6981
      simonpj authored
      	Better arity stuff
      * CoreToStg now has a local function, predictArity, to
        predict the code-gen arity of a function. Better not to
        use CoreUtils.exprArity, because predictArity is a very
        local thing
      * CoreUtils.exprArity is freed to do a better job.  Comments
      exprArity is a cheap-and-cheerful version of exprEtaExpandArity.
      It tells how many things the expression can be applied to before doing
      any work.  It doesn't look inside cases, lets, etc.  The idea is that
      exprEtaExpandArity will do the hard work, leaving something that's easy
      for exprArity to grapple with.  In particular, Simplify uses exprArity to
      compute the ArityInfo for the Id.
      Originally I thought that it was enough just to look for top-level lambdas, but
      it isn't.  I've seen this
      	foo = PrelBase.timesInt
      We want foo to get arity 2 even though the eta-expander will leave it
      unchanged, in the expectation that it'll be inlined.  But occasionally it
      isn't, because foo is blacklisted (used in a rule).
      Similarly, see the ok_note check in exprEtaExpandArity.  So
      	f = __inline_me (\x -> e)
      won't be eta-expanded.
      And in any case it seems more robust to have exprArity be a bit more intelligent.