[Git][ghc/ghc][wip/sand-witch/check- at -binders] 24 commits: llvmGen: Adapt to allow use of new pass manager.

Vladislav Zavialov (@int-index) gitlab at gitlab.haskell.org
Mon Feb 12 14:01:55 UTC 2024



Vladislav Zavialov pushed to branch wip/sand-witch/check- at -binders at Glasgow Haskell Compiler / GHC


Commits:
77db84ab by Ben Gamari at 2024-02-08T00:35:22-05:00
llvmGen: Adapt to allow use of new pass manager.

We now must use `-passes` in place of `-O<n>` due to #21936.

Closes #21936.

- - - - -
3c9ddf97 by Matthew Pickering at 2024-02-08T00:35:59-05:00
testsuite: Mark length001 as fragile on javascript

Modifying the timeout multiplier is not a robust way to get this test to
reliably fail. Therefore we mark it as fragile until/if javascript ever
supports the stack limit.

- - - - -
20b702b5 by Matthew Pickering at 2024-02-08T00:35:59-05:00
Javascript: Don't filter out rtsDeps list

This logic appears to be incorrect as it would drop any dependency which
was not in a direct dependency of the package being linked.

In the ghc-internals split this started to cause errors because
`ghc-internal` is not a direct dependency of most packages, and hence
important symbols to keep which are hard coded into the js runtime were
getting dropped.

- - - - -
2df96366 by Ben Gamari at 2024-02-08T00:35:59-05:00
base: Cleanup whitespace in cbits

- - - - -
44f6557a by Ben Gamari at 2024-02-08T00:35:59-05:00
Move `base` to `ghc-internal`

Here we move a good deal of the implementation of `base` into a new
package, `ghc-internal` such that it can be evolved independently
from the user-visible interfaces of `base`.

While we want to isolate implementation from interfaces, naturally, we
would like to avoid turning `base` into a mere set of module re-exports.
However, this is a non-trivial undertaking for a variety of reasons:

 * `base` contains numerous known-key and wired-in things, requiring
   corresponding changes in the compiler

 * `base` contains a significant amount of C code and corresponding
   autoconf logic, which is very fragile and difficult to break apart

 * `base` has numerous import cycles, which are currently dealt with via
   carefully balanced `hs-boot` files

 * We must not break existing users

To accomplish this migration, I tried the following approaches:

* [Split-GHC.Base]: Break apart the GHC.Base knot to allow incremental
  migration of modules into ghc-internal: this knot is simply too
  intertwined to be easily pulled apart, especially given the rather
  tricky import cycles that it contains)

* [Move-Core]: Moving the "core" connected component of base (roughly
  150 modules) into ghc-internal. While the Haskell side of this seems
  tractable, the C dependencies are very subtle to break apart.

