1. 26 Aug, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix flaggery for RULES (cf Trac #2497) · 24b1e136
      simonpj@microsoft.com authored
      This patch executes the plan described in the discussion in Trac #2497.
      Specficially:
      
          * Inside a RULE, switch on the forall-as-keyword in the lexer,
            unconditionally. (Actually this is done by an earlier patch.)
      
          * Merge the -XScopedTypeVariables and -XPatternSignatures flags,
            and deprecate the latter. Distinguishing them isn't senseless,
            but it's jolly confusing.
      
          * Inside a RULE, switch on -XScopedTypeVariables unconditionally. 
      
          * Change -frewrite-rules to -fenable-rewrite-rules; deprecate the former. 
            Internally the DynFlag is now Opt_EnableRewriteRules.
      
      There's a test in typecheck/should_compile/T2497.hs
      24b1e136
  2. 20 Aug, 2008 1 commit
  3. 22 Aug, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Fix a nasty float-in bug · 081d294c
      simonpj@microsoft.com authored
      This is a long-standing bug in FloatIn, which I somehow managed to
      tickle (it's actually surprisingly hard to provoke which is why 
      it has not shown up before).
      
      The problem was that we had a specialisation like this:
      
        let
      	f_spec = ...
        in let
      	{-# RULE f Int = f_spec #-}
      	f = ...
        in
      	<body>
      
      The 'f_spec' binding was being floated inside the binding for 'f', 
      which makes the RULE invalid becuase 'f_spec' isn't in scope.
      
      We just need to add the free variables of the RULE in the right 
      places...
      	
      081d294c
  4. 21 Aug, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Make rule printing wobble less · 10f18550
      simonpj@microsoft.com authored
      a) When generating specialisations, include the types in the name
         of the rule, to avoid having rules with duplicate names.
         (The rule name is used to put rules in canonical order for
         fingerprinting.)
      
      b) In Specialise and SpecConstr use a new function Rules.pprRulesForUser
         to print rules in canonical order.  This reduces unnecessary wobbling
         in test output, notably in T2486
      10f18550
  5. 25 Aug, 2008 10 commits
  6. 24 Aug, 2008 5 commits
  7. 23 Aug, 2008 1 commit
  8. 21 Aug, 2008 9 commits
  9. 20 Aug, 2008 1 commit
  10. 18 Aug, 2008 1 commit
  11. 17 Aug, 2008 8 commits
  12. 21 Aug, 2008 1 commit
    • Simon Marlow's avatar
      Don't use the cc-options from packages when compiling .hc files · 39271273
      Simon Marlow authored
      Now that we don't include any header files in .hc apart from our own,
      the cc-options from packages are at best superfluous, so don't pass
      them.
      
      We still pass them to .c compilations, although I've just made changes
      to Cabal so that cc-options from a .cabal file are not copied into the
      InstalledPackageInfo.  Most uses of cc-options in Cabal are clearly
      intended to be local to the package, but they were being propagated
      everywhere, almost certainly unintentionally.
      
      The way is left open for Cabal to allow packages to specify cc-options
      that get propagated in the future, if we find a use case for this.
      39271273