| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pattern match oracle can now cope with the abundance of information
that ViewPatterns, NPlusKPats, overloaded lists, etc. provide.
No need to have PmFake anymore!
Also got rid of a spurious call to `allCompleteMatches`, which we used to call
*for every constructor* match. Naturally this blows up quadratically for
programs like `ManyAlternatives`.
-------------------------
Metric Decrease:
ManyAlternatives
Metric Increase:
T11822
-------------------------
|
|
|
|
|
|
|
| |
This updates the documentation of the MIN_PAYLOAD_SIZE constant and adds
a new Note [Mark bits in mark-compact collector] explaning why the
mark-compact collector uses two bits per objet and why we need
MIN_PAYLOAD_SIZE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using EvVars for capturing type constraints implied side-effects in DsM
when we just wanted to *construct* type constraints.
But giving names to type constraints is only necessary when passing
Givens to the type checker, of which the majority of the pattern match
checker should be unaware.
Thus, we simply generate `newtype TyCt = TyCt PredType`, which are
nicely stateless. But at the same time this means we have to allocate
EvVars when we want to query the type oracle! So we keep the type oracle
state as `newtype TyState = TySt (Bag EvVar)`, which nicely makes a
distinction between new, unchecked `TyCt`s and the inert set in
`TyState`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #17056 revealed that we were sometimes building a case
expression whose type field (in the Case constructor) was bogus.
Consider a phantom type synonym
type S a = Int
and we want to form the case expression
case x of K (a::*) -> (e :: S a)
We must not make the type field of the Case constructor be (S a)
because 'a' isn't in scope. We must instead expand the synonym.
Changes in this patch:
* Expand synonyms in the new function CoreUtils.mkSingleAltCase.
* Use mkSingleAltCase in MkCore.wrapFloat, which was the proximate
source of the bug (when called by exprIsConApp_maybe)
* Use mkSingleAltCase elsewhere
* Documentation
CoreSyn new invariant (6) in Note [Case expression invariants]
CoreSyn Note [Why does Case have a 'Type' field?]
CoreUtils Note [Care with the type of a case expression]
* I improved Core Lint's error reporting, which was pretty
confusing in this case, because it didn't mention that the offending
type was the return type of a case expression.
* A little bit of cosmetic refactoring in CoreUtils
|
|
|
|
|
|
|
|
| |
PmOracle.addVarCoreCt was giving a bogus (empty) in-scope set to
exprIsConApp_maybe, which resulted in a substitution-invariant
failure (see MR !1647 discussion).
This patch fixes it, by taking the free vars of the expression.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Add GHC.Hs module hierarchy replacing hsSyn.
Metric Increase:
haddock.compiler
|
|
|
|
| |
Fixes #17200.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'withTiming' becomes a function that, when passed '-vN' (N >= 2) or
'-ddump-timings', will print timing (and possibly allocations) related
information. When additionally built with '-eventlog' and executed with
'+RTS -l', 'withTiming' will also emit both 'traceMarker' and 'traceEvent'
events to the eventlog.
'withTimingSilent' on the other hand will never print any timing information,
under any circumstance, and will only emit 'traceEvent' events to the eventlog.
As pointed out in !1672, 'traceMarker' is better suited for things that we
might want to visualize in tools like eventlog2html, while 'traceEvent'
is better suited for internal events that occur a lot more often and that we
don't necessarily want to visualize.
This addresses #17138 by using 'withTimingSilent' for all the codegen bits
that are expressed as a bunch of small computations over streams of codegen
ASTs.
|
| |
|
|
|
|
|
| |
The particular test is already fixed, but the issue seems to have
multiple different test cases lumped together.
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently ghc-lib-parser's API blew up because the newly induced cyclic
dependency between TcRnTypes and PmOracle pulled in the other half of
GHC into the relevant strongly-connected component.
This patch arranges it so that PmTypes exposes mostly data type
definitions and type class instances to be used within PmOracle, without
importing the any of the possibly offending modules DsMonad, TcSimplify
and FamInst.
|
|
|
|
| |
Also add reference from isUnliftedType to mightBeUnliftedType.
|
| |
|
|
|
|
|
|
|
|
| |
This fixes #15809, and is covered in
Note [Use level numbers for quantification] in TcMType.
This patch removes the "global tyvars" from the
environment, a nice little win.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit should have no change in behavior.(*)
The observation was that Note [Recipe for checking a signature]
says that every metavariable in a type-checked type must either
(A) be generalized
(B) be promoted
(C) be zapped.
Yet the code paths for doing these were all somewhat separate.
This led to some steps being skipped. This commit shores this
all up. The key innovation is TcHsType.kindGeneralizeSome, with
appropriate commentary.
This commit also sets the stage for #15809, by turning the
WARNing about bad level-numbers in generalisation into an
ASSERTion. The actual fix for #15809 will be in a separate
commit.
Other changes:
* zonkPromoteType is now replaced by kindGeneralizeNone.
This might have a small performance degradation, because
zonkPromoteType zonked and promoted all at once. The new
code path promotes first, and then zonks.
* A call to kindGeneralizeNone was added in tcHsPartialSigType.
I think this was a lurking bug, because it did not follow
Note [Recipe for checking a signature]. I did not try to
come up with an example showing the bug. This is the (*)
above.
Because of this change, there is an error message regression
in partial-sigs/should_fail/T14040a. This problem isn't really
a direct result of this refactoring, but is a symptom of
something deeper. See #16775, which addresses the deeper
problem.
* I added a short-cut to quantifyTyVars, in case there's
nothing to quantify.
* There was a horribly-outdated Note that wasn't referred
to. Gone now.
* While poking around with T14040a, I discovered a small
mistake in the Coercion.simplifyArgsWorker. Easy to fix,
happily.
* See new Note [Free vars in coercion hole] in TcMType.
Previously, we were doing the wrong thing when looking
at a coercion hole in the gather-candidates algorithm.
Fixed now, with lengthy explanation.
Metric Decrease:
T14683
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In simplCast I totally failed to keep the sc_hole_ty field of
ApplyToTy (see Note [The hole type in ApplyToTy]) up to date.
When a cast goes by, of course the hole type changes.
Amazingly this has not bitten us before, but #16312 finally
triggered it. Fortunately the fix is simple.
Fixes #16312.
|
|
|
|
|
|
|
| |
Until 0472f0f6a92395d478e9644c0dbd12948518099f there was a meaningful
host vs target distinction (though it wasn't used right, in genapply).
After that, they did not differ in meaningful ways, so it's best to just
only keep one.
|
|
|
|
|
|
|
|
|
|
| |
As #13834 and #17150 report, we get a TERRIBLE error message when you
have an out of scope variable applied in a visible type application:
(outOfScope @Int True)
This very simple patch improves matters.
See TcExpr Note [VTA for out-of-scope functions]
|
| |
|
|
|
|
| |
Test case: indexed-types/should_fail/T13571
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new eventlog event which indicates the start of
a biographical profiler sample. These are different to normal events as
they also include the timestamp of when the census took place. This is
because the LDV profiler only emits samples at the end of the run.
Now all the different profiling modes emit consumable events to the
eventlog.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had an elaborate mechanism for selecting the warnings to
generate in the presence of different `COMPLETE` matching groups that,
albeit finely-tuned, produced wrong results from an end user's
perspective in some cases (#13363).
The underlying issue is that at the point where the `ConVar` case has to
commit to a particular `COMPLETE` group, there's not enough information
to do so and the status quo was to just enumerate all possible complete
sets nondeterministically. The `getResult` function would then pick the
outcome according to metrics defined in accordance to the user's guide.
But crucially, it lacked knowledge about the order in which affected
clauses appear, leading to the surprising behavior in #13363.
In !1010 we taught the term oracle to reason about literal values a
variable can certainly not take on. This MR extends that idea to
`ConLike`s and thereby fixes #13363: Instead of committing to a
particular `COMPLETE` group in the `ConVar` case, we now split off the
matching constructor incrementally and record the newly covered case as
a refutable shape in the oracle. Whenever the set of refutable shapes
covers any `COMPLETE` set, the oracle recognises vacuosity of the
uncovered set.
This patch goes a step further: Since at this point the information
in value abstractions is merely a cut down representation of what the
oracle knows, value abstractions degenerate to a single `Id`, the
semantics of which is determined by the oracle state `Delta`.
Value vectors become lists of `[Id]` given meaning to by a single
`Delta`, value set abstractions (of which the uncovered set is an
instance) correspond to a union of `Delta`s which instantiate the
same `[Id]` (akin to models of formula).
Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149
-------------------------
Metric Decrease:
ManyAlternatives
T11195
-------------------------
|
| |
|
|
|
|
| |
Broken by 2b37a79d61e9b3787873dc9f7458ef2bde4809b0
|
|
|
|
|
|
|
|
|
| |
Incredibly, Windows disallows the manipulation of any file matching
Con(\..*)?. The `GHC.StgToCmm.Con` was introduced in the renamings in
447864a9, breaking the Windows build. Work around this by renaming it to
`GHC.StgToCmm.DataCon`
Fixes #17187.
|
| |
|
|
|
|
|
| |
This adds isResourceVanished, resourceVanishedErrorType, and
isResourceVanishedErrorType to System.IO.Error, resolving #14730.
|
| |
|
|
|
|
| |
Fixes #17180.
|
|
|
|
|
| |
07ee15915d5a0d6d1aeee137541eec6e9c153e65 started the transition, but the
job was never finished.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
There was an outright bug in TcInteract.solveOneFromTheOther
which meant that we did not always pick the innermost
implicit parameter binding, causing #17104.
The fix is easy, just a rearrangement of conditional tests
|
| |
|
|
|
|
|
| |
If I understand correctly, `deriving instance _ => Eq (Foo a)`
is equivalent to `data Foo a deriving Eq`, rather than
`data Foo a deriving Foo`.
|
|
|
|
|
|
|
|
| |
-------------------------
Metric Increase:
haddock.Cabal
T4029
-------------------------
|
|
|
|
|
| |
Looks like these have been unused since
7c665f9ce0980ee7c81a44c8f861686395637453.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, there is only one home package so this probably doesn't
matter. But if we support multiple home packages, they could differ only
in arguments (same indef component being applied).
It looks like it used to be this way before
4e8a0607140b23561248a41aeaf837224aa6315b, but that commit doesn't seem
to comment on this change in the particular. (It's main purpose is
creating the InstalledUnitId and recategorizing the UnitId expressions
accordingly.)
Trying this as a separate commit for testing purposes. I leave it to
others to decide whether this is a good change on its own.
|
|
|
|
|
|
|
| |
Use `stats.max_mem_in_use_bytes` to print the memory usage instead of
`stats.max_live_bytes` which prints maximum residency.
Fixes (#17158).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do bad coercion checking in a few places in the compiler, but they
all checked it differently:
- CoreToStg.coreToStgArgs:
Disallowed lifted-to-unlifted, disallowed changing prim reps even when
the sizes are the same.
- StgCmmExpr.cgCase:
Checked primRepSlot equality. This disallowed Int to Int64 coercions
on 64-bit systems (and Int to Int32 on 32-bit) even though those are
fine.
- CoreLint:
Only place where we do this right. Full rules are explained in Note
[Bad unsafe coercion].
This patch implements the check explained in Note [Bad unsafe coercion]
in CoreLint and uses it in CoreToStg.coreToStgArgs and
StgCmmExpr.cgCase.
This fixes #16952 and unblocks !1381 (which fixes #16893).
This is the most conservative and correct change I came up with that
fixes #16952.
One remaining problem with coercion checking is that it's currently done
in seemingly random places. What's special about CoreToStg.coreToStgArgs
and StgCmmExpr.cgCase? My guess is that adding assertions to those
places caught bugs before so we left assertions in those places. I think
we should remove these assertions and do coercion checking in CoreLint
and StgLint only (#17041).
|
|
|
|
|
|
| |
3b31a94d introduced a use of isUnliftedType which can panic in the case
of levity-polymorphic types. Fix this by introducing mightBeUnliftedType
which returns whether the type is *guaranteed* to be lifted.
|