[Git][ghc/ghc][wip/T23146] 17 commits: Add structured error messages for GHC.Rename.Utils
Rodrigo Mesquita (@alt-romes)
gitlab at gitlab.haskell.org
Mon May 8 09:27:22 UTC 2023
Rodrigo Mesquita pushed to branch wip/T23146 at Glasgow Haskell Compiler / GHC
Commits:
275836d2 by Torsten Schmits at 2023-05-05T08:43:02+00:00
Add structured error messages for GHC.Rename.Utils
Tracking ticket: #20115
MR: !10350
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
- - - - -
983ce558 by Oleg Grenrus at 2023-05-05T13:11:29-04:00
Use TemplateHaskellQuotes in TH.Syntax to construct Names
- - - - -
a5174a59 by Matthew Pickering at 2023-05-05T18:42:31-04:00
driver: Use hooks from plugin_hsc_env
This fixes a bug in oneshot mode where hooks modified in a plugin
wouldn't be used in oneshot mode because we neglected to use the right
hsc_env. This was observed by @csabahruska.
- - - - -
18a7d03d by Aaron Allen at 2023-05-05T18:42:31-04:00
Rework plugin initialisation points
In general this patch pushes plugin initialisation points to earlier in
the pipeline. As plugins can modify the `HscEnv`, it's imperative that
the plugins are initialised as soon as possible and used thereafter.
For example, there are some new tests which modify hsc_logger and other
hooks which failed to fire before (and now do)
One consequence of this change is that the error for specifying the
usage of a HPT plugin from the command line has changed, because it's
now attempted to be loaded at initialisation rather than causing a
cyclic module import.
Closes #21279
Co-authored-by: Matthew Pickering <matthewtpickering at gmail.com>
- - - - -
6e776ed3 by Matthew Pickering at 2023-05-05T18:42:31-04:00
docs: Add Note [Timing of plugin initialization]
- - - - -
e1df8511 by Matthew Pickering at 2023-05-05T18:43:07-04:00
Incrementally update ghcup metadata in ghc/ghcup-metadata
This job paves the way for distributing nightly builds
* A new repo https://gitlab.haskell.org/ghc/ghcup-metadata stores the
metadata on the "updates" branch.
* Each night this metadata is downloaded and the nightly builds are
appended to the end of the metadata.
* The update job only runs on the scheduled nightly pipeline, not just
when NIGHTLY=1.
Things which are not done yet
* Modify the retention policy for nightly jobs
* Think about building release flavour compilers to distribute nightly.
Fixes #23334
- - - - -
8f303d27 by Rodrigo Mesquita at 2023-05-05T22:04:31-04:00
docs: Remove mentions of ArrayArray# from unlifted FFI section
Fixes #23277
- - - - -
994bda56 by Torsten Schmits at 2023-05-05T22:05:12-04:00
Add structured error messages for GHC.Rename.Module
Tracking ticket: #20115
MR: !10361
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
Only addresses the single warning missing from the previous MR.
- - - - -
cf76eca0 by Ben Gamari at 2023-05-08T10:27:00+01:00
testsuite: Add tests for #23146
Both lifted and unlifted variants.
- - - - -
96bdef3a by Ben Gamari at 2023-05-08T10:27:00+01:00
codeGen: Fix some Haddocks
- - - - -
8adcf90e by Ben Gamari at 2023-05-08T10:27:00+01:00
codeGen: Give proper LFInfo to datacon wrappers
As noted in `Note [Conveying CAF-info and LFInfo between modules]`,
when importing a binding from another module we must ensure that it gets
the appropriate `LambdaFormInfo` if it is in WHNF to ensure that
references to it are tagged correctly.
However, the implementation responsible for doing this,
`GHC.StgToCmm.Closure.mkLFImported`, only dealt with datacon workers and
not wrappers. This lead to the crash of this program in #23146:
module B where
type NP :: [UnliftedType] -> UnliftedType
data NP xs where
UNil :: NP '[]
module A where
import B
fieldsSam :: NP xs -> NP xs -> Bool
fieldsSam UNil UNil = True
x = fieldsSam UNil UNil
Due to its GADT nature, `UNil` produces a trivial wrapper
$WUNil :: NP '[]
$WUNil = UNil @'[] @~(<co:1>)
which is referenced in the RHS of `A.x`. Due to the above-mentioned bug
in `mkLFImported`, the references to `$WUNil` passed to `fieldsSam` were
not tagged. This is problematic as `fieldsSam` expected its arguments to
be tagged as they are unlifted.
The fix is straightforward: extend the logic in `mkLFImported` to cover
(nullary) datacon wrappers as well as workers. This is safe because we
know that the wrapper of a nullary datacon will be in WHNF, even if it
includes equalities evidence (since such equalities are not runtime
relevant).
Thanks to @MangoIV for the great ticket and @alt-romes for his
minimization and help debugging.
Fixes #23146.
- - - - -
3c6d972e by Rodrigo Mesquita at 2023-05-08T10:27:00+01:00
codeGen: Fix LFInfo of imported datacon wrappers
As noted in #23231 and in the previous commit, we were failing to give a
an LFInfo of LFCon to a nullary datacon wrapper from another module,
failing to properly tag pointers which ultimately led to the
segmentation fault in #23146.
On top of the previous commit which now considers wrappers where we
previously only considered workers, we change the order of the guards so
that we check for the arity of the binding before we check whether it is
a constructor. This allows us to
(1) Correctly assign `LFReEntrant` to imported wrappers whose worker was
nullary, which we previously would fail to do
(2) Remove the `isNullaryRepDataCon` predicate:
(a) which was previously wrong, since it considered wrappers whose
workers had zero-width arguments to be non-nullary and would fail to
give `LFCon` to them
(b) is now unnecessary, since arity == 0 guarantees
- that the worker takes no arguments at all
- and the wrapper takes no arguments and its RHS must be an
application of the worker to zero-width-args only.
- we lint these two items with an assertion that the datacon
`hasNoNonZeroWidthArgs`
We also update `isTagged` to use the new logic in determining the
LFInfos of imported Ids.
The creation of LFInfos for imported Ids and this detail are explained
in Note [The LFInfo of Imported Ids].
Note that before the patch to those issues we would already consider these
nullary wrappers to have `LFCon` lambda form info; but failed to re-construct
that information in `mkLFImported`
Closes #23231, #23146
(I've additionally batched some fixes to documentation I found while
investigating this issue)
- - - - -
31a7c8ba by Rodrigo Mesquita at 2023-05-08T10:27:00+01:00
Make LFInfos for DataCons on construction
As a result of the discussion in !10165, we decided to amend the
previous commit which fixed the logic of `mkLFImported` with regard to
datacon workers and wrappers.
Instead of having the logic for the LFInfo of datacons be in
`mkLFImported`, we now construct an LFInfo for all data constructors on
GHC.Types.Id.Make and store it in the `lfInfo` field.
See the new Note [LFInfo of DataCon workers and wrappers] and
ammendments to Note [The LFInfo of Imported Ids]
- - - - -
497895f2 by Rodrigo Mesquita at 2023-05-08T10:27:00+01:00
Update Note [Core letrec invariant]
Authored by @simonpj
- - - - -
b263dd1b by Rodrigo Mesquita at 2023-05-08T10:27:00+01:00
Rename mkLFImported to importedIdLFInfo
The `mkLFImported` sounded too much like a constructor of sorts, when
really it got the `LFInfo` of an imported Id from its `lf_info` field
when this existed, and otherwise returned a conservative estimate of
that imported Id's LFInfo. This in contrast to functions such as
`mkLFReEntrant` which really are about constructing an `LFInfo`.
- - - - -
9cea6c86 by Rodrigo Mesquita at 2023-05-08T10:27:00+01:00
Enforce invariant on typePrimRepArgs in the types
As part of the documentation effort in !10165 I came across this
invariant on 'typePrimRepArgs' which is easily expressed at the
type-level through a NonEmpty list.
It allowed us to remove one panic.
- - - - -
43b82817 by Rodrigo Mesquita at 2023-05-08T10:27:00+01:00
Merge outdated Note [Data con representation] into Note [Data constructor representation]
Introduce new Note [Constructor applications in STG] to better support
the merge, and reference it from the relevant bits in the STG syntax.
- - - - -
30 changed files:
- .gitlab-ci.yml
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Tidy.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Rename/Utils.hs
- compiler/GHC/Runtime/Heap/Inspect.hs
- compiler/GHC/Runtime/Loader.hs
- compiler/GHC/Stg/InferTags/Rewrite.hs
- compiler/GHC/Stg/Syntax.hs
- compiler/GHC/Stg/Unarise.hs
- compiler/GHC/StgToByteCode.hs
- compiler/GHC/StgToCmm/Closure.hs
- compiler/GHC/StgToCmm/Env.hs
- compiler/GHC/StgToCmm/Monad.hs
- compiler/GHC/StgToCmm/Types.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Module.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Hint.hs
- compiler/GHC/Types/Hint/Ppr.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c77f81c87e43b1dd1d34d7c928b323b675cab8c5...43b828178afb8eea69db223181fe2cc70f72a642
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c77f81c87e43b1dd1d34d7c928b323b675cab8c5...43b828178afb8eea69db223181fe2cc70f72a642
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/20230508/2351866f/attachment-0001.html>
More information about the ghc-commits
mailing list