| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
A potential contributor said that they weren't aware of
ghc-proposals. This might increase visibility.
|
| |
|
|
| |
Fixes #20598, which is mostly a duplicate of #18824 but for GHC 9.2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, these flags were passed when both compiling and linking
code. However, `-pie` and `-no-pie` are link-time-only options. Usually,
this does not cause issues, but when using Clang with `-Werror` set
results in errors:
clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument]
This is unused by Clang because this flag has no effect at compile time
(it’s called `-nopie` internally by Clang but called `-no-pie` in GHC
for compatibility with GCC). Just passing these flags at linking time
resolves this.
Additionally, update #15319 hack to look for `-pgml` instead.
Because of the main change, the value of `-pgmc` does not matter when
checking for the workaround of #15319. However, `-pgml` *does* still
matter as not all `-pgml` values support `-no-pie`.
To cover all potential values, we assume that no custom `-pgml` values
support `-no-pie`. This means that we run the risk of not using
`-no-pie` when it is otherwise necessary for in auto-hardened
toolchains! This could be a problem at some point, but this workaround
was already introduced in 8d008b71 and we might as well continue
supporting it.
Likewise, mark `-pgmc-supports-no-pie` as deprecated and create a new
`-pgml-supports-no-pie`.
|
| |
|
|
|
|
|
|
|
|
| |
This saves a lot of repeated work on big dependency graphs.
-------------------------
Metric Decrease:
MultiLayerModules
T13719
-------------------------
|
| |
|
|
|
|
|
|
| |
Two reasons for this change:
1. Avoid computing the transitive dependencies when compiling each
module, this can save a lot of repeated work.
2. More robust to forthcoming changes to support multiple home units.
|
| |
|
|
| |
Fixes #20621
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The user guide wrongly stated that default methods should not
be included in hs-boot files. In fact, if the class is not left
abstract (no methods, no superclass constraints, ...) then the
defaults must be provided and match with those given in the .hs
file.
We add some tests for this, as there were no tests in the testsuite
that gave rise to the "missing default methods" error.
Fixes #20588
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- rename the function f4 to h1 for consistency with
the naming convention
- be more explicit about the difference between
`Int -> (forall a. a -> a)`
and
`forall a. Int -> (a -> a)`
- reorder the section to make it flow better
Fixes #20585
|
| |
|
|
| |
Close #19938.
|
| |
|
|
|
|
|
|
| |
- Fix cut/paste error by adding missing `c` pattern in `Vec3`
traversable instance.
- Add a bit of contextual prose above the Vec2/Vec3 instance
sample code.
|
| | |
|
| |
|
|
|
|
| |
`Note [The stupid context]` in `GHC.Core.DataCon` talks about stupid contexts
from `DatatypeContexts`, but prior to this commit, it was rather outdated.
This commit spruces it up and references it from places where it is relevant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, derived instances that use `deriving` clauses would infer
`DatatypeContexts` by using `tyConStupidTheta`. But this sometimes causes
redundant constraints to be included in the derived instance contexts, as the
constraints that appear in the `tyConStupidTheta` may not actually appear in
the types of the data constructors (i.e., the `dataConStupidTheta`s). For
instance, in `data Show a => T a = MkT deriving Eq`, the type of `MkT` does
not require `Show`, so the derived `Eq` instance should not require `Show`
either. This patch makes it so with some small tweaks to
`inferConstraintsStock`.
Fixes #20501.
|
| | |
|
| |
|
|
|
|
|
| |
GHC is bignum backend agnostic and shouldn't report this information as
in the future ghc-bignum will be reinstallable potentially with a
different backend that GHC is unaware of. Moreover as #20495 shows the
returned information may be wrong currently.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should still default kind variables in type families
in the presence of -XNoPolyKinds, to avoid suggesting enabling
-XPolyKinds just because the function arrow introduced kind variables,
e.g.
type family F (t :: Type) :: Type where
F (a -> b) = b
With -XNoPolyKinds, we should still default `r :: RuntimeRep`
in `a :: TYPE r`.
Fixes #20584
|
| |
|
|
|
|
|
|
|
|
|
| |
Although I thought we were already set to handle unlifted datatypes correctly,
it appears we weren't. #20631 showed that it's wrong to assume
`vi_bot=IsNotBot` for `VarInfo`s of unlifted types from their inception if we
don't follow up with an inhabitation test to see if there are any habitable
constructors left. We can't trigger the test from `emptyVarInfo`, so now we
instead fail early in `addBotCt` for variables of unlifted types.
Fixed #20631.
|
| |
|
|
| |
These will be useful for upcoming RTS configure script.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Type kind is printed unqualified:
ghci> :set -XNoStarIsType
ghci> :k (->)
(->) :: Type -> Type -> Type
This is the desired behavior unless the user has defined
their own Type:
ghci> data Type
Then we want to resolve the ambiguity by qualification:
ghci> :k (->)
(->) :: GHC.Types.Type -> GHC.Types.Type -> GHC.Types.Type
|
| |
|
|
|
|
|
|
| |
In #20599 I ran into an issue where the unfolding for a join point was
eta-reduced removing the required lambdas.
This patch adds guards that should prevent this from happening going
forward.
|
| |
|
|
|
|
| |
* No more need for InlineHdkM, mkHdkM
* unHdkM is now just a record selector
* Update comments
|
| |
|
|
| |
GHC produced broken executables with rebindable if and -fhpc if `ifThenElse` expected non-Bool condition until GHC 9.0. This adds a simple regression test.
|
| |
|
|
|
|
|
|
| |
Performance improvement:
T15185(normal) run/alloc 51112.0 41032.0 -19.7% GOOD
Metric Decrease:
T15185
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Primops types were dependent on the target word-size at *compiler*
compilation time. It's an issue for multi-target as GHC may not have the
correct primops types for the target.
This patch fixes some primops types: if they take or return fixed 64-bit
values they now always use `Int64#/Word64#`, even on 64-bit
architectures (where they used `Int#/Word#` before). Users of these
primops may now need to convert from Int64#/Word64# to Int#/Word# (a
no-op at runtime).
This is a stripped down version of !3658 which goes the all way of
changing the underlying primitive types of Word64/Int64. This is left
for future work.
T12545 allocations increase ~4% on some CI platforms and decrease ~3% on
AArch64.
Metric Increase:
T12545
Metric Decrease:
T12545
|
| | |
|
| |
|
|
|
|
| |
When the input literal was larger than 32-bit it would crash in a
compiler with assertion enabled because it was creating an out-of-bound
word-sized literal (32-bit).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I accidently got the two branches of the if expression the wrong way
around when refactoring.
Fixes #20567
|
| |
|
|
|
|
|
|
|
| |
We should strive to make our includes in terms of the RTS as much as
possible. One place there that is not possible, the llvm version, we
make a new tiny header
Stage numbers are somewhat arbitrary, if we simple need a newer RTS, we
should say so.
|
| |
|
|
|
| |
This will make it easier to add and remove generated headers, as we will
do when we add a configure script for the RTS.
|
| |
|
|
|
|
|
|
| |
At some point in the past this started working. I noticed this when
working on multiple home units and couldn't load GHC's dependencies into
the interpreter.
Fixes #7388
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ticket #20562 revealed that Solo, which is a wired-in TyCon, had
a record field that wasn't being added to the type env. Why not?
Because wired-in TyCons don't have record fields.
It's not hard to change that, but it's tiresome for this one use-case,
and it seems easier simply to make `getSolo` into a standalone
function.
On the way I refactored the handling of Solo slightly, to put it
into wiredInTyCons (where it belongs) rather than only in
knownKeyNames
|
| | |
|
| |
|
|
| |
Close #20433
|
| |
|
|
|
|
|
|
|
| |
This patch corrects the instruction for load_load_barrier().
Current load_load_barrier() incorrectly uses `fence w,r`.
It means a store-load barrier.
See also linux-kernel's smp_rmb() implementation:
https://github.com/torvalds/linux/blob/v5.14/arch/riscv/include/asm/barrier.h#L27
|
| | |
|
| | |
|
| |
|
|
|
|
| |
`dirname $0` doesn't work when the wrapper is called via a symbolic link.
Fix #20589
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The ghc-exactPrint library has had to re-introduce the relatavise
phase.
This is needed if you change the length of an identifier and want the
layout to be preserved afterwards.
It is not possible to relatavise a bare SrcSpan, so introduce `SrcAnn
NoEpAnns` for them instead.
Updates haddock submodule.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were always converting empty GADT contexts to `Just []` in `GHC.ThToHs`,
which caused the pretty-printer to always print them as `() => ...`. This is
easily fixed by using the `mkHsContextMaybe` function when converting GADT
contexts so that empty contexts are turned to `Nothing`. This is in the same
tradition established in commit 4c87a3d1d14f9e28c8aa0f6062e9c4201f469ad7.
In the process of fixing this, I discovered that the `Cxt` argument to
`mkHsContextMaybe` is completely unnecessary, as we can just as well check if
the `LHsContext GhcPs` argument is empty.
Fixes #20590.
|
| |
|
|
| |
We can depend on all of them at once the same way.
|
| |
|
|
| |
It is dead code.
|
