| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Due to #21322.
|
| |
|
|
|
|
|
| |
It was previously failing due to #18721 and now passes with the new
toolchain.
Closes #18721.
|
| |
|
|
|
| |
Split up the C and C++ uses since the latter is significantly more
platform-dependent.
|
| | |
|
| |
|
|
|
| |
Users are supposed to import GHC.Exts rather than GHC.Prim.
Part of #18749.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes this failure:
=====> 1 of 1 [0, 0, 0]
T13366(normal) 1 of 1 [0, 0, 0] Compile failed (exit code 1) errors were:
<no location info>: error:
user specified .o/.so/.DLL could not be loaded (File not found)
Whilst trying to load: (dynamic) stdc++
Additional directories searched: (none)
*** unexpected failure for T13366(normal)
|
| | |
|
| |
|
|
|
|
|
|
| |
The pretty printer for regular data types already accounted for these,
and had some duplication with the newtype pretty printer.
Factoring the logic out into a common function and using it for both
newtypes and data declarations is enough to fix the bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the critical notes and fix outdated ones,
use `HsQuote GhcRn` (in `HsBracketTc`) for desugaring regardless of the
bracket being typed or untyped,
remove unused `EpAnn` from `Hs*Bracket GhcRn`,
zonkExpr factor out common brackets code,
ppr_expr factor out common brackets code,
and fix tests,
to finish MR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4782.
-------------------------
Metric Decrease:
hard_hole_fits
-------------------------
|
| |
|
|
|
|
| |
We still don't allow negative overloaded patterns. Earler all negative patterns
were treated as negative overloaded patterns. Now, we expliclty check the
extension field to see if the pattern is actually a negative overloaded pattern
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As #20837 pointed out, `isLiftedType_maybe` returned `Just False` in
many situations where it should return `Nothing`, because it didn't
take into account type families or type variables.
In this patch, we fix this issue. We rename `isLiftedType_maybe` to
`typeLevity_maybe`, which now returns a `Levity` instead of a boolean.
We now return `Nothing` for types with kinds of the form
`TYPE (F a1 ... an)` for a type family `F`, as well as
`TYPE (BoxedRep l)` where `l` is a type variable.
This fix caused several other problems, as other parts of the compiler
were relying on `isLiftedType_maybe` returning a `Just` value, and were
now panicking after the above fix. There were two main situations in
which panics occurred:
1. Issues involving the let/app invariant. To uphold that invariant,
we need to know whether something is lifted or not. If we get an
answer of `Nothing` from `isLiftedType_maybe`, then we don't know
what to do. As this invariant isn't particularly invariant, we
can change the affected functions to not panic, e.g. by behaving
the same in the `Just False` case and in the `Nothing` case
(meaning: no observable change in behaviour compared to before).
2. Typechecking of data (/newtype) constructor patterns. Some programs
involving patterns with unknown representations were accepted, such
as T20363. Now that we are stricter, this caused further issues,
culminating in Core Lint errors. However, the behaviour was
incorrect the whole time; the incorrectness only being revealed by
this change, not triggered by it.
This patch fixes this by overhauling where the representation
polymorphism involving pattern matching are done. Instead of doing
it in `tcMatches`, we instead ensure that the `matchExpected`
functions such as `matchExpectedFunTys`, `matchActualFunTySigma`,
`matchActualFunTysRho` allow return argument pattern types which
have a fixed RuntimeRep (as defined in Note [Fixed RuntimeRep]).
This ensures that the pattern matching code only ever handles types
with a known runtime representation. One exception was that
patterns with an unknown representation type could sneak in via
`tcConPat`, which points to a missing representation-polymorphism
check, which this patch now adds.
This means that we now reject the program in #20363, at least until
we implement PHASE 2 of FixedRuntimeRep (allowing type families in
RuntimeRep positions). The aforementioned refactoring, in which
checks have been moved to `matchExpected` functions, is a first
step in implementing PHASE 2 for patterns.
Fixes #20837
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in tcAnonWildCardOcc assumed that it could never encounter
anonymous wildcards in illegal positions, because the renamer would
have ruled them out. However, it's possible to sneak past the checks
in the renamer by using Template Haskell. It isn't possible to simply
pass on additional information when renaming Template Haskell
brackets, because we don't know in advance in what context the bracket
will be spliced in (see test case T15433b). So we accept that we might
encounter these bogus wildcards in the typechecker and throw the
appropriate error.
This patch also migrates the error messages for illegal wildcards in
types to use the diagnostic infrastructure.
Fixes #15433
|
| |
|
|
|
|
| |
Fix two issues regarding printing numeric literals.
Fixing #20454.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, surrounding a head expression with a TH splice would defeat
`tcInferAppHead_maybe`, preventing some expressions from typechecking that
used to typecheck in previous GHC versions (see #21038 for examples). This is
simple enough to fix: just look through `HsSpliceE`s in `tcInferAppHead_maybe`.
I've added some additional prose to `Note [Application chains and heads]` in
`GHC.Tc.Gen.App` to accompany this change.
Fixes #21038.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we introduce a new data structure, RoughMap, inspired by the
previous `RoughTc` matching mechanism for checking instance matches.
This allows [Fam]InstEnv to be implemented as a trie indexed by these
RoughTc signatures, reducing the complexity of instance lookup and
FamInstEnv merging (done during the family instance conflict test)
from O(n) to O(log n).
The critical performance improvement currently realised by this patch is
in instance matching. In particular the RoughMap mechanism allows us to
discount many potential instances which will never match for constraints
involving type variables (see Note [Matching a RoughMap]). In realistic
code bases matchInstEnv was accounting for 50% of typechecker time due
to redundant work checking instances when simplifying instance contexts
when deriving instances. With this patch the cost is significantly
reduced.
The larger constants in InstEnv creation do mean that a few small
tests regress in allocations slightly. However, the runtime of T19703 is
reduced by a factor of 4. Moreover, the compilation time of the Cabal
library is slightly improved.
A couple of test cases are included which demonstrate significant
improvements in compile time with this patch.
This unfortunately does not fix the testcase provided in #19703 but does
fix #20933
-------------------------
Metric Decrease:
T12425
Metric Increase:
T13719
T9872a
T9872d
hard_hole_fits
-------------------------
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>
|
| | |
|
| |
|
|
| |
The test produces different output on static vs dynamic GHC builds.
|
| |
|
|
|
|
| |
This patch ensures that the pretty printer formats LambdaCase and where
clauses using braces (instead of layout) to remain consistent with the
formatting of other statements (like `do` and `case`)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main purpose of this patch is to attach a SkolemInfo directly to
each SkolemTv. This fixes the large number of bugs which have
accumulated over the years where we failed to report errors due to
having "no skolem info" for particular type variables. Now the origin of
each type varible is stored on the type variable we can always report
accurately where it cames from.
Fixes #20969 #20732 #20680 #19482 #20232 #19752 #10946
#19760 #20063 #13499 #14040
The main changes of this patch are:
* SkolemTv now contains a SkolemInfo field which tells us how the
SkolemTv was created. Used when reporting errors.
* Enforce invariants relating the SkolemInfoAnon and level of an implication (ic_info, ic_tclvl)
to the SkolemInfo and level of the type variables in ic_skols.
* All ic_skols are TcTyVars -- Check is currently disabled
* All ic_skols are SkolemTv
* The tv_lvl of the ic_skols agrees with the ic_tclvl
* The ic_info agrees with the SkolInfo of the implication.
These invariants are checked by a debug compiler by
checkImplicationInvariants.
* Completely refactor kcCheckDeclHeader_sig which kept
doing my head in. Plus, it wasn't right because it wasn't skolemising
the binders as it decomposed the kind signature.
The new story is described in Note [kcCheckDeclHeader_sig]. The code
is considerably shorter than before (roughly 240 lines turns into 150
lines).
It still has the same awkward complexity around computing arity as
before, but that is a language design issue.
See Note [Arity inference in kcCheckDeclHeader_sig]
* I added new type synonyms MonoTcTyCon and PolyTcTyCon, and used
them to be clear which TcTyCons have "finished" kinds etc, and
which are monomorphic. See Note [TcTyCon, MonoTcTyCon, and PolyTcTyCon]
* I renamed etaExpandAlgTyCon to splitTyConKind, becuase that's a
better name, and it is very useful in kcCheckDeclHeader_sig, where
eta-expansion isn't an issue.
* Kill off the nasty `ClassScopedTvEnv` entirely.
Co-authored-by: Simon Peyton Jones <simon.peytonjones@gmail.com>
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When quoting (using a TH single or double quote) a built-in
name such as the list constructor (:), we didn't always check
that the resulting 'Name' was in the correct namespace.
This patch adds a check in GHC.Rename.Splice to ensure
we get a Name that is in the term-level/type-level namespace,
when using a single/double tick, respectively.
Fixes #20884.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.
Public Interface
~~~~~~~~~~~~~~~~
In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.
```
ghc -unit @unitLibCore -unit @unitLib
```
where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.
```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```
The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.
```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```
Then when the compiler starts in --make mode it will compile both units lib and lib-core.
There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.
Options used when working with Multiple Home Units
There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.
-working-dir ⟨dir⟩
It is common to assume that a package is compiled in the directory
where its cabal file resides. Thus, all paths used in the compiler
are assumed to be relative to this directory. When there are
multiple home units the compiler is often not operating in the
standard directory and instead where the cabal.project file is
located. In this case the -working-dir option can be passed which
specifies the path from the current directory to the directory the
unit assumes to be it’s root, normally the directory which contains
the cabal file.
When the flag is passed, any relative paths used by the compiler are
offset by the working directory. Notably this includes -i and
-I⟨dir⟩ flags.
-this-package-name ⟨name⟩
This flag papers over the awkward interaction of the PackageImports
and multiple home units. When using PackageImports you can specify
the name of the package in an import to disambiguate between modules
which appear in multiple packages with the same name.
This flag allows a home unit to be given a package name so that you
can also disambiguate between multiple home units which provide
modules with the same name.
-hidden-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules in a home unit should not be visible outside of the unit it
belongs to.
The main use of this flag is to be able to recreate the difference
between an exposed and hidden module for installed packages.
-reexported-module ⟨module name⟩
This flag can be supplied multiple times in order to specify which
modules are not defined in a unit but should be reexported. The
effect is that other units will see this module as if it was defined
in this unit.
The use of this flag is to be able to replicate the reexported
modules feature of packages with multiple home units.
Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.
For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.
```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )
foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```
> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.
A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.
Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For tools or libraries using the API there is one very important closure
property which must be adhered to:
> Any dependency which is not a home unit must not (transitively) depend
on a home unit.
For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.
If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.
Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are a few limitations of the initial implementation which will be smoothed out on user demand.
* Package thinning/renaming syntax is not supported
* More complicated reexports/renaming are not yet supported.
* It’s more common to run into existing linker bugs when loading a
large number of packages in a session (for example #20674, #20689)
* Backpack is not yet supported when using multiple home units.
* Dependency chasing can be quite slow with a large number of
modules and packages.
* Loading wired-in packages as home units is currently not supported
(this only really affects GHC developers attempting to load
template-haskell).
* Barely any normal GHCi features are supported, it would be good to
support enough for ghcid to work correctly.
Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.
Internal Changes
~~~~~~~~~~~~~~~~
* The biggest change is that the HomePackageTable is replaced with the
HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
which contains information specific to each home unit.
* The HomeUnitEnv contains:
- A unit state, each home unit can have different package db flags
- A set of dynflags, each home unit can have different flags
- A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
place the linking step into the build plan so linking can proceed in
parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
determined by looking at the value of the node. In order to achieve
this, downsweep now performs a more complete job of downsweeping and
then the dependenices are recorded forever in the node rather than
being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
of the existing API code which is unit agnostic (for example, in the
driver).
The road may be bumpy for a little while after this change but the
basics are well-tested.
One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.
Closes #10827
-------------------------
Metric Increase:
MultiLayerModules
-------------------------
Co-authored-by: Fendor <power.walross@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to providing stack traces, the scary HasCallStack will
hopefully make people think whether they want to use these functions,
i.e. act as a documentation hint that something weird might happen.
A single metric increased, which doesn't visibly
use any method with `HasCallStack`.
-------------------------
Metric Decrease:
T9630
Metric Decrease:
T19695
T9630
-------------------------
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was not possible to refer to a data constructor using
InfixT with a dynamically bound name (i.e. a name with NameFlavour
`NameS` or `NameQ`) if a type constructor of the same
name exists.
This commit adds promoted counterparts to InfixT and UInfixT,
analogously to how PromotedT is the promoted counterpart to ConT.
Closes #20773
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
T12545 is very inconsistently affected by this change for some reason.
There is a decrease in allocations on most configurations, but
an increase on validate-x86_64-linux-deb9-unreg-hadrian. Accepting it
as it seems unrelated to this patch.
Metric Decrease:
T12545
Metric Increase:
T12545
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently in GHCi, when given a line of user input we:
1. Attempt to parse and handle it as a statement
2. Otherwise, attempt to parse and handle a single import
3. Otherwise, check if there are imports present (and if so display an error message)
4. Otherwise, attempt to parse a module and only handle the declarations
This patch simplifies the process to:
Attempt to parse and handle it as a statement
Otherwise, attempt to parse a module and handle the imports and declarations
This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 8.10, when formatting a pattern match warning, we'd case split on a
wildcard match such as
```hs
foo :: [a] -> [a]
foo [] = []
foo xs = ys
where
(_, ys@(_:_)) = splitAt 0 xs
-- Pattern match(es) are non-exhaustive
-- In a pattern binding:
-- Patterns not matched:
-- ([], [])
-- ((_:_), [])
```
But that's quite verbose and distracts from which part of the pattern was
actually the inexhaustive one. We'd prefer a wildcard for the first pair
component here, like it used to be in GHC 8.8.
On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the
different constructors we could've matched on:
```hs
f :: Bool -> ()
f x = case x of {}
-- Pattern match(es) are non-exhaustive
-- In a pattern binding:
-- Patterns not matched:
-- False
-- True
```
The solution is to communicate that we want a top-level case split to
`generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what
this patch arranges. Details in `Note [Case split inhabiting patterns]`.
Fixes #20642.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Users of `undefined` don’t want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
undefined, called at file.hs:151:19 in main:Main
```
but want to see
```
files.hs: Prelude.undefined:
CallStack (from HasCallStack):
undefined, called at file.hs:151:19 in main:Main
```
so let’s make that so.
The function for that is `withFrozenCallStack`, but that is not usable
here (module dependencies, and also not representation-polymorphic). And
even if it were, it could confuse GHC’s strictness analyzer, leading to
big regressions in some perf tests (T10421 in particular).
So after shuffling modules and definitions around, I eventually noticed
that the easiest way is to just not call `error` here.
Fixes #19886
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PHASE 1: we never rewrite Concrete# evidence.
This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form
Concrete# :: forall k. k -> TupleRep '[]
Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.
This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).
fixes #17907 #20277 #20330 #20423 #20426
updates haddock submodule
-------------------------
Metric Decrease:
T5642
-------------------------
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add 19 new messages. Update test outputs accordingly.
- Pretty print suggest-extensions hints: remove space before
interspersed commas.
- Refactor Rank's MonoType constructors. Each MonoType constructor
should represent a specific case. With the Doc suggestion belonging
to the TcRnMessage diagnostics instead.
- Move Rank from Validity to its own `GHC.Tc.Types.Rank` module.
- Remove the outdated `check_irred_pred` check.
- Remove the outdated duplication check in `check_valid_theta`, which
was subsumed by `redundant-constraints`.
- Add missing test cases for quantified-constraints/T16474 & th/T12387a.
|
| | |
|
| |
|
|
|
|
|
|
| |
In GHC.Tc.Gen.Splice.tcTopSpliceExpr we were forgetting to
catch exceptions. As a result we missed the kind error
in the unsolved constraints.
This patch has an easy fix, which cures #20179
|
| |
|
|
|
| |
Here we introduce a very thin abstraction for allocating, filling, and
freezing executable pages to replace allocateExec.
|
| |
|
|
| |
Fixes #19373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous code assumed properties of the CoreToStg translation,
namely that a core let expression which be translated to a single
non-recursive top-level STG binding. This assumption was false, as
evidenced by #20060.
The consequence of this was the need to modify the call sites of
`myCoreToStgExpr`, the main one being in hscCompileCoreExpr', which
the meant we had to use byteCodeGen instead of stgExprToBCOs to convert
the returned value to bytecode.
I removed the `stgExprToBCOs` function as it is no longer
used in the compiler.
There is still some partiallity with this patch (the lookup in
hscCompileCoreExpr') but this should be more robust that before.
Fixes #20060
|
| |
|
|
| |
fixes #19756, updates haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
-------------------------
|
| |
|
|
|
| |
This fixes an oversight in the implementation of `extract_lctxt` which
was introduced in commit ce85cffc. Fixes #19759.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, the `Outputable` instance for `HsArg` was being used to
pretty-print each `HsArgPar` in a list of `HsArg`s individually, which
simply doesn't work. In lieu of the `Outputable` instance, we now use
a dedicated `pprHsArgsApp` function to print a list of `HsArg`s as a single
unit. I have also added documentation to the `Outputable` instance for `HsArg`
to more clearly signpost that it is only suitable for debug pretty-printing.
Fixes #19737.
|
| | |
|
| |
|
|
|
|
| |
Otherwise, errors can go missing which arise when running the splices.
Fixes #19470
|
