| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
We only support building static profiling libraries, the transformer was
requesting things like a dynamic, threaded, debug, profiling RTS, which
we have never produced nor distributed.
Fixes #21567
|
| |
|
|
| |
This seems to fail on the ancient version of bash present on CentOS
|
| |
|
|
|
|
|
| |
The centos docker image lacks the sphinx builder so we disable building
sphinx docs for these jobs.
Fixes #21580
|
| |
|
|
|
|
|
|
| |
The release flavour is essentially the same as the perf flavour
currently but also enables `-haddock`. I have hopefully updated all the
relevant places where the `-perf` flavour was hardcoded.
Fixes #21486
|
| | |
|
| |
|
|
| |
Fixes #21336.
|
| |
|
|
|
| |
This introduces a global hook which is called when an exception is
thrown during finalization.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LlvmConfig contains information read from llvm-passes and llvm-targets
files in GHC's top directory. Reading these files is done only when
needed (i.e. when the LLVM backend is used) and cached for the whole
compiler session. This patch changes the way this is done:
- Split LlvmConfig into LlvmConfig and LlvmConfigCache
- Store LlvmConfigCache in HscEnv instead of DynFlags: there is no
good reason to store it in DynFlags. As it is fixed per session, we
store it in the session state instead (HscEnv).
- Initializing LlvmConfigCache required some changes to driver functions
such as newHscEnv. I've used the opportunity to untangle initHscEnv
from initGhcMonad (in top-level GHC module) and to move it to
GHC.Driver.Main, close to newHscEnv.
- I've also made `cmmPipeline` independent of HscEnv in order to remove
the call to newHscEnv in regalloc_unit_tests.
|
| |
|
|
|
|
| |
This is now fixed on master and 9.2 branch.
Closes #21558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating an SRT for a recursive group, GHC.Cmm.Info.Build.oneSRT
filters out recursive references, as described in Note [recursive SRTs].
However, doing so for static functions would be unsound, for the reason
described in Note [Invalid optimisation: shortcutting].
However, the same argument applies to static data constructor
applications, as we discovered in #20959. Fix this by ensuring that
static data constructor applications are included in recursive SRTs.
The approach here is not entirely satisfactory, but it is a starting
point.
Fixes #20959.
|
| |
|
|
|
|
|
|
|
|
| |
Here we implement a few measures to improve the clarity of the CAF
analysis implementation. Specifically:
* Use CafInfo instead of Bool since the former is more descriptive
* Rename CAFLabel to CAFfyLabel, since not all CAFfyLabels are in fact
CAFs
* Add numerous comments
|
| |
|
|
|
| |
Those files were moved to the perf/ subtree in 11c9a469, and then
accidentally reintroduced in 680ef2c8.
|
| |
|
|
|
|
| |
This bumps the time submodule to the 1.12.2 release.
Fixes #21571
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This MR fixes a bad bug, where the withDict was inlined too
vigorously, which in turn made the type-class Specialiser generate
a bogus specialisation, because it saw the same overloaded function
applied to two /different/ dictionaries.
Solution: inline `withDict` later. See (WD8) of Note [withDict]
in GHC.HsToCore.Expr
See #21575, which is fixed by this change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using defaultSDocContext for pprTrace, which suppresses
lots of useful infomation. This small MR adds
GHC.Utils.Outputable.traceSDocContext
and uses it for pprTrace and pprTraceUserWarning.
traceSDocContext is a global, and hence not influenced by flags,
but that seems unavoidable. But I made the sdocPprDebug bit
controlled by unsafeHasPprDebug, since we have the latter for
exactly this purpose.
Fixes #21569
|
| |
|
|
| |
for better disambiguation (#17420)
|
| |
|
|
|
|
|
| |
Test that we can successfully link against C++ code both in GHCi and
batch compilation.
See #20010
|
| |
|
|
|
|
|
|
| |
Here we introduce a new "virtual" package into the initial package
database, `system-cxx-std-lib`. This gives users a convenient, platform
agnostic way to link against C++ libraries, addressing #20010.
Fixes #20010.
|
| | |
|
