1. 25 Jun, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      
      > data VisibilityFlag = Visible | Specified | Invisible
      
      to
      
      > data ArgFlag = Required | Specified | Inferred
      
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
      5fdb854c
  2. 24 Jun, 2016 15 commits
  3. 23 Jun, 2016 11 commits
    • eir@cis.upenn.edu's avatar
      Release notes for #11975 and #10963 · 4ae950fb
      eir@cis.upenn.edu authored
      4ae950fb
    • eir@cis.upenn.edu's avatar
      Fix #10963 and #11975 by adding new cmds to GHCi. · 8035d1a5
      eir@cis.upenn.edu authored
      See the user's guide entry or the Note [TcRnExprMode] in TcRnDriver.
      
      Test cases: ghci/scripts/T{10963,11975}
      8035d1a5
    • eir@cis.upenn.edu's avatar
      Fix #11974 by adding a more smarts to TcDefaults. · 9a34bf19
      eir@cis.upenn.edu authored
      Test cases:
        typecheck/should_compile/T11974
        typecheck/should_fail/T11974b
      9a34bf19
    • eir@cis.upenn.edu's avatar
      Very confusing typo in error message. · 7f5d5603
      eir@cis.upenn.edu authored
      7f5d5603
    • niteria's avatar
      Remove Ord TyCon · bb740218
      niteria authored
      After 35d1564c: Provide Uniquable version of SCC we
      can remove this. We want to remove it because when used
      it can introduce unnecessary nondeterminism.
      
      GHC Trac: #4012
      bb740218
    • niteria's avatar
      Provide Uniquable version of SCC · 35d1564c
      niteria authored
      We want to remove the `Ord Unique` instance because there's
      no way to implement it in deterministic way and it's too
      easy to use by accident.
      
      We sometimes compute SCC for datatypes whose Ord instance
      is implemented in terms of Unique. The Ord constraint on
      SCC is just an artifact of some internal data structures.
      We can have an alternative implementation with a data
      structure that uses Uniquable instead.
      
      This does exactly that and I'm pleased that I didn't have
      to introduce any duplication to do that.
      
      Test Plan:
      ./validate
      I looked at performance tests and it's a tiny bit better.
      
      Reviewers: bgamari, simonmar, ezyang, austin, goldfire
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2359
      
      GHC Trac Issues: #4012
      35d1564c
    • Facundo Domínguez's avatar
      Have Core linter accept programs using StaticPointers and -fhpc. · 7fc20b02
      Facundo Domínguez authored
      Summary:
      This patch uses collectArgsTicks instead of collectArgs to test that
      StaticPtr only occurs at the top of RHSs of top-level expressions.
      
      Ticks introduced by -fhpc would interfere otherwise.
      
      Test Plan: ./validate
      
      Reviewers: thomie, austin, goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2355
      
      GHC Trac Issues: #12207
      7fc20b02
    • Simon Peyton Jones's avatar
      Narrow the use of record wildcards slightly · 2f8cd14f
      Simon Peyton Jones authored
      In reviewing the fix to Trac #12130 I found the wild-card
      fill-in code for ".." notation in record constructions hard
      to understand.  It went to great contortions (including the
      find_tycon code) to allow
          data T = C { x, y :: Int }
          f x = C { .. }
      to expand to
          f x = C { x = x, y = y }
      where 'y' is an /imported function/!  That seems way over the top
      for what record wildcards are supposed to do.
      
      So I have narrowed the record-wildcard expansion to include only
      /locally-bound/ variables; i.e. not top level, and certainly not
      imported.
      
      I don't think anyone is using record wildcards in this bizarre way, so
      I don't expect any fallout. Even if there is, you can easily
      initialise fields with eponymous but imported values by hand.
      
      An intermediate position would be to allow /local/ top-level
      definitions.  But I doubt anyone is doing that either.
      
      Let's see if there's any fallout.  It's a local change, easy to
      revert, so I've just gone ahead to save everyone's time.
      2f8cd14f
    • Simon Peyton Jones's avatar
      Narrow the warning for simplifiable constraints · 643706e4
      Simon Peyton Jones authored
      In Trac #11948 I added the warning
          -Wsimplifiable-class-constraints
      which warns if the class constraints in a type signature are
      simplifiable.
      
      But in fact the fragility it warns about only happens with
      NoMonoLocalBinds, so this patch switches off the warning if
      you have MonoLocalBinds (and suggests using it in the error
      message).
      
      See Note [Simplifiable given constraints] in TcValidity.
      643706e4
    • Simon Peyton Jones's avatar
      Remove unused import · e556f768
      Simon Peyton Jones authored
      e556f768
    • Simon Peyton Jones's avatar
      Give lookupGRE_Name a better API · 3e0af469
      Simon Peyton Jones authored
      lookupGRE_Name should return either zero or one GREs, never
      several. This is a consequence of INVARIANT 1 on GlobalRdrEnv.
      
      So it's better if it returns a Maybe; the panic on multiple results
      is put in one place, instead of being scattered or ignored.
      
      Just refactoring, no change in behaviour
      3e0af469
  4. 22 Jun, 2016 13 commits
    • Simon Peyton Jones's avatar
      Test Trac #12163 · 210a2e12
      Simon Peyton Jones authored
      210a2e12
    • Simon Peyton Jones's avatar
      Expand given superclasses more eagerly · ce97b729
      Simon Peyton Jones authored
      This patch fixes Trac #12175, another delicate corner case of
      Note [Instance and Given overlap] in TcInteract.
      
      In #12175 we were not expanding given superclasses eagerly
      enough. It was easy to fix, and is actually rather neater than
      before.
      
      See Note [Eagerly expand given superclasses] in TcCanonical.
      The main change is to move the eager expansion of given superclasses
      to canClassNC.
      ce97b729
    • Simon Peyton Jones's avatar
      Remove unused arg to tcSuperClasses · a1b33596
      Simon Peyton Jones authored
      We don't need the FamInstEnvs argument any more.
      Just a tiny refactor.
      a1b33596
    • Simon Peyton Jones's avatar
      Improve error message in deriving( Functor ) · cc92a446
      Simon Peyton Jones authored
      Fixes Trac #12163.  Pretty simple.
      cc92a446
    • Simon Peyton Jones's avatar
      Comments only · 7e7aeab2
      Simon Peyton Jones authored
      7e7aeab2
    • Simon Marlow's avatar
      Accept new (lower) allocations for T7257 · 15641b07
      Simon Marlow authored
      15641b07
    • niteria's avatar
      Make the Ord Module independent of Unique order (2nd try) · 348f2dbb
      niteria authored
      The `Ord Module` instance currently uses `Unique`s for comparison.
      We don't want to use the `Unique` order because it can introduce
      nondeterminism.
      This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic
      ordering making `Ord Module` deterministic transitively.
      
      I've run `nofib` and it doesn't make a measurable difference.
      
      See also Note [ModuleEnv determinism and performance].
      
      This fixes #12191 - the regression, that the previous version of this
      patch had.
      
      Test Plan:
      ./validate
      run nofib: P112
      
      Reviewers: simonmar, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2354
      
      GHC Trac Issues: #4012, #12191
      348f2dbb
    • niteria's avatar
      Don't error on GCC inlining warning in rts · 93f40cb9
      niteria authored
      The warning for reference:
      ```
      rts/RaiseAsync.c: In function ‘throwToMsg’:
      
      rts/SMPClosureOps.h:65:0: error:
           error: inlining failed in call to ‘lockClosure’: call is unlikely
      and code size would grow
      
      rts/RaiseAsync.c:305:0: error:  error: called from here
      
      rts/SMPClosureOps.h:65:0: error:
           error: inlining failed in call to ‘lockClosure’: call is unlikely
      and code size would grow
      ```
      
      This warning triggers on `gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)`
      and it doesn't trigger with new GCCs.
      
      Test Plan: build ghc/rts
      
      Reviewers: bgamari, simonmar, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2353
      93f40cb9
    • Gabor Greif's avatar
      More typos in comments [skip ci] · 61995883
      Gabor Greif authored
      61995883
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 4e7d8350
      Gabor Greif authored
      4e7d8350
    • Simon Marlow's avatar
      9d62d09a
    • Simon Marlow's avatar
      Fix build breakage due to rebase · c0583a9e
      Simon Marlow authored
      c0583a9e
    • Simon Marlow's avatar
      Second attempt to fix sizeExpr · a47b62cb
      Simon Marlow authored
      Summary:
      Background:
      * sizeExpr was calculating expressions like ((e `cast` T) x) wrongly
      * Fixing it caused regressions in compile performance, and one nofib
        program (k-nucleotide)
      
      I managed to fix the source of the compiler regressions.  I think it was
      due to traceTc not being inlined, which I fixed in a more robust way by
      putting an export list on TcRnMonad.
      
      The k-nucleotide regression is more difficult.  I don't think anything
      is actually going wrong, but this program has been highly tuned and is
      quite sensitive to changing in inlining behaviour.  I managed to recover
      most of the performance by manual lambda-lifting which makes it a bit
      less fragile, but the end result was a bit slower.  I don't think this
      is disastrous, the program is pretty horrible to begin with and we could
      probably make a faster one by starting from scratch.
      
      Test Plan: validate, nofib
      
      Reviewers: simonpj, bgamari, niteria, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2338
      
      GHC Trac Issues: #11564
      a47b62cb