[Git][ghc/ghc][wip/23305] 20 commits: Add sized primitive literal syntax

Matthew Pickering (@mpickering) gitlab at gitlab.haskell.org
Fri May 5 09:33:28 UTC 2023 


Matthew Pickering pushed to branch wip/23305 at Glasgow Haskell Compiler / GHC


Commits:
931c8d82 by Ben Orchard at 2023-05-03T20:16:18-04:00
Add sized primitive literal syntax

Adds a new LANGUAGE pragma ExtendedLiterals, which enables defining
unboxed numeric literals such as `0xFF#Word8 :: Word8#`.

Implements GHC proposal 0451:
https://github.com/ghc-proposals/ghc-proposals/blob/b384a538b34f79d18a0201455b7b3c473bc8c936/proposals/0451-sized-literals.rst

Fixes #21422.

Bumps haddock submodule.

Co-authored-by: Krzysztof Gogolewski <krzysztof.gogolewski at tweag.io>

- - - - -
f3460845 by Bodigrim at 2023-05-03T20:16:57-04:00
Document instances of Double

- - - - -
1e9caa1a by Sylvain Henry at 2023-05-03T20:17:37-04:00
Bump Cabal submodule (#22356)

- - - - -
4eafb52a by sheaf at 2023-05-03T20:18:16-04:00
Don't forget to check the parent in an export list

Commit 3f374399 introduced a bug which caused us to forget to include
the parent of an export item of the form T(..) (that is, IEThingAll)
when checking for duplicate exports.

Fixes #23318

- - - - -
8fde4ac8 by amesgen at 2023-05-03T20:18:57-04:00
Fix unlit path in cross bindists

- - - - -
8cc9a534 by Matthew Pickering at 2023-05-04T14:58:14-04:00
hadrian: Flavour: Change args -> extraArgs

Previously in a flavour definition you could override all the flags
which were passed to GHC. This causes issues when needed to compute a
package hash because we need to know what these extra arguments are
going to be before computing the hash. The solution is to modify flavour
so that the arguments you pass here are just extra ones rather than all
the arguments that you need to compile something.

This makes things work more like how cabal.project files work when you
give extra arguments to a package and also means that flavour
transformers correctly affect the hash.

- - - - -
3fdb18f8 by romes at 2023-05-04T14:58:14-04:00
Hardwire a better unit-id for ghc

Previously, the unit-id of ghc-the-library was fixed as `ghc`.
This was done primarily because the compiler must know the unit-id of
some packages (including ghc) a-priori to define wired-in names.

However, as seen in #20742, a reinstallable `ghc` whose unit-id is fixed
to `ghc` might result in subtle bugs when different ghc's interact.

A good example of this is having GHC_A load a plugin compiled by GHC_B,
where GHC_A and GHC_B are linked to ghc-libraries that are ABI
incompatible. Without a distinction between the unit-id of the ghc library
GHC_A is linked against and the ghc library the plugin it is loading was
compiled against, we can't check compatibility.

This patch gives a slightly better unit-id to ghc (ghc-version) by
(1) Not setting -this-unit-id to ghc, but rather to the new unit-id (modulo stage0)
(2) Adding a definition to `GHC.Settings.Config` whose value is the new unit-id.
    (2.1) `GHC.Settings.Config` is generated by Hadrian
    (2.2) and also by cabal through `compiler/Setup.hs`
This unit-id definition is imported by `GHC.Unit.Types` and used to
set the wired-in unit-id of "ghc", which was previously fixed to "ghc"

The commits following this one will improve the unit-id with a
cabal-style package hash and check compatibility when loading plugins.

Note that we also ensure that ghc's unit key matches unit id both when
hadrian or cabal builds ghc, and in this way we no longer need to add
`ghc` to the WiringMap.

- - - - -
6689c9c6 by romes at 2023-05-04T14:58:14-04:00
Validate compatibility of ghcs when loading plugins

Ensure, when loading plugins, that the ghc the plugin depends on is the
ghc loading the plugin -- otherwise fail to load the plugin.

Progress towards #20742.

- - - - -
db4be339 by romes at 2023-05-04T14:58:14-04:00
Add hashes to unit-ids created by hadrian

This commit adds support for computing an inputs hash for packages
compiled by hadrian. The result is that ABI incompatible packages should
be given different hashes and therefore be distinct in a cabal store.

Hashing is enabled by the `--flag`, and is off by default as the hash
contains a hash of the source files. We enable it when we produce
release builds so that the artifacts we distribute have the right unit
ids.

- - - - -
944a9b94 by Matthew Pickering at 2023-05-04T14:58:14-04:00
Use hash-unit-ids in release jobs

Includes fix upload_ghc_libs glob

- - - - -
116d7312 by Josh Meredith at 2023-05-04T14:58:51-04:00
JS: fix bounds checking (Issue 23123)

* For ByteArray-based bounds-checking, the JavaScript backend must use the
`len` field, instead of the inbuild JavaScript `length` field.

* Range-based operations must also check both the start and end of the range
for bounds

* All indicies are valid for ranges of size zero, since they are essentially no-ops

* For cases of ByteArray accesses (e.g. read as Int), the end index is
(i * sizeof(type) + sizeof(type) - 1), while the previous implementation
uses (i + sizeof(type) - 1). In the Int32 example, this is (i * 4 + 3)

* IndexByteArrayOp_Word8As* primitives use byte array indicies (unlike
the previous point), but now check both start and end indicies

* Byte array copies now check if the arrays are the same by identity and
then if the ranges overlap.

- - - - -
2d5c1dde by Sylvain Henry at 2023-05-04T14:58:51-04:00
Fix remaining issues with bound checking (#23123)

While fixing these I've also changed the way we store addresses into
ByteArray#. Addr# are composed of two parts: a JavaScript array and an
offset (32-bit number).

Suppose we want to store an Addr# in a ByteArray# foo at offset i.
Before this patch, we were storing both fields as a tuple in the "arr"
array field:

  foo.arr[i] = [addr_arr, addr_offset];

Now we only store the array part in the "arr" field and the offset
directly in the array:

  foo.dv.setInt32(i, addr_offset):
  foo.arr[i] = addr_arr;

It avoids wasting space for the tuple.

- - - - -
98c5ee45 by Luite Stegeman at 2023-05-04T14:59:31-04:00
JavaScript: Correct arguments to h$appendToHsStringA

fixes #23278

- - - - -
ca611447 by Josh Meredith at 2023-05-04T15:00:07-04:00
base/encoding: add an allocations performance test (#22946)

- - - - -
e3ddf58d by Krzysztof Gogolewski at 2023-05-04T15:00:44-04:00
linear types: Don't add external names to the usage env

This has no observable effect, but avoids storing useless data.

- - - - -
b3226616 by Andrei Borzenkov at 2023-05-04T15:01:25-04:00
Improved documentation for the Data.OldList.nub function

There was recomentation to use map head . group . sort instead of nub
function, but containers library has more suitable and efficient
analogue

- - - - -
e8b72ff6 by Ryan Scott at 2023-05-04T15:02:02-04:00
Fix type variable substitution in gen_Newtype_fam_insts

Previously, `gen_Newtype_fam_insts` was substituting the type variable binders
of a type family instance using `substTyVars`, which failed to take type
variable dependencies into account. There is similar code in
`GHC.Tc.TyCl.Class.tcATDefault` that _does_ perform this substitution properly,
so this patch:

1. Factors out this code into a top-level `substATBndrs` function, and
2. Uses `substATBndrs` in `gen_Newtype_fam_insts`.

Fixes #23329.

- - - - -
a0f5c55a by Matthew Pickering at 2023-05-05T10:33:18+01:00
Fix behaviour of -keep-tmp-files when used in OPTIONS_GHC pragma

This fixes the behaviour of -keep-tmp-files when used in an OPTIONS_GHC
pragma for files with module level scope.

Instead of simple not deleting the files, we also need to remove them
from the TmpFs so they are not deleted later on when all the other files
are deleted.

There are additional complications because you also need to remove the
directory where these files live from the TmpFs so we don't try to
delete those later either.

I added two tests.

1. Tests simply that -keep-tmp-files works at all with a single module
   and --make mode.
2. The other tests that temporary files are deleted for other modules
   which don't enable -keep-tmp-files.

Fixes #23339

- - - - -
4d1d819a by Matthew Pickering at 2023-05-05T10:33:18+01:00
withDeferredDiagnostics: When debugIsOn, write landmine into IORef to catch use-after-free.

Ticket #23305 reports an error where we were attempting to use the
logger which was created by withDeferredDiagnostics after its scope had
ended.

This problem would have been caught by this patch and a validate build:

```
+*** Exception: Use after free
+CallStack (from HasCallStack):
+  error, called at compiler/GHC/Driver/Make.hs:<line>:<column> in <package-id>:GHC.Driver.Make
```

This general issue is tracked by #20981

- - - - -
1315c369 by Matthew Pickering at 2023-05-05T10:33:18+01:00
Don't return complete HscEnv from upsweep

By returning a complete HscEnv from upsweep the logger (as introduced by
withDeferredDiagnostics) was escaping the scope of
withDeferredDiagnostics and hence we were losing error messages.

This is reminiscent of #20981, which also talks about writing errors
into messages after their scope has ended.

See #23305 for details.

- - - - -


30 changed files:

- .gitlab/gen_ci.hs
- .gitlab/jobs.yaml
- .gitlab/rel_eng/upload_ghc_libs.py
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/UsageEnv.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Lit.hs
- compiler/GHC/Hs/Syn/Type.hs
- compiler/GHC/HsToCore/Match/Literal.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Runtime/Loader.hs
- compiler/GHC/StgToJS/Apply.hs
- compiler/GHC/StgToJS/Linker/Utils.hs
- compiler/GHC/StgToJS/Prim.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Gen/Export.hs
- compiler/GHC/Tc/Gen/Head.hs
- compiler/GHC/Tc/TyCl/Class.hs
- compiler/GHC/Unit/Types.hs
- compiler/GHC/Utils/TmpFs.hs
- compiler/Language/Haskell/Syntax/Extension.hs
- compiler/Language/Haskell/Syntax/Lit.hs
- compiler/Setup.hs
- compiler/ghc.cabal.in
- docs/users_guide/9.8.1-notes.rst
- + docs/users_guide/exts/extended_literals.rst
- docs/users_guide/exts/literals.rst
- docs/users_guide/exts/primitives.rst


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/384c9a2f0ce460d2f167f2dfc9fe6d823db580e4...1315c369203302fcba8f4f5966bf0d834b93b866

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/384c9a2f0ce460d2f167f2dfc9fe6d823db580e4...1315c369203302fcba8f4f5966bf0d834b93b866
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/20230505/eee0bf77/attachment-0001.html>

More information about the ghc-commits mailing list