| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
As requested by @treeowl in CLC#139.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20114
MR: !10390
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
|
|
|
|
|
|
|
| |
As noticed by @Terrorjack, `hs_init_ghc` previously used non-atomic
increment/decrement on the RTS's initialization count. This may go wrong
in a multithreaded program which initializes the runtime multiple times.
Closes #22756.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fixes #23277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@gmail.com>
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20115
MR: !10350
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
There was recomentation to use map head . group . sort instead of nub
function, but containers library has more suitable and efficient
analogue
|
|
|
|
| |
This has no observable effect, but avoids storing useless data.
|
| |
|
|
|
|
| |
fixes #23278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
| |
Includes fix upload_ghc_libs glob
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@tweag.io>
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20115
MR: !10336
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
|
|
|
|
|
|
|
|
| |
This commit implements GHC proposal #433, adding the Unsatisfiable
class to the GHC.TypeError module. This provides an alternative to
TypeError for which error reporting is more predictable: we report it
when we are reporting unsolved Wanted constraints.
Fixes #14983 #16249 #16906 #18310 #20835
|
| |
|
|
|
|
| |
This patch includes all wasm32-specific testsuite fixes.
|
|
|
|
|
|
|
| |
This patch adds missing annotations (req_th, req_dynamic_lib_support,
req_rts_linker) to some tests. They were discovered when testing
wasm32, though it's better to be explicit about what features they
require, rather than simply adding when(arch('wasm32'), skip).
|
|
|
|
|
|
|
| |
This patch adds the req_host_target_ghc predicate to the testsuite to
assert the ghc compiler being tested can compile both host/target
code. When testing cross GHCs this is not supported yet, but it may
change in the future.
|
|
|
|
|
|
| |
This patch adds the req_process predicate to the testsuite to assert
the platform has a process model, also marking tests that involve
spawning processes as req_process. Also bumps hpc & process submodule.
|
|
|
|
|
|
|
| |
This patch adds the req_ghc_with_threaded_rts predicate to the
testsuite to assert the platform has threaded RTS, and mark some tests
as req_ghc_with_threaded_rts. Also makes ghc_with_threaded_rts a
config field instead of a global variable.
|
|
|
|
|
|
|
|
| |
When the testsuite driver copy files instead of symlinking them, it
should also copy the permission bits, otherwise there'll be permission
denied errors. Also, enforce file copying when testing wasm32, since
wasmtime doesn't handle host symlinks quite well
(https://github.com/bytecodealliance/wasmtime/issues/6227).
|
|
|
|
|
|
| |
This patch implements logic to automatically exclude ghci ways when
there is no rts linker. It's way better than having to annotate
individual test cases.
|
|
|
|
|
|
| |
This patch fixes hp2ps related framework failures when testing the
wasm backend by including target exe extension in heap profile
filenames.
|
|
|
|
|
|
|
|
| |
This patch fixes cross prefix stripping in the testsuite driver. The
normalization logic used to only handle prefixes of the triple form
<arch>-<vendor>-<os>, now it's relaxed to allow any number of tokens
in the prefix tuple, so the cross prefix stripping logic would work
when ghc is configured with something like --target=wasm32-wasi.
|
|
|
|
|
|
| |
This patch enables bignum native & unregisterised wasm32 jobs as
manual jobs in validate pipelines, which can be useful to prevent
breakage when working on wasm32 related patches.
|
|
|
|
|
| |
For the time being, we still need to use in-tree mode and can't test
the bindist yet.
|
|
|
|
|
|
|
|
|
| |
!9018 brought in exact print annotations in LayoutInfo for open and
close braces at the top level.
But it retained them in the HsModule annotations too.
Remove the originals, so exact printing uses LayoutInfo
|
|
|
|
|
|
|
|
|
| |
#22364)
Carry the actual type of an expression through the PreStgRhs and into GenStgRhs
for use in later stages. Currently this is used in the JavaScript backend to fix
some tests from the above mentioned issues: EtaExpandLevPoly, RepPolyWrappedVar2,
T13822, T14749.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #23208 we observed that the demand signature of a binder occuring in a RULE
wasn't unleashed, leading to a transitively used binder being discarded as
absent. The solution was to use the same code path that we already use for
handling exported bindings.
See the changes to `Note [Absence analysis for stable unfoldings and RULES]`
for more details.
I took the chance to factor out the old notion of a `PlusDmdArg` (a pair of a
`VarEnv Demand` and a `Divergence`) into `DmdEnv`, which fits nicely into our
existing framework. As a result, I had to touch quite a few places in the code.
This refactoring exposed a few small bugs around correct handling of bottoming
demand environments. As a result, some strictness signatures now mention uniques
that weren't there before which caused test output changes to T13143, T19969 and
T22112. But these tests compared whole -ddump-simpl listings which is a very
fragile thing to begin with. I changed what exactly they test for based on the
symptoms in the corresponding issues.
There is a single regression in T18894 because we are more conservative around
stable unfoldings now. Unfortunately it is not easily fixed; let's wait until
there is a concrete motivation before invest more time.
Fixes #23208.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Added new section in the GHC user's guide that legends behavior of
nested implicit parameter bindings in these two cases:
let ?f = 1 in let ?f = 2 in ?f
and
data T where MkT :: (?f :: Int) => T
f :: T -> T -> Int
f MkT MkT = ?f
- Added new test case to examine this behavior.
|
| |
|