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 1 commit
  6. 24 Aug, 2008 1 commit
  7. 23 Aug, 2008 1 commit
  8. 21 Aug, 2008 1 commit
  9. 18 Aug, 2008 1 commit
  10. 17 Aug, 2008 2 commits
  11. 21 Aug, 2008 3 commits
  12. 20 Aug, 2008 2 commits
  13. 18 Aug, 2008 1 commit
  14. 16 Aug, 2008 1 commit
  15. 13 Aug, 2008 1 commit
  16. 12 Aug, 2008 1 commit
    • Simon Marlow's avatar
      put back -fwarn-depcrecations · 27abb1f5
      Simon Marlow authored
      It was replaced by -fwarn-warnings-deprecations, but I think we want
      to keep it for backwards compatibility.  I'm not sure we want to
      deprecate it either...
      27abb1f5
  17. 13 Aug, 2008 1 commit
  18. 11 Aug, 2008 1 commit
  19. 05 Aug, 2008 2 commits
    • Simon Marlow's avatar
      Don't warn if 'import Prelude' doesn't import anything · 3245f93f
      Simon Marlow authored
      ... even if Prelude doesn't come from the base package (it might come from
      a old backwards-compatible version of base, for example).
      3245f93f
    • Simon Marlow's avatar
      Add -XPackageImports, new syntax for package-qualified imports · 1867a7bb
      Simon Marlow authored
      Now you can say
        
        import "network" Network.Socket
      
      and get Network.Socket from package "network", even if there are
      multiple Network.Socket modules in scope from different packages
      and/or the current package.
      
      This is not really intended for general use, it's mainly so that we
      can build backwards-compatible versions of packages, where we need to
      be able to do
      
      module GHC.Base (module New.GHC.Base) where
      import "base" GHC.Base as New.GHC.Base
      1867a7bb
  20. 12 Aug, 2008 5 commits
  21. 11 Aug, 2008 11 commits