| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This adds a new mode, `--merge-objs`, which can be used to produce
merged GHCi library objects.
As future work we will rip out the object-merging logic in Hadrian and
Cabal and instead use this mode.
Closes #20712.
|
| |
|
|
| |
This field was entirely unused.
|
| |
|
|
|
|
|
|
|
| |
- Change the dumpPrefix to FilePath, and default to non-module
- Add dot to seperate dump-file-prefix and suffix
- Modify user guide to introduce how dump files are named
- This commit does not affect Ghci dump file naming.
See also #17500
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment if `-dynamic-too` fails then we rerun the whole pipeline
as if we were just in `-dynamic` mode. I argue this is a misfeature and
we should remove the so-called `DT_Failed` mode.
In what situations do we fall back to `DT_Failed`?
1. If the `dyn_hi` file corresponding to a `hi` file is missing completely.
2. If the interface hash of `dyn_hi` doesn't match the interface hash of `hi`.
What happens in `DT_Failed` mode?
* The whole compiler pipeline is rerun as if the user had just passed `-dynamic`.
* Therefore `dyn_hi/dyn_o` files are used which don't agree with the
`hi/o` files. (As evidenced by `dynamicToo001` test).
* This is very confusing as now a single compiler invocation has
produced further `hi`/`dyn_hi` files which are different to each
other.
Why should we remove it?
* In `--make` mode, which is predominately used `DT_Failed` does not
work (#19782), there can't be users relying on this functionality.
* In `-c` mode, the recovery doesn't fix the root issue, which is the
`dyn_hi` and `hi` files are mismatched. We should instead produce an
error and pass responsibility to the build system using `-c` to ensure
that the prerequisites for `-dynamic-too` (dyn_hi/hi) files are there
before we start compiling.
* It is a misfeature to support use cases like `dynamicToo001` which
allow you to mix different versions of dynamic/non-dynamic interface
files. It's more likely to lead to subtle bugs in your resulting
programs where out-dated build products are used rather than a
deliberate choice.
* In practice, people are usually compiling with `-dynamic-too` rather
than separately with `-dynamic` and `-static`, so the build products
always match and `DT_Failed` is only entered due to compiler bugs (see
!6583)
What should we do instead?
* In `--make` mode, for home packages check during recompilation
checking that `dyn_hi` and `hi` are both present and agree, recompile
the modules if they do not.
* For package modules, when loading the interface check that `dyn_hi`
and `hi` are there and that they agree but fail with an
error message if they are not.
* In `--oneshot` mode, fail with an error message if the right files
aren't already there.
Closes #19782 #20446 #9176 #13616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ModLocation is the data type which tells you the locations of all the
build products which can affect recompilation. It is now computed in one
place and not modified through the pipeline. Important locations will
now just consult ModLocation rather than construct the dynamic object
path incorrectly.
* Add paths for dynamic object and dynamic interface files to
ModLocation.
* Always use the paths from mod location when looking for where to find
any interface or object file.
* Always use the paths in a ModLocation when deciding where to write an
interface and object file.
* Remove `dynamicOutputFile` and `dynamicOutputHi` functions which
*calculated* (incorrectly) the location of `dyn_o` and `dyn_hi` files.
* Don't set `outputFile_` and so-on in `enableCodeGenWhen`, `-o` and
hence `outputFile_` should not affect the location of object files in
`--make` mode. It is now sufficient to just update the ModLocation with
the temporary paths.
* In `hscGenBackendPipeline` don't recompute the `ModLocation` to
account for `-dynamic-too`, the paths are now accurate from the start
of the run.
* Rename `getLocation` to `mkOneShotModLocation`, as that's the only
place it's used. Increase the locality of the definition by moving it
close to the use-site.
* Load the dynamic interface from ml_dyn_hi_file rather than attempting
to reconstruct it in load_dynamic_too.
* Add a variety of tests to check how -o -dyno etc interact with each
other.
Some other clean-ups
* DeIOify mkHomeModLocation and friends, they are all pure functions.
* Move FinderOpts into GHC.Driver.Config.Finder, next to initFinderOpts.
* Be more precise about whether we mean outputFile or outputFile_: there
were many places where outputFile was used but the result shouldn't have
been affected by `-dyno` (for example the filename of the resulting
executable). In these places dynamicNow would never be set but it's
still more precise to not allow for this possibility.
* Typo fixes suffices -> suffixes in the appropiate places.
|
| |
|
|
|
| |
This "fixes" DT_Failed in --make mode, but only "fixes" because I still
believe DT_Failed is pretty broken.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fixes #20416
I thought about adding a test for this case but I struggled to think of
something robust. Grepping -v3 will include different paths on different
systems and the structure of the result file depends on which
preprocessor you are using.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch specifies and simplifies the module cycle compilation
in upsweep. How things work are described in the Note [Upsweep]
Note [Upsweep]
~~~~~~~~~~~~~~
Upsweep takes a 'ModuleGraph' as input, computes a build plan and then executes
the plan in order to compile the project.
The first step is computing the build plan from a 'ModuleGraph'.
The output of this step is a `[BuildPlan]`, which is a topologically sorted plan for
how to build all the modules.
```
data BuildPlan = SingleModule ModuleGraphNode -- A simple, single module all alone but *might* have an hs-boot file which isn't part of a cycle
| ResolvedCycle [ModuleGraphNode] -- A resolved cycle, linearised by hs-boot files
| UnresolvedCycle [ModuleGraphNode] -- An actual cycle, which wasn't resolved by hs-boot files
```
The plan is computed in two steps:
Step 1: Topologically sort the module graph without hs-boot files. This returns a [SCC ModuleGraphNode] which contains
cycles.
Step 2: For each cycle, topologically sort the modules in the cycle *with* the relevant hs-boot files. This should
result in an acyclic build plan if the hs-boot files are sufficient to resolve the cycle.
The `[BuildPlan]` is then interpreted by the `interpretBuildPlan` function.
* `SingleModule nodes` are compiled normally by either the upsweep_inst or upsweep_mod functions.
* `ResolvedCycles` need to compiled "together" so that the information which ends up in
the interface files at the end is accurate (and doesn't contain temporary information from
the hs-boot files.)
- During the initial compilation, a `KnotVars` is created which stores an IORef TypeEnv for
each module of the loop. These IORefs are gradually updated as the loop completes and provide
the required laziness to typecheck the module loop.
- At the end of typechecking, all the interface files are typechecked again in
the retypecheck loop. This time, the knot-tying is done by the normal laziness
based tying, so the environment is run without the KnotVars.
* UnresolvedCycles are indicative of a proper cycle, unresolved by hs-boot files
and are reported as an error to the user.
The main trickiness of `interpretBuildPlan` is deciding which version of a dependency
is visible from each module. For modules which are not in a cycle, there is just
one version of a module, so that is always used. For modules in a cycle, there are two versions of
'HomeModInfo'.
1. Internal to loop: The version created whilst compiling the loop by upsweep_mod.
2. External to loop: The knot-tied version created by typecheckLoop.
Whilst compiling a module inside the loop, we need to use the (1). For a module which
is outside of the loop which depends on something from in the loop, the (2) version
is used.
As the plan is interpreted, which version of a HomeModInfo is visible is updated
by updating a map held in a state monad. So after a loop has finished being compiled,
the visible module is the one created by typecheckLoop and the internal version is not
used again.
This plan also ensures the most important invariant to do with module loops:
> If you depend on anything within a module loop, before you can use the dependency,
the whole loop has to finish compiling.
The end result of `interpretBuildPlan` is a `[MakeAction]`, which are pairs
of `IO a` actions and a `MVar (Maybe a)`, somewhere to put the result of running
the action. This list is topologically sorted, so can be run in order to compute
the whole graph.
As well as this `interpretBuildPlan` also outputs an `IO [Maybe (Maybe HomeModInfo)]` which
can be queried at the end to get the result of all modules at the end, with their proper
visibility. For example, if any module in a loop fails then all modules in that loop will
report as failed because the visible node at the end will be the result of retypechecking
those modules together.
Along the way we also fix a number of other bugs in the driver:
* Unify upsweep and parUpsweep.
* Fix #19937 (static points, ghci and -j)
* Adds lots of module loop tests due to Divam.
Also related to #20030
Co-authored-by: Divam Narula <dfordivam@gmail.com>
-------------------------
Metric Decrease:
T10370
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make mkDependencies pure
* Use Sets instead of sorted lists
Notable perf changes:
MultiLayerModules(normal) ghc/alloc 4130851520.0 2981473072.0 -27.8%
T13719(normal) ghc/alloc 4313296052.0 4151647512.0 -3.7%
Metric Decrease:
MultiLayerModules
T13719
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is small step towards #19877. We want to make the Loader/Linker
interface more abstract to be easily reused (i.e. don't pass it
DynFlags) but the system linker uses TmpFs which required a DynFlags
value to get its temp directory. We explicitly pass the temp directory
now. Similarly TmpFs was consulting the DynFlags to decide whether to
clean or: this is now done by the caller in the driver code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts the runPipeline function to be implemented in terms
of a free monad rather than the previous CompPipeline.
The advantages of this are three-fold:
1. Different parts of the pipeline can return different results, the
limits of runPipeline were being pushed already by !5555, this opens up
futher fine-grainedism of the pipeline.
2. The same mechanism can be extended to build-plan at the module level
so the whole build plan can be expressed in terms of one computation
which can then be treated uniformly.
3. The pipeline monad can now be interpreted in different ways, for
example, you may want to interpret the `TPhase` action into the monad
for your own build system (such as shake). That bit will probably
require a bit more work, but this is a step in the right directin.
There are a few more modules containing useful functions for interacting
with the pipelines.
* GHC.Driver.Pipeline: Functions for building pipelines at a high-level
* GHC.Driver.Pipeline.Execute: Functions for providing the default
interpretation of TPhase, in terms of normal IO.
* GHC.Driver.Pipeline.Phases: The home for TPhase, the typed phase data
type which dictates what the phases are.
* GHC.Driver.Pipeline.Monad: Definitions to do with the TPipelineClass
and MonadUse class.
Hooks consumers may notice the type of the `phaseHook` has got
slightly more restrictive, you can now no longer control the
continuation of the pipeline by returning the next phase to execute but
only override individual phases. If this is a problem then please open
an issue and we will work out a solution.
-------------------------
Metric Decrease:
T4029
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use DiagOpts for diagnostic options instead of directly querying
DynFlags (#17957).
Surprising performance improvements on CI:
T4801(normal) ghc/alloc 313236344.0 306515216.0 -2.1% GOOD
T9961(normal) ghc/alloc 384502736.0 380584384.0 -1.0% GOOD
ManyAlternatives(normal) ghc/alloc 797356128.0 786644928.0 -1.3%
ManyConstructors(normal) ghc/alloc 4389732432.0 4317740880.0 -1.6%
T783(normal) ghc/alloc 408142680.0 402812176.0 -1.3%
Metric Decrease:
T4801
T9961
T783
ManyAlternatives
ManyConstructors
Bump haddock submodule
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is an attempt at reducing the number of dependencies of the Parser
(as reported by CountParserDeps). Modules in GHC.Parser.* don't import
GHC.Driver.Session directly anymore.
Sadly some GHC.Driver.* modules are still transitively imported and the
number of dependencies didn't decrease. But it's a step in the right
direction.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce LogFlags as a independent subset of DynFlags used for logging.
As a consequence in many places we don't have to pass both Logger and
DynFlags anymore.
The main reason for this refactoring is that I want to refactor the
systools interfaces: for now many systools functions use DynFlags both
to use the Logger and to fetch their parameters (e.g. ldInputs for the
linker). I'm interested in refactoring the way they fetch their
parameters (i.e. use dedicated XxxOpts data types instead of DynFlags)
for #19877. But if I did this refactoring before refactoring the Logger,
we would have duplicate parameters (e.g. ldInputs from DynFlags and
linkerInputs from LinkerOpts). Hence this patch first.
Some flags don't really belong to LogFlags because they are subsystem
specific (e.g. most DumpFlags). For example -ddump-asm should better be
passed in NCGConfig somehow. This patch doesn't fix this tight coupling:
the dump flags are part of the UI but they are passed all the way down
for example to infer the file name for the dumps.
Because LogFlags are a subset of the DynFlags, we must update the former
when the latter changes (not so often). As a consequence we now use
accessors to read/write DynFlags in HscEnv instead of using `hsc_dflags`
directly.
In the process I've also made some subsystems less dependent on DynFlags:
- CmmToAsm: by passing some missing flags via NCGConfig (see new fields
in GHC.CmmToAsm.Config)
- Core.Opt.*:
- by passing -dinline-check value into UnfoldingOpts
- by fixing some Core passes interfaces (e.g. CallArity, FloatIn)
that took DynFlags argument for no good reason.
- as a side-effect GHC.Core.Opt.Pipeline.doCorePass is much less
convoluted.
|
| |
|
|
|
|
|
|
|
|
|
| |
This commit replaces the PsUnknownMessage diagnostics over at
`GHC.Parser.Header` with a new `PsHeaderMessage` type (part of
the more general `PsMessage`), so that we can throw parser header's
errors which can be correctly caught by `GHC.Driver.Pipeline.preprocess`
and rewrapped (correctly) as Driver messages (using the
`DriverPsHeaderMessage`).
This gets rid of the nasty compiler crash as part of #19923.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch comprises of four different but closely related ideas. The
net result is fixing a large number of open issues with the driver
whilst making it simpler to understand.
1. Use the hash of the source file to determine whether the source file
has changed or not. This makes the recompilation checking more robust to
modern build systems which are liable to copy files around changing
their modification times.
2. Remove the concept of a "stable module", a stable module was one
where the object file was older than the source file, and all transitive
dependencies were also stable. Now we don't rely on the modification
time of the source file, the notion of stability is moot.
3. Fix TH/plugin recompilation after the removal of stable modules. The
TH recompilation check used to rely on stable modules. Now there is a
uniform and simple way, we directly track the linkables which were
loaded into the interpreter whilst compiling a module. This is an
over-approximation but more robust wrt package dependencies changing.
4. Fix recompilation checking for dynamic object files. Now we actually
check if the dynamic object file exists when compiling with -dynamic-too
Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change aims to make source files relocatable w.r.t. to the interface files produced by the compiler.
This is so that we can download interface files produced by a cloud build system and then reuse them in a local ghcide session
catch another case of implicit includes
actually use the implicit quote includes
add another missing case
recomp020
test that .hi files are reused even if .hs files are moved to a new location
Added recomp021 to record behaviour with non implicit includes
add a note
additional pointer to the note
Mention #16956 in Note
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit converts the lexers and all the parser machinery to use the
new parser types and diagnostics infrastructure. Furthermore, it cleans
up the way the parser code was emitting hints.
As a result of this systematic approach, the test output of the
`InfixAppPatErr` and `T984` tests have been changed. Previously they
would emit a `SuggestMissingDo` hint, but this was not at all helpful in
resolving the error, and it was even confusing by just looking at the
original program that triggered the errors.
Update haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit does some de-duplication of logic between the one-shot and --make
modes, and splitting of some of the APIs so that its easier to do the
fine-grained parallelism implementation. This is the first part of the
implementation plan as described in #14095
* compileOne now uses the runPhase pipeline for most of the work.
The Interpreter backend handling has been moved to the runPhase.
* hscIncrementalCompile has been broken down into multiple APIs.
* haddock submodule bump: Rename of variables in html-test ref:
This is caused by a change in ModDetails in case of NoBackend.
Now the initModDetails is used to recreate the ModDetails from interface and
in-memory ModDetails is not used.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit extends the GHC diagnostic hierarchy with a `GhcHint` type,
modelling helpful suggestions emitted by GHC which can be used to deal
with a particular warning or error.
As a direct consequence of this, the `Diagnostic` typeclass has been extended
with a `diagnosticHints` method, which returns a `[GhcHint]`. This means
that now we can clearly separate out the printing of the diagnostic
message with the suggested fixes.
This is done by extending the `printMessages` function in
`GHC.Driver.Errors`.
On top of that, the old `PsHint` type has been superseded by the new `GhcHint`
type, which de-duplicates some hints in favour of a general `SuggestExtension`
constructor that takes a `GHC.LanguageExtensions.Extension`.
|
| |
|
|
|
|
|
| |
arguments (#19827)
Previously we assumed that the assembler was the same as the c compiler,
but we allow setting them to different programs with -pgmc and -pgma.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit modifies interface files so that *only* direct information
about modules and packages is stored in the interface file.
* Only direct module and direct package dependencies are stored in the
interface files.
* Trusted packages are now stored separately as they need to be checked
transitively.
* hs-boot files below the compiled module in the home module are stored
so that eps_is_boot can be calculated in one-shot mode without loading
all interface files in the home package.
* The transitive closure of signatures is stored separately
This is important for two reasons
* Less recompilation is needed, as motivated by #16885, a lot of
redundant compilation was triggered when adding new imports deep in the
module tree as all the parent interface files had to be redundantly
updated.
* Checking an interface file is cheaper because you don't have to
perform a transitive traversal to check the dependencies are up-to-date.
In the code, places where we would have used the transitive closure, we
instead compute the necessary transitive closure. The closure is not
computed very often, was already happening in checkDependencies, and
was already happening in getLinkDeps.
Fixes #16885
-------------------------
Metric Decrease:
MultiLayerModules
T13701
T13719
-------------------------
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Replace uses of WARN macro with calls to:
warnPprTrace :: Bool -> SDoc -> a -> a
Remove the now unused HsVersions.h
Bump haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no reason to use CPP. __LINE__ and __FILE__ macros are now
better replaced with GHC's CallStack. As a bonus, assert error messages
now contain more information (function name, column).
Here is the mapping table (HasCallStack omitted):
* ASSERT: assert :: Bool -> a -> a
* MASSERT: massert :: Bool -> m ()
* ASSERTM: assertM :: m Bool -> m ()
* ASSERT2: assertPpr :: Bool -> SDoc -> a -> a
* MASSERT2: massertPpr :: Bool -> SDoc -> m ()
* ASSERTM2: assertPprM :: m Bool -> SDoc -> m ()
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds GhcMessage and ancillary (PsMessage, TcRnMessage, ..)
types.
These types will be expanded to represent more errors generated
by different subsystems within GHC. Right now, they are underused,
but more will come in the glorious future.
See
https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
for a design overview.
Along the way, lots of other things had to happen:
* Adds Semigroup and Monoid instance for Bag
* Fixes #19746 by parsing OPTIONS_GHC pragmas into Located Strings.
See GHC.Parser.Header.toArgs (moved from GHC.Utils.Misc, where it
didn't belong anyway).
* Addresses (but does not completely fix) #19709, now reporting
desugarer warnings and errors appropriately for TH splices.
Not done: reporting type-checker warnings for TH splices.
* Some small refactoring around Safe Haskell inference, in order
to keep separate classes of messages separate.
* Some small refactoring around initDsTc, in order to keep separate
classes of messages separate.
* Separate out the generation of messages (that is, the construction
of the text block) from the wrapping of messages (that is, assigning
a SrcSpan). This is more modular than the previous design, which
mixed the two.
Close #19746.
This was a collaborative effort by Alfredo di Napoli and
Richard Eisenberg, with a key assist on #19746 by Iavor
Diatchki.
Metric Increase:
MultiLayerModules
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When -dynamic-too is enabled, there are two result files, .o and .dyn_o,
therefore we should check both to decide whether to set SourceModified
or not.
The whole recompilation logic is very messy, a more thorough refactor
would be beneficial in this area but this is the minimal patch to fix
this more high priority problem.
Fixes #17968 and hopefully #17534
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This vastly reduces memory usage when compiling with `--make` mode, from
about 900M when compiling Cabal to about 300M.
As a matter of uniformity, it also ensures that reading from an
interface performs the same as using the in-memory cache. We can also
delete all the horrible knot-tying in updateIdInfos.
Goes some way to fixing #13586
Accept new output of tests fixing some bugs along the way
-------------------------
Metric Decrease:
T12545
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch we switch from reading the globally installed
platformConstants file to reading the DerivedConstants.h header file
that is bundled in the RTS unit. When we build the RTS unit itself, we
get it from its includes directories.
The new parser is more efficient and strict than the Read instance for
PlatformConstants and we get about 2.2MB less allocations in every
cases. However it only really shows in tests that don't allocate much,
hence the following metric decreases.
Metric Decrease:
Naperian
T10421
T10547
T12150
T12234
T12425
T13035
T18304
T18923
T5837
T6048
T18140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit further expand on the design for #18516 by getting rid of
the `defaultReasonSeverity` in favour of a function called
`diagReasonSeverity` which correctly takes the `DynFlags` as input. The
idea is to compute the `Severity` and the `DiagnosticReason` of each
message "at birth", without doing any later re-classifications, which
are potentially error prone, as the `DynFlags` might evolve during the
course of the program.
In preparation for a proper refactoring, now `pprWarning` from the
Parser.Ppr module has been renamed to `mkParserWarn`, which now takes a
`DynFlags` as input.
We also get rid of the reclassification we were performing inside `printOrThrowWarnings`.
Last but not least, this commit removes the need for reclassify inside GHC.Tc.Errors,
and also simplifies the implementation of `maybeReportError`.
Update Haddock submodule
|
| | |
|
| | |
|
| |
|
|
|
| |
Also make the HomeUnit optional to keep the field strict and prepare for
UnitEnvs without a HomeUnit (e.g. in Plugins envs, cf #14335).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other than that:
* Fix T16167,json,json2,T7478,T10637 tests to reflect the introduction of
the `MessageClass` type
* Remove `makeIntoWarning`
* Remove `warningsToMessages`
* Refactor GHC.Tc.Errors
1. Refactors GHC.Tc.Errors so that we use `DiagnosticReason` for "choices"
(defer types errors, holes, etc);
2. We get rid of `reportWarning` and `reportError` in favour of a general
`reportDiagnostic`.
* Introduce `DiagnosticReason`, `Severity` is an enum: This big commit makes
`Severity` a simple enumeration, and introduces the concept of `DiagnosticReason`,
which classifies the /reason/ why we are emitting a particular diagnostic.
It also adds a monomorphic `DiagnosticMessage` type which is used for
generic messages.
* The `Severity` is computed (for now) from the reason, statically.
Later improvement will add a `diagReasonSeverity` function to compute
the `Severity` taking `DynFlags` into account.
* Rename `logWarnings` into `logDiagnostics`
* Add note and expand description of the `mkHoleError` function
|
| |
|
|
|
|
|
|
|
|
| |
In the future, we want `HscEnv` to support multiple home units
at the same time. This means, that there will be 'Target's that do
not belong to the current 'HomeUnit'.
This is an API change without changing behaviour.
Update haddock submodule to incorporate API changes.
|
| | |
|
| | |
|
| |
|
|
| |
This enables a registerised build for the riscv64 architecture.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new flag embeds a lookup table from the address of an info table
to information about that info table.
The main interface for consulting the map is the `lookupIPE` C function
> InfoProvEnt * lookupIPE(StgInfoTable *info)
The `InfoProvEnt` has the following structure:
> typedef struct InfoProv_{
> char * table_name;
> char * closure_desc;
> char * ty_desc;
> char * label;
> char * module;
> char * srcloc;
> } InfoProv;
>
> typedef struct InfoProvEnt_ {
> StgInfoTable * info;
> InfoProv prov;
> struct InfoProvEnt_ *link;
> } InfoProvEnt;
The source positions are approximated in a similar way to the source
positions for DWARF debugging information. They are only approximate but
in our experience provide a good enough hint about where the problem
might be. It is therefore recommended to use this flag in conjunction
with `-g<n>` for more accurate locations.
The lookup table is also emitted into the eventlog when it is available
as it is intended to be used with the `-hi` profiling mode.
Using this flag will significantly increase the size of the resulting
object file but only by a factor of 2-3x in our experience.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, the only way to override GHC's default logging
behavior was to set `log_action`, `dump_action` and `trace_action`
fields in DynFlags. This patch introduces a new Logger abstraction and
stores it in HscEnv instead.
This is part of #17957 (avoid storing state in DynFlags). DynFlags are
duplicated and updated per-module (because of OPTIONS_GHC pragma), so
we shouldn't store global state in them.
This patch also fixes a race in parallel "--make" mode which updated
the `generatedDumps` IORef concurrently.
Bump haddock submodule
The increase in MultilayerModules is tracked in #19293.
Metric Increase:
MultiLayerModules
|
| |
|
|
| |
Updates Haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
See T19264 for a tricky corner case when explicitly importing
GHC.Num.BigNat and another module. With -dynamic-too, the FinderCache
contains paths for non-dynamic interfaces so they must be loaded first,
which is usually the case, except for some interfaces loaded in the
backend (e.g. in CorePrep).
So we must run the backend for the non-dynamic way first for
-dynamic-too to work as it is but I broke this invariant in
c85f4928d4dbb2eb2cf906d08bfe7620d6f04ca5 by mistakenly making the
backend run for the dynamic way first.
|
