1. 09 Apr, 2010 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #3955: renamer and type variables · b87e22d2
      simonpj@microsoft.com authored
      The renamer wasn't computing the free variables of a type declaration
      properly.  This patch refactors a bit, and makes it more robust,
      fixing #3955 and several other closely-related bugs.  (We were
      omitting some free variables and that could just possibly lead to a
      usage-version tracking error.
    • simonpj@microsoft.com's avatar
      Layout only · 858a5b26
      simonpj@microsoft.com authored
  2. 06 May, 2010 4 commits
  3. 05 May, 2010 3 commits
    • simonpj@microsoft.com's avatar
      Make the demand analyser sdd demands for strict constructors · c5b76e6f
      simonpj@microsoft.com authored
      This opportunity was spotted by Roman, and is documented in 
      Note [Add demands for strict constructors] in DmdAnal.
    • simonpj@microsoft.com's avatar
      Fix interaction of exprIsCheap and the lone-variable inlining check · 356e6869
      simonpj@microsoft.com authored
      See Note [Interaction of exprIsCheap and lone variables] in CoreUnfold
      This buglet meant that a nullary definition with an INLINE pragma
      counter-intuitively didn't get inlined at all.  Roman identified
      the bug.
    • simonpj@microsoft.com's avatar
      Matching cases in SpecConstr and Rules · 9abe2972
      simonpj@microsoft.com authored
      This patch has zero effect.  It includes comments,
      a bit of refactoring, and a tiny bit of commment-out
      code go implement the "matching cases" idea below.
      In the end I've left it disabled because while I think
      it does no harm I don't think it'll do any good either.
      But I didn't want to lose the idea totally. There's
      a thread called "Storable and constant memory" on
      the libraries@haskell.org list (Apr 2010) about it.
      Note [Matching cases]
      {- NOTE: This idea is currently disabled.  It really only works if
               the primops involved are OkForSpeculation, and, since
      	 they have side effects readIntOfAddr and touch are not.
      	 Maybe we'll get back to this later .  -}
         f (case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) ->
            case touch# fp s# of { _ -> 
            I# n# } } )
      This happened in a tight loop generated by stream fusion that 
      Roman encountered.  We'd like to treat this just like the let 
      case, because the primops concerned are ok-for-speculation.
      That is, we'd like to behave as if it had been
         case readIntOffAddr# p# i# realWorld# of { (# s#, n# #) ->
         case touch# fp s# of { _ -> 
         f (I# n# } } )
  4. 04 May, 2010 3 commits
  5. 17 Apr, 2010 1 commit
  6. 05 May, 2010 1 commit
  7. 04 May, 2010 1 commit
  8. 05 May, 2010 8 commits
  9. 04 May, 2010 3 commits
  10. 03 May, 2010 4 commits
  11. 02 May, 2010 1 commit
  12. 28 Apr, 2010 1 commit
  13. 27 Apr, 2010 3 commits
    • Ian Lynagh's avatar
      Fix "make 2" · a1969113
      Ian Lynagh authored
      The new Makefile logic was enabling the stage 1 rules when stage=2,
      so "make 2" was rebuilding stage 1.
    • Ian Lynagh's avatar
    • Simon Marlow's avatar
      --make is now the default (#3515), and -fno-code works with --make (#3783) · 7828bf3e
      Simon Marlow authored
      If the command line contains any Haskell source files, then we behave
      as if --make had been given.
      The meaning of the -c flag has changed (back): -c now selects one-shot
      compilation, but stops before linking.  However, to retain backwards
      compatibility, -c is still allowed with --make, and means the same as
      --make -no-link.  The -no-link flag has been un-deprecated.
      -fno-code is now allowed with --make (#3783); the fact that it was
      disabled before was largely accidental, it seems.  We also had some
      regressions in this area: it seems that -fno-code was causing a .hc
      file to be emitted in certain cases.  I've tidied up the code, there
      was no need for -fno-code to be a "mode" flag, as far as I can tell.
      -fno-code does not emit interface files, nor does it do recompilation
      checking, as suggested in #3783.  This would make Haddock emit
      interface files, for example, and I'm fairly sure we don't want to do
      that.  Compiling with -fno-code is pretty quick anyway, perhaps we can
      get away without recompilation checking.
  14. 26 Apr, 2010 2 commits
  15. 24 Apr, 2010 3 commits