Skip to content
Snippets Groups Projects
  1. Mar 08, 2024
  2. Mar 06, 2024
  3. Mar 04, 2024
    • Finley McIlwaine's avatar
      add -fprof-late-overloaded and -fprof-late-overloaded-calls · 61bb5ff6
      Finley McIlwaine authored
      * Refactor late cost centre insertion for extensibility
      * Add two more late cost centre insertion methods that add SCCs to overloaded
        top level bindings and call sites with dictionary arguments.
      * Some tests for the basic functionality of the new insertion methods
      
      Resolves: #24500
      61bb5ff6
  4. 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
    • 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
  5. Feb 26, 2024
  6. Feb 25, 2024
  7. Feb 21, 2024
    • Adam Gundry's avatar
      Define GHC2024 language edition (#24320) · 09941666
      Adam Gundry authored
      See https://github.com/ghc-proposals/ghc-proposals/pull/613
      
      . Also
      fixes #24343 and improves the documentation of language editions.
      
      Co-authored-by: Joachim Breitner's avatarJoachim Breitner <mail@joachim-breitner.de>
      09941666
    • Andrei Borzenkov's avatar
      Namespacing for fixity signatures (#14032) · 77629e76
      Andrei Borzenkov authored and Marge Bot's avatar Marge Bot committed
      Namespace specifiers were added to syntax of fixity signatures:
        - sigdecl ::= infix prec ops | ...
        + sigdecl ::= infix prec namespace_spec ops | ...
      
      To preserve namespace during renaming MiniFixityEnv type
      now has separate FastStringEnv fields for names that should be
      on the term level and for name that should be on the type level.
      
      makeMiniFixityEnv function was changed to fill MiniFixityEnv in the right way:
       - signatures without namespace specifiers fill both fields
       - signatures with 'data' specifier fill data field only
       - signatures with 'type' specifier fill type field only
      
      Was added helper function lookupMiniFixityEnv that takes care about
      looking for a name in an appropriate namespace.
      
      Updates haddock submodule.
      
      Metric Decrease:
          MultiLayerModulesTH_OneShot
      77629e76
  8. Feb 19, 2024
    • John Ericson's avatar
      Fix reST in users guide · 17e309d2
      John Ericson authored and Marge Bot's avatar Marge Bot committed
      It appears that aef587f6 wasn't valid syntax.
      17e309d2
    • Andrei Borzenkov's avatar
      Parser, renamer, type checker for @a-binders (#17594) · 0dbd729e
      Andrei Borzenkov authored and Marge Bot's avatar Marge Bot committed
      GHC Proposal 448 introduces binders for invisible type arguments
      (@a-binders) in various contexts. This patch implements @-binders
      in lambda patterns and function equations:
      
        {-# LANGUAGE TypeAbstractions #-}
      
        id1 :: a -> a
        id1 @t x = x :: t      -- @t-binder on the LHS of a function equation
      
        higherRank :: (forall a. (Num a, Bounded a) => a -> a) -> (Int8, Int16)
        higherRank f = (f 42, f 42)
      
        ex :: (Int8, Int16)
        ex = higherRank (\ @a x -> maxBound @a - x )
                               -- @a-binder in a lambda pattern in an argument
                               -- to a higher-order function
      
      Syntax
      ------
      
      To represent those @-binders in the AST, the list of patterns in Match
      now uses ArgPat instead of Pat:
      
        data Match p body
           = Match {
               ...
      -        m_pats  :: [LPat p],
      +        m_pats  :: [LArgPat p],
               ...
         }
      
      + data ArgPat pass
      +   = VisPat (XVisPat pass) (LPat pass)
      +   | InvisPat (XInvisPat pass) (HsTyPat (NoGhcTc pass))
      +   | XArgPat !(XXArgPat pass)
      
      The VisPat constructor represents patterns for visible arguments,
      which include ordinary value-level arguments and required type arguments
      (neither is prefixed with a @), while InvisPat represents invisible type
      arguments (prefixed with a @).
      
      Parser
      ------
      
      In the grammar (Parser.y), the lambda and lambda-cases productions of
      aexp non-terminal were updated to accept argpats instead of apats:
      
        aexp : ...
      -        | '\\' apats '->' exp
      +        | '\\' argpats '->' exp
               ...
      -        | '\\' 'lcases' altslist(apats)
      +        | '\\' 'lcases' altslist(argpats)
               ...
      
      + argpat : apat
      +        | PREFIX_AT atype
      
      Function left-hand sides did not require any changes to the grammar, as
      they were already parsed with productions capable of parsing @-binders.
      Those binders were being rejected in post-processing (isFunLhs), and now
      we accept them.
      
      In Parser.PostProcess, patterns are constructed with the help of
      PatBuilder, which is used as an intermediate data structure when
      disambiguating between FunBind and PatBind. In this patch we define
      ArgPatBuilder to accompany PatBuilder. ArgPatBuilder is a short-lived
      data structure produced in isFunLhs and consumed in checkFunBind.
      
      Renamer
      -------
      
      Renaming of @-binders builds upon prior work on type patterns,
      implemented in 2afbddb0, which guarantees proper scoping and
      shadowing behavior of bound type variables.
      
      This patch merely defines rnLArgPatsAndThen to process a mix of visible
      and invisible patterns:
      
      + rnLArgPatsAndThen :: NameMaker -> [LArgPat GhcPs] -> CpsRn [LArgPat GhcRn]
      + rnLArgPatsAndThen mk = mapM (wrapSrcSpanCps rnArgPatAndThen) where
      +   rnArgPatAndThen (VisPat x p)    = ... rnLPatAndThen ...
      +   rnArgPatAndThen (InvisPat _ tp) = ... rnHsTyPat ...
      
      Common logic between rnArgPats and rnPats is factored out into the
      rn_pats_general helper.
      
      Type checker
      ------------
      
      Type-checking of @-binders builds upon prior work on lazy skolemisation,
      implemented in f5d3e03c.
      
      This patch extends tcMatchPats to handle @-binders. Now it takes and
      returns a list of LArgPat rather than LPat:
      
        tcMatchPats ::
                    ...
      -             -> [LPat GhcRn]
      +             -> [LArgPat GhcRn]
                    ...
      -             -> TcM ([LPat GhcTc], a)
      +             -> TcM ([LArgPat GhcTc], a)
      
      Invisible binders in the Match are matched up with invisible (Specified)
      foralls in the type. This is done with a new clause in the `loop` worker
      of tcMatchPats:
      
        loop :: [LArgPat GhcRn] -> [ExpPatType] -> TcM ([LArgPat GhcTc], a)
        loop (L l apat : pats) (ExpForAllPatTy (Bndr tv vis) : pat_tys)
          ...
          -- NEW CLAUSE:
          | InvisPat _ tp <- apat, isSpecifiedForAllTyFlag vis
          = ...
      
      In addition to that, tcMatchPats no longer discards type patterns. This
      is done by filterOutErasedPats in the desugarer instead.
      
      x86_64-linux-deb10-validate+debug_info
      Metric Increase:
          MultiLayerModulesTH_OneShot
      0dbd729e
  9. Feb 13, 2024
  10. Feb 12, 2024
    • Teo Camarasu's avatar
      doc: Add requires prof annotation to options that require it · d0d5acb5
      Teo Camarasu authored and Marge Bot's avatar Marge Bot committed
      Resolves #24421
      d0d5acb5
    • Teo Camarasu's avatar
      nonmoving: Add support for heap profiling · bedb4f0d
      Teo Camarasu authored and Marge Bot's avatar Marge Bot committed
      Add support for heap profiling while using the nonmoving collector.
      
      We greatly simply the implementation by disabling concurrent collection for
      GCs when heap profiling is enabled. This entails that the marked objects on
      the nonmoving heap are exactly the live objects.
      
      Note that we match the behaviour for live bytes accounting by taking the size
      of objects on the nonmoving heap to be that of the segment's block
      rather than the object itself.
      
      Resolves #22221
      bedb4f0d
    • Sylvain Henry's avatar
      JS: add support for linking C sources · aef587f6
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      Support linking C sources with JS output of the JavaScript backend.
      See the added documentation in the users guide.
      
      The implementation simply extends the JS linker to use the objects (.o)
      that were already produced by the emcc compiler and which were filtered
      out previously. I've also added some options to control the link with C
      functions (see the documentation about pragmas).
      
      With this change I've successfully compiled the direct-sqlite package
      which embeds the sqlite.c database code. Some wrappers are still
      required (see the documentation about wrappers) but everything generic
      enough to be reused for other libraries have been integrated into
      rts/js/mem.js.
      aef587f6
  11. Feb 10, 2024
    • Matthew Pickering's avatar
      rts: eras profiling mode · b0293f78
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      The eras profiling mode is useful for tracking the life-time of
      closures. When a closure is written, the current era is recorded in the
      profiling header. This records the era in which the closure was created.
      
      * Enable with -he
      * User mode: Use functions ghc-experimental module GHC.Profiling.Eras to modify the era
      * Automatically: --automatic-era-increment, increases the user era on major
        collections
      * The first era is era 1
      * -he<era> can be used with other profiling modes to select a specific
        era
      
      If you just want to record the era but not to perform heap profiling you
      can use `-he --no-automatic-heap-samples`.
      
      https://well-typed.com/blog/2024/01/ghc-eras-profiling/
      
      Fixes #24332
      b0293f78
  12. Feb 08, 2024
    • Matthew Pickering's avatar
      Use specific clang assembler when compiling with -fllvm · ab533e71
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      There are situations where LLVM will produce assembly which older gcc
      toolchains can't handle. For example on Deb10, it seems that LLVM >= 13
      produces assembly which the default gcc doesn't support.
      
      A more robust solution in the long term is to require a specific LLVM
      compatible assembler when using -fllvm.
      
      Fixes #16354
      ab533e71
  13. Feb 05, 2024
  14. Feb 01, 2024
    • Andrei Borzenkov's avatar
      Namespacing for WARNING/DEPRECATED pragmas (#24396) · 151dda4e
      Andrei Borzenkov authored and Marge Bot's avatar Marge Bot committed
      New syntax for WARNING and DEPRECATED pragmas was added,
      namely namespace specifierss:
      
        namespace_spec ::= 'type' | 'data' | {- empty -}
      
        warning ::= warning_category namespace_spec namelist strings
      
        deprecation ::= namespace_spec namelist strings
      
      A new data type was introduced to represent these namespace specifiers:
      
        data NamespaceSpecifier =
          NoSpecifier |
          TypeNamespaceSpecifier (EpToken "type") |
          DataNamespaceSpecifier (EpToken "data")
      
      Extension field XWarning now contains this NamespaceSpecifier.
      
      lookupBindGroupOcc function was changed: it now takes NamespaceSpecifier
      and checks that the namespace of the found names matches the passed flag.
      With this change {-# WARNING data D "..." #-} pragma will only affect value
      namespace and {-# WARNING type D "..." #-} will only affect type
      namespace. The same logic is applicable to DEPRECATED pragmas.
      
      Finding duplicated warnings inside rnSrcWarnDecls now takes into
      consideration NamespaceSpecifier flag to allow warnings with the
      same names that refer to different namespaces.
      151dda4e
    • Teo Camarasu's avatar
      doc: Add -Dn flag to user guide · 94ce031d
      Teo Camarasu authored and Marge Bot's avatar Marge Bot committed
      Resolves #24394
      94ce031d
  15. Jan 24, 2024
  16. Jan 20, 2024
  17. Jan 16, 2024
  18. Jan 15, 2024
    • Krzysztof Gogolewski's avatar
      Make the build more strict on documentation errors · da908790
      Krzysztof Gogolewski authored and Marge Bot's avatar Marge Bot committed
      * Detect undefined labels. This can be tested by adding :ref:`nonexistent`
        to a documentation rst file; attempting to build docs will fail.
        Fixed the undefined label in `9.8.1-notes.rst`.
      * Detect errors. While we have plenty of warnings, we can at least enforce
        that Sphinx does not report errors.
        Fixed the error in `required_type_arguments.rst`.
      
      Unrelated change: I have documented that the `-dlint` enables
      `-fcatch-nonexhaustive-cases`, as can be verified by checking
      `enableDLint`.
      da908790
  19. Jan 13, 2024
  20. Jan 10, 2024
  21. Jan 08, 2024
  22. Jan 07, 2024
  23. Jan 01, 2024
  24. Dec 25, 2023
  25. Dec 24, 2023
  26. Dec 20, 2023
  27. Dec 15, 2023
  28. Dec 13, 2023
  29. Dec 11, 2023
    • Arnaud Spiwack's avatar
      Linear let and where bindings · 8e0446df
      Arnaud Spiwack authored
      For expediency, the initial implementation of linear types in GHC
      made it so that let and where binders would always be considered
      unrestricted. This was rather unpleasant, and probably a big obstacle
      to adoption. At any rate, this was not how the proposal was designed.
      
      This patch fixes this infelicity. It was surprisingly difficult to
      build, which explains, in part, why it took so long to materialise.
      
      As of this patch, let or where bindings marked with %1 will be
      linear (respectively %p for an arbitrary multiplicity p). Unmarked let
      will infer their multiplicity.
      
      Here is a prototypical example of program that used to be rejected and
      is accepted with this patch:
      
      ```haskell
      f :: A %1 -> B
      g :: B %1 -> C
      
      h :: A %1 -> C
      h x = g y
        where
          y = f x
      ```
      
      Exceptions:
      - Recursive let are unrestricted, as there isn't a clear semantics of
        what a linear recursive binding would be.
      - Destructive lets with lazy bindings are unrestricted, as their
        desugaring isn't linear (see also #23461).
      - (Strict) destructive lets with inferred polymorphic type are
        unrestricted. Because the desugaring isn't linear (See #18461
        down-thread).
      
      Closes #18461 and #18739
      
      Co-authored-by: @jackohughes
      8e0446df
Loading