Skip to content
Snippets Groups Projects
  1. Mar 09, 2024
    • Patrick's avatar
      HieAst: add module name #24493 · cfb197e3
      Patrick authored and Marge Bot's avatar Marge Bot committed
      The main purpose of this is to tuck the module name `xxx` in `module xxx where` into the hieAst.
      It should fix #24493.
      
      The following have been done:
      1. Renamed and update the `tcg_doc_hdr :: Maybe (LHsDoc GhcRn)` to `tcg_hdr_info :: (Maybe (LHsDoc GhcRn), Maybe (XRec GhcRn ModuleName))`
         To store the located module name information.
      2. update the `RenamedSource` and `RenamedStuff` with extra `Maybe (XRec GhcRn ModuleName)` located module name information.
      3. add test `testsuite/tests/hiefile/should_compile/T24493.hs` to ensure the module name is added and update several relevent tests.
      4. accompanied submodule haddoc test update MR in haddock!53
      cfb197e3
    • Jade's avatar
      Error messages: Improve Error messages for Data constructors in type signatures. · edb9bf77
      Jade authored and Marge Bot's avatar Marge Bot committed
      This patch improves the error messages from invalid type signatures by
      trying to guess what the user did and suggesting an appropriate fix.
      
      Partially fixes: #17879
      edb9bf77
  2. Mar 08, 2024
  3. Mar 07, 2024
    • Vladislav Zavialov's avatar
      Rephrase error message to say "visible arguments" (#24318) · 9cd9efb4
      Vladislav Zavialov authored
      * Main change: make the error message generated by mkFunTysMsg more
        accurate by changing "value arguments" to "visible arguments".
      
      * Refactor: define a new type synonym VisArity and use it instead of
        Arity in a few places.
      
      It might be the case that there other places in the compiler that should
      talk about visible arguments rather than value arguments, but I haven't
      tried to find them all, focusing only on the error message reported in
      the ticket.
      9cd9efb4
  4. Mar 06, 2024
  5. Mar 05, 2024
  6. Mar 04, 2024
  7. Mar 02, 2024
  8. Mar 01, 2024
    • Arnaud Spiwack's avatar
      Adjust documentation of linear lets according to committee decision · 6612388e
      Arnaud Spiwack authored and Marge Bot's avatar Marge Bot committed
      6612388e
    • Arnaud Spiwack's avatar
      Improve error messages coming from non-linear patterns · dec6d8d3
      Arnaud Spiwack authored and Marge Bot's avatar Marge Bot committed
      This enriched the `CtOrigin` for non-linear patterns to include data
      of the pattern that created the constraint (which can be quite useful
      if it occurs nested in a pattern) as well as an explanation why the
      pattern is non-restricted in (at least in some cases).
      dec6d8d3
    • Sylvain Henry's avatar
      JS linker: filter unboxed tuples · bbdb6286
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      bbdb6286
    • Torsten Schmits's avatar
      Introduce ListTuplePuns extension · d91d00fc
      Torsten Schmits authored and Marge Bot's avatar Marge Bot committed
      This implements Proposal 0475, introducing the `ListTuplePuns` extension
      which is enabled by default.
      
      Disabling this extension makes it invalid to refer to list, tuple and
      sum type constructors by using built-in syntax like `[Int]`,
      `(Int, Int)`, `(# Int#, Int# #)` or `(# Int | Int #)`.
      Instead, this syntax exclusively denotes data constructors for use with
      `DataKinds`.
      The conventional way of referring to these data constructors by
      prefixing them with a single quote (`'(Int, Int)`) is now a parser
      error.
      
      Tuple declarations have been moved to `GHC.Tuple.Prim` and the `Solo`
      data constructor has been renamed to `MkSolo` (in a previous commit).
      Unboxed tuples and sums now have real source declarations in `GHC.Types`.
      Unit and solo types for tuples are now called `Unit`, `Unit#`, `Solo`
      and `Solo#`.
      Constraint tuples now have the unambiguous type constructors `CTuple<n>`
      as well as `CUnit` and `CSolo`, defined in `GHC.Classes` like before.
      
      A new parser construct has been added for the unboxed sum data
      constructor declarations.
      
      The type families `Tuple`, `Sum#` etc. that were intended to provide
      nicer syntax have been omitted from this change set due to inference
      problems, to be implemented at a later time.
      See the MR discussion for more info.
      
      Updates the submodule utils/haddock.
      Updates the cabal submodule due to new language extension.
      
          Metric Increase:
              haddock.base
      
          Metric Decrease:
              MultiLayerModulesTH_OneShot
              size_hello_artifact
      
      Proposal document: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst
      
      Merge request: ghc/ghc!8820
      
      Tracking ticket: ghc/ghc#21294
      d91d00fc
    • Matthew Pickering's avatar
Loading