| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
- reordered the 3 SRT implementation cases from the most general to the
most specific one:
USE_SRT_POINTER -> USE_SRT_OFFSET -> USE_INLINE_SRT_FIELD
- added requirements for each
- found and documented a confusion about "SRT inlining" not supported
with MachO. (It is fixed in the following commit)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM64_RELOC_SUBTRACTOR relocations are paired with an
AMR64_RELOC_UNSIGNED relocation to implement: addend + sym1 - sym2
The linker was doing it in two steps, basically:
*addend <- *addend - sym2
*addend <- *addend + sym1
The first operation was likely to overflow. For example when the
relocation target was 32-bit and both sym1/sym2 were 64-bit addresses.
With the small memory model, (sym1-sym2) would fit in 32 bits but
(*addend-sym2) may not.
Now the linker does it in one step:
*addend <- *addend + sym1 - sym2
|
|
|
|
| |
it is still re-exported from GHC.Exts
|
| |
|
|
|
|
| |
Fixes #21659
|
|
|
|
|
|
|
|
|
| |
The theory is that on windows there is some difference in the
environment between pipelines on master and merge requests which affects
all tests equally but because T16875 barely allocates anything it is the
test which is affected the most.
See #21557
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit acb188e0 introduced a regression in the computation of free
variables in mdo statements, as the logic in
GHC.Rename.Expr.segmentRecStmts was slightly different depending on
whether the recursive do block corresponded to an mdo statement or
a rec statment.
This patch restores the previous computation for mdo blocks.
Fixes #21654
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves handling of the magic 'withDict' function from the desugarer
to the typechecker. Details in Note [withDict].
I've extracted a part of T16646Fail to a separate file T16646Fail2,
because the new error in 'reify' hides the errors from 'f' and 'g'.
WithDict now works with casts, this fixes #21328.
Part of #19915
|
|
|
|
|
|
| |
fix #21658
fix #21657
fix #21657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function breakTyVarCycle_maybe has been installed
in a dark corner of GHC to catch some gremlins (a.k.a.
occurs-check failures) who lurk
there. But it previously only caught gremlins of the
form (a ~ ... F a ...), where some of our intrepid users
have spawned gremlins of the form (G a ~ ... F (G a) ...).
This commit improves breakTyVarCycle_maybe (and renames
it to breakTyEqCycle_maybe) to catch the new gremlins.
Happily, the change is remarkably small.
The gory details are in Note [Type equality cycles].
Test cases: typecheck/should_compile/{T21515,T21473}.
|
|
|
|
|
| |
This patch adds several tests relating to the eta-expansion of
data constructors, including UnliftedNewtypes and DataTypeContexts.
|
| |
|
|
|
|
| |
We want `DynFlags` only mentioned in `GHC.Driver`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
executablePath support for NetBSD was added in
a172be07e3dce758a2325104a3a37fc8b1d20c9c, but the test was not
updated.
Update the test so that it works for NetBSD. This requires handling
some quirks:
- The result of getExecutablePath could include "./" segments.
Therefore use System.FilePath.equalFilePath to compare paths.
- The sysctl(2) call returns the original executable name even after
it was deleted. Add `canQueryAfterDelete :: [FilePath]` and
adjust expectations for the post-delete query accordingly.
Also add a note to the `executablePath` haddock to advise that
NetBSD behaves differently from other OSes when the file has been
deleted.
Also accept a decrease in memory usage for T16875. On Windows, the
metric is -2.2% of baseline, just outside the allowed ±2%. I don't
see how this commit could have influenced this metric, so I suppose
it's something in the CI environment.
Metric Decrease:
T16875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The executablePath test strips the file extension (if any) when
comparing the query result with the expected value. This is to
handle platforms where GHC adds a file extension to the output
program file (e.g. .exe on Windows).
After the initial check, the file gets deleted (if supported).
However, it tries to delete the *stripped* filename, which is
incorrect. The test currently passes only because Windows does not
allow deleting the program while any process created from it is
alive.
Make the test program correct in general by deleting the
*non-stripped* executable filename.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functions `pushCoValArg` and `pushCoercionIntoLambda` could
introduce bad representation-polymorphism. Example:
type RR :: RuntimeRep
type family RR where { RR = IntRep }
type F :: TYPE RR
type family F where { F = Int# }
co = GRefl F (TYPE RR[0])
:: (F :: TYPE RR)
~# (F |> TYPE RR[0] :: TYPE IntRep)
f :: F -> ()
`pushCoValArg` would transform the unproblematic application
(f |> (co -> <()>)) (arg :: F |> TYPE RR[0])
into an application in which the argument does not have a fixed
`RuntimeRep`:
f ((arg |> sym co) :: (F :: TYPE RR))
|
|
|
|
| |
Progress towards #17957
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch typechecks record updates by desugaring them inside
the typechecker using the HsExpansion mechanism, and then typechecking
this desugared result.
Example:
data T p q = T1 { x :: Int, y :: Bool, z :: Char }
| T2 { v :: Char }
| T3 { x :: Int }
| T4 { p :: Float, y :: Bool, x :: Int }
| T5
The record update `e { x=e1, y=e2 }` desugars as follows
e { x=e1, y=e2 }
===>
let { x' = e1; y' = e2 } in
case e of
T1 _ _ z -> T1 x' y' z
T4 p _ _ -> T4 p y' x'
The desugared expression is put into an HsExpansion, and we typecheck
that.
The full details are given in Note [Record Updates] in GHC.Tc.Gen.Expr.
Fixes #2595 #3632 #10808 #10856 #16501 #18311 #18802 #21158 #21289
Updates haddock submodule
|
|
|
|
|
|
|
|
|
|
|
|
| |
The simple optimiser would sometimes fail to
beta-reduce a lambda when there were casts
in between the lambda and its arguments.
This can cause problems because we rely on
representation-polymorphic lambdas getting
beta-reduced away (for example, those
that arise from newtype constructors with
representation-polymorphic arguments, with
UnliftedNewtypes).
|
|
|
|
|
| |
Metric Decrease:
T16875
|
|
|
|
|
|
|
| |
The conditional in hadrian/bindist/Makefile depended on the target OS,
but it makes more sense to use whether we are using a relocatable build.
(Currently this only gets set to true on Windows, but this ensures
that the logic stays correctly coupled.)
|
|
|
|
|
|
|
|
|
|
|
| |
-haddock on GHC < 9.0 is quite fragile and can result in obtuse parse errors
when it encounters invalid haddock syntax.
This has started to affect users since 297156e0b8053a28a860e7a18e1816207a59547b
enabled -haddock by default on many flavours.
Furthermore, since we don't test bootstrapping with 8.10 on CI, this problem
managed to slip throught the cracks.
|
|
|
|
|
|
| |
We use the 64bit shifts only on 64bit platforms. But we
compile the code always so compiling it on 32bit caused a
lint error. So use Word64 instead.
|
|
|
|
| |
This should get rid of most, if not all "Overlong lists" errors and fix #20016
|
|
|
|
|
|
|
| |
With all the recent W^X fixes in the loader this workaround is not
necessary any longer. I verified that the only tests failing for me on
OpenBSD 7.1-current are the same (libc++ related) before and after
this commit (with --fast).
|
|
|
|
|
|
| |
`install.mk` is already included by `config.mk`. Moreover, `install.mk`
depends upon `config.mk` to set `RelocatableBuild`, making this first
include incorrect.
|
|
|
|
|
|
|
| |
Using regexp pattern requires `egrep` and straight up `+`. The
haddock_parser_perf and haddock_renamer_perf tests now pass on
OpenBSD. They previously incorrectly parsed the files and awk
complained about invalid syntax.
|
|
|
|
| |
Resolves #21455
|
| |
|
|
|
|
|
|
|
| |
Make sure comments captured in the exact print annotations are in
order of increasing location
Closes #20718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code
data instance Method PGMigration = MigrationQuery Query
-- ^ Run a query against the database
| MigrationCode (Connection -> IO (Either String ()))
-- ^ Run any arbitrary IO code
Resulted in two instances of the "-- ^ Run a query against the database"
comment appearing in the Exact Print Annotations when it was parsed.
Ensure only one is kept.
Closes #20239
|
|
|
|
|
|
|
| |
We don't need any more resolution than this.
Rename the field to `stgToCmmEmitDebugInfo` to indicate it is no longer
conveying any "level" information.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses a relatively obscure situation that arose
when chasing perf regressions in !7847, which itself is fixing
It does two things:
* SpecConstr can specialise on ($df d1 d2) dictionary arguments
* FloatOut no longer checks argument strictness
See Note [Specialising on dictionaries] in GHC.Core.Opt.SpecConstr.
A test case is difficult to construct, but it makes a big difference
in nofib/real/eff/VSM, at least when we have the patch for #21286
installed. (The latter stops worker/wrapper for dictionary arguments).
There is a spectacular, but slightly illusory, improvement in
runtime perf on T15426. I have documented the specifics in
T15426 itself.
Metric Decrease:
T15426
|
|
|
|
| |
Progress towards #17957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were considering all Typeable evidence to be "BuiltinInstance"s which
meant the stage restriction was going unchecked. In-fact, typeable has
evidence and so we need to apply the stage restriction.
This is
complicated by the fact we don't generate typeable evidence and the
corresponding DFunIds until after typechecking is concluded so we
introcue a new `InstanceWhat` constructor, BuiltinTypeableInstance which
records whether the evidence is going to be local or not.
Fixes #21547
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, `Backend` becomes an abstract type
(there are no more exposed value constructors).
Decisions that were formerly made by asking "is the
current back end equal to (or different from) this named value
constructor?" are now made by interrogating the back end about
its properties, which are functions exported by `GHC.Driver.Backend`.
There is a description of how to migrate code using `Backend` in the
user guide.
Clients using the GHC API can find a backdoor to access the Backend
datatype in GHC.Driver.Backend.Internal.
Bumps haddock submodule.
Fixes #20927
|
|
|
|
|
|
|
|
| |
In the validate script we are careful to use the $make variable as this
stores whether we are using gmake, make, quiet mode etc. There was just
this one place where we failed to use it.
Fixes #21598
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This firstly caused spurious output to be emitted (as evidenced by
#21555) but even worse caused a massive coercion to be attempted to be
printed (> 200k terms) which would invariably eats up all the memory of
your computer.
The good news is that removing this trace allows the program to compile
to completion, the bad news is that the program exhibits a core lint
error (on 9.0.2) but not any other releases it seems.
Fixes #21577 and #21555
|
|
|
|
|
|
| |
These were previously incorrect.
Fixes #21553.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds module `GHC.Cmm.Dominators`, which provides a wrapper
around two existing algorithms in GHC: the Lengauer-Tarjan dominator
analysis from the X86 back end and the reverse postorder ordering from
the Cmm Dataflow framework. Issue #20726 proposes that we evaluate
some alternatives for dominator analysis, but for the time being, the
best path forward is simply to use the existing analysis on
`CmmGraph`s.
This commit addresses a bullet in #21200.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously only checked the stage 1/2 compiler
for --target support. We got away with this for quite a while but it
eventually caught up with us in #21579, where `bytestring`'s new NEON
implementation was unbuildable on Darwin due to Rosetta's seemingly
random logic for determining which executable image to execute. This
lead to a confusing failure to build `bytestring`'s cbits, when `clang`
tried to compile NEON builtins while targetting x86-64.
Fix this by checking CC_STAGE0 for --target support.
Fixes #21579.
|