1. 19 Feb, 2021 1 commit
    • Simon Peyton Jones's avatar
      Improve handling of overloaded labels, literals, lists etc · 4196969c
      Simon Peyton Jones authored
      When implementing Quick Look I'd failed to remember that overloaded
      labels, like #foo, should be treated as a "head", so that they can be
      instantiated with Visible Type Application. This caused #19154.
      
      A very similar ticket covers overloaded literals: #19167.
      
      This patch fixes both problems, but (annoyingly, albeit temporarily)
      in two different ways.
      
      Overloaded labels
      
      I dealt with overloaded labels by buying fully into the
      Rebindable Syntax approach described in GHC.Hs.Expr
      Note [Rebindable syntax and HsExpansion].
      
      There is a good overview in GHC.Rename.Expr
      Note [Handling overloaded and rebindable constructs].
      That module contains much of the payload for this patch.
      
      Specifically:
      
      * Overloaded labels are expanded in the renamer, fixing #19154.
        See Note [Overloaded labels] in GHC.Rename.Expr.
      
      * Left and right sections used to have special code paths in the
        typechecker and desugarer.  Now we just expand them in the
        renamer. This is harder than it sounds.  See GHC.Rename.Expr
        Note [Left and right sections].
      
      * Infix operator applications are expanded in the typechecker,
        specifically in GHC.Tc.Gen.App.splitHsApps.  See
        Note [Desugar OpApp in the typechecker] in that module
      
      * ExplicitLists are expanded in the renamer, when (and only when)
        OverloadedLists is on.
      
      * HsIf is expanded in the renamer when (and only when) RebindableSyntax
        is on.  Reason: the coverage checker treats HsIf specially.  Maybe
        we could instead expand it unconditionally, and fix up the coverage
        checker, but I did not attempt that.
      
      Overloaded literals
      
      Overloaded literals, like numbers (3, 4.2) and strings with
      OverloadedStrings, were not working correctly with explicit type
      applications (see #19167).  Ideally I'd also expand them in the
      renamer, like the stuff above, but I drew back on that because they
      can occur in HsPat as well, and I did not want to to do the HsExpanded
      thing for patterns.
      
      But they *can* now be the "head" of an application in the typechecker,
      and hence something like ("foo" @T) works now.  See
      GHC.Tc.Gen.Head.tcInferOverLit.  It's also done a bit more elegantly,
      rather than by constructing a new HsExpr and re-invoking the
      typechecker. There is some refactoring around tcShortCutLit.
      
      Ultimately there is more to do here, following the Rebindable Syntax
      story.
      
      There are a lot of knock-on effects:
      
      * HsOverLabel and ExplicitList no longer need funny (Maybe SyntaxExpr)
        fields to support rebindable syntax -- good!
      
      * HsOverLabel, OpApp, SectionL, SectionR all become impossible in the
        output of the typecheker, GhcTc; so we set their extension fields to
        Void. See GHC.Hs.Expr Note [Constructor cannot occur]
      
      * Template Haskell quotes for HsExpanded is a bit tricky.  See
        Note [Quotation and rebindable syntax] in GHC.HsToCore.Quote.
      
      * In GHC.HsToCore.Match.viewLExprEq, which groups equal HsExprs for the
        purpose of pattern-match overlap checking, I found that dictionary
        evidence for the same type could have two different names.  Easily
        fixed by comparing types not names.
      
      * I did quite a bit of annoying fiddling around in GHC.Tc.Gen.Head and
        GHC.Tc.Gen.App to get error message locations and contexts right,
        esp in splitHsApps, and the HsExprArg type.  Tiresome and not very
        illuminating.  But at least the tricky, higher order, Rebuilder
        function is gone.
      
      * Some refactoring in GHC.Tc.Utils.Monad around contexts and locations
        for rebindable syntax.
      
      * Incidentally fixes #19346, because we now print renamed, rather than
        typechecked, syntax in error mesages about applications.
      
      The commit removes the vestigial module GHC.Builtin.RebindableNames,
      and thus triggers a 2.4% metric decrease for test MultiLayerModules
      (#19293).
      
      Metric Decrease:
          MultiLayerModules
          T12545
      4196969c
  2. 18 Feb, 2021 12 commits
  3. 17 Feb, 2021 20 commits
  4. 16 Feb, 2021 7 commits
    • Ryan Scott's avatar
      Parse symbolic names in ANN type correctly with otycon · a04179e7
      Ryan Scott authored
      This adds a new `otycon` production to the parser that allows for type
      constructor names that are either alphanumeric (`tycon`) or symbolic
      (`tyconsym`), where the latter must be parenthesized appropriately.
      `otycon` is much like the existing `oqtycon` production, except that it does
      not permit qualified names. The parser now uses `otycon` to parse type
      constructor names in `ANN type` declarations, which fixes #19374.
      
      To make sure that all of this works, I added three test cases:
      
      * `should_compile/T19374a`: the original test case from #19374
      * `should_fail/T19374b`: a test that makes sure that an `ANN` with a qualified
        name fails to parse
      * `should_fail/T19374c`: a test that makes sure that an `ANN type` with a
        qualified name fails to parse
      a04179e7
    • Adam Gundry's avatar
      Avoid false redundant import warning with DisambiguateRecordFields · 7686f9f8
      Adam Gundry authored
      Fixes #17853. We mustn't discard the result of pickGREs, because doing
      so might lead to incorrect redundant import warnings.
      7686f9f8
    • Andrzej Rybczak's avatar
      Add Generic tuple instances up to 15 · c2029001
      Andrzej Rybczak authored
      c2029001
    • Simon Peyton Jones's avatar
      Avoid useless w/w split · c6faa42b
      Simon Peyton Jones authored
      This patch is just a tidy-up for the post-strictness-analysis
      worker wrapper split.  Consider
      
         f x = x
      
      Strictnesss analysis does not lead to a w/w split, so the
      obvious thing is to leave it 100% alone.  But actually, because
      the RHS is small, we ended up adding a StableUnfolding for it.
      
      There is some reason to do this if we choose /not/ do to w/w
      on the grounds that the function is small.  See
      Note [Don't w/w inline small non-loop-breaker things]
      
      But there is no reason if we would not have done w/w anyway.
      
      This patch just moves the conditional to later.  Easy.
      This does move some -ddump-simpl printouts around a bit.
      
      I also discovered that the previous code was overwritten an
      InlineCompulsory with InlineStable, which is utterly wrong.  That in
      turn meant that some default methods (marked InlineCompulsory)
      were getting their InlineCompulsory squashed. This patch fixes
      that bug --- but of course that does mean a bit more inlining!
      
      Metric Decrease:
          T9233
          T9675
      Metric Increase:
          T12707
          T11374
          T3064
          T4029
          T9872b
          T9872d
          haddock.Cabal
      c6faa42b
    • Oleg Grenrus's avatar
      Use explicit import list for Data.List · 963e1e9a
      Oleg Grenrus authored
      963e1e9a
    • Sylvain Henry's avatar
      42ab06f7
    • Sylvain Henry's avatar
      Don't build extra object with -no-hs-main · a01e78cc
      Sylvain Henry authored
      We don't need to compile/link an additional empty C file when it is not
      needed.
      
      This patch may also fix #18938 by avoiding trying to lookup the RTS unit
      when there is none (yet) in the unit database.
      a01e78cc