* [Move-Incrementally]:

  1. Move all of base into ghc-internal
  2. Examine the module structure and begin moving obvious modules (e.g.
     leaves of the import graph) back into base
  3. Examine the modules remaining in ghc-internal, refactor as necessary
     to facilitate further moves
  4. Go to (2) iterate until the cost/benefit of further moves is
     insufficient to justify continuing
  5. Rename the modules moved into ghc-internal to ensure that they don't
     overlap with those in base
  6. For each module moved into ghc-internal, add a shim module to base
     with the declarations which should be exposed and any requisite
     Haddocks (thus guaranteeing that base will be insulated from changes
     in the export lists of modules in ghc-internal

Here I am using the [Move-Incrementally] approach, which is empirically
the least painful of the unpleasant options above

Bumps haddock submodule.

Metric Decrease:
    haddock.Cabal
    haddock.base
Metric Increase:
    MultiComponentModulesRecomp
    T16875
    size_hello_artifact

- - - - -
e8fb2451 by Vladislav Zavialov at 2024-02-08T00:36:36-05:00
Haddock comments on infix constructors (#24221)

Rewrite the `HasHaddock` instance for `ConDecl GhcPs` to account for
infix constructors.

This change fixes a Haddock regression (introduced in 19e80b9af252)
that affected leading comments on infix data constructor declarations:

	-- | Docs for infix constructor
	| Int :* Bool

The comment should be associated with the data constructor (:*), not
with its left-hand side Int.

- - - - -
9060d55b by Ben Gamari at 2024-02-08T00:37:13-05:00
Add os-string as a boot package

Introduces `os-string` submodule. This will be necessary for
`filepath-1.5`.

- - - - -
9d65235a by Ben Gamari at 2024-02-08T00:37:13-05:00
gitignore: Ignore .hadrian_ghci_multi/

- - - - -
d7ee12ea by Ben Gamari at 2024-02-08T00:37:13-05:00
hadrian: Set -this-package-name

When constructing the GHC flags for a package Hadrian must take care to
set `-this-package-name` in addition to `-this-unit-id`. This hasn't
broken until now as we have not had any uses of qualified package
imports. However, this will change with `filepath-1.5` and the
corresponding `unix` bump, breaking `hadrian/multi-ghci`.

- - - - -
f2dffd2e by Ben Gamari at 2024-02-08T00:37:13-05:00
Bump filepath to 1.5.0.0

Required bumps of the following submodules:

 * `directory`
 * `filepath`
 * `haskeline`
 * `process`
 * `unix`
 * `hsc2hs`
 * `Win32`
 * `semaphore-compat`

and the addition of `os-string` as a boot package.

- - - - -
ab533e71 by Matthew Pickering at 2024-02-08T00:37:50-05:00
Use specific clang assembler when compiling with -fllvm

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

- - - - -
c32b6426 by Matthew Pickering at 2024-02-08T00:37:50-05:00
Update CI images with LLVM 15, ghc-9.6.4 and cabal-install-3.10.2.0

- - - - -
5fcd58be by Matthew Pickering at 2024-02-08T00:37:50-05:00
Update bootstrap plans for 9.4.8 and 9.6.4

- - - - -
707a32f5 by Matthew Pickering at 2024-02-08T00:37:50-05:00
Add alpine 3_18 release job

This is mainly experimental and future proofing to enable a smooth
transition to newer alpine releases once 3_12 is too old.

- - - - -
c37931b3 by John Ericson at 2024-02-08T06:39:05-05:00
Generate LLVM min/max bound policy via Hadrian

Per #23966, I want the top-level configure to only generate
configuration data for Hadrian, not do any "real" tasks on its own.
This is part of that effort --- one less file generated by it.

(It is still done with a `.in` file, so in a future world non-Hadrian
also can easily create this file.)

Split modules:

- GHC.CmmToLlvm.Config
- GHC.CmmToLlvm.Version
- GHC.CmmToLlvm.Version.Bounds
- GHC.CmmToLlvm.Version.Type

This also means we can get rid of the silly `unused.h` introduced in
!6803 / 7dfcab2f4bcb7206174ea48857df1883d05e97a2 as temporary kludge.

Part of #23966

- - - - -
9f987235 by Apoorv Ingle at 2024-02-08T06:39:42-05:00
Enable mdo statements to use HsExpansions
Fixes: #24411
Added test T24411 for regression

- - - - -
762b2120 by Jade at 2024-02-08T15:17:15+00:00
Improve Monad, Functor & Applicative docs

This patch aims to improve the documentation of Functor, Applicative,
Monad and related symbols. The main goal is to make it more consistent
and make accessible. See also: !10979 (closed) and !10985 (closed)

Ticket #17929

Updates haddock submodule

- - - - -
151770ca by Josh Meredith at 2024-02-10T14:28:15-05:00
JavaScript codegen: Use GHC's tag inference where JS backend-specific evaluation inference was previously used (#24309)

- - - - -
2e880635 by Zubin Duggal at 2024-02-10T14:28:51-05:00
ci: Allow release-hackage-lint to fail

Otherwise it blocks the ghcup metadata pipeline from running.

- - - - -
b0293f78 by Matthew Pickering at 2024-02-10T14:29:28-05:00
rts: eras profiling mode

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

- - - - -
be674a2c by Jade at 2024-02-10T14:30:04-05:00
Adjust error message for trailing whitespace in as-pattern.

Fixes #22524

- - - - -
53ef83f9 by doyougnu at 2024-02-10T14:30:47-05:00
gitlab: js: add codeowners

Fixes:
- #24409

Follow on from:
- #21078 and MR !9133
- When we added the JS backend this was forgotten. This patch adds the
rightful codeowners.

- - - - -
8bbe12f2 by Matthew Pickering at 2024-02-10T14:31:23-05:00
Bump CI images so that alpine3_18 image includes clang15

The only changes here are that clang15 is now installed on the
alpine-3_18 image.

- - - - -
db8fdca9 by Andrei Borzenkov at 2024-02-12T17:01:45+03:00
Parser, renamer, type checker for @a-binders (17594)

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 2afbddb0f24, 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 f5d3e03c56f.

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 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, isInvisibleForAllTyFlag vis
    = ...

In addition to that, tcMatchPats no longer discards type patterns. This
is done by filterOutErasedPats in the desugarer instead.

- - - - -


30 changed files:

- .gitignore
- .gitlab-ci.yml
- .gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml
- .gitlab/rel_eng/fetch-gitlab-artifacts/fetch_gitlab.py
- .gitmodules
- CODEOWNERS
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/CmmToLlvm.hs
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/CmmToLlvm/Config.hs
- + compiler/GHC/CmmToLlvm/Version.hs
- + compiler/GHC/CmmToLlvm/Version/Bounds.hs.in
- + compiler/GHC/CmmToLlvm/Version/Type.hs
- compiler/GHC/Driver/DynFlags.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Driver/Pipeline/Phases.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Pmc/Desugar.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a7c60d3d6f47378bd9a532e47b04a03921843ff5...db8fdca9ea353b844a7dabab845aeb716a7d609c

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a7c60d3d6f47378bd9a532e47b04a03921843ff5...db8fdca9ea353b844a7dabab845aeb716a7d609c
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240212/639ba9dd/attachment-0001.html>


More information about the ghc-commits mailing list