| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
fixes #17126, updates containers submodule
|
| |
|
|
|
|
|
|
|
|
| |
There's no `errorWithCallStack`, only `errorWithStackTrace`, but the latter is
now deprecated, since `error` now defaults to returning a stack strace.
So rather than change this to the intended deprecated function we replace
`errorWithCallStack` with `error` instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove fstName, sndName, fstIdKey, sndIdKey - no longer used,
removed from basicKnownKeyNames
- Remove breakpointId, breakpointCondId, opaqueTyCon, unknownTyCon -
they were used in the old implementation of the GHCi debugger
- Fix typos in comments
- Remove outdated comment in Lint.hs
- Use 'LitRubbish' instead of 'RubbishLit' for consistency
- Remove comment about subkinding - superseded by
Note [Kind Constraint and kind Type]
- Mention ticket ID in a linear types error message
- Fix formatting in using-warnings.rst and linear-types.rst
- Remove comment about 'Any' in Dynamic.hs - Dynamic
now uses Typeable + existential instead of Any
- Remove codeGen/should_compile/T13233.hs
This was added by accident, it is not used and T13233 is already in
should_fail
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The specification is now simple
* On linux, use `-Xlinker -rpath -Xlinker` to set the rpath of the
executable
* On darwin, never use `-Xlinker -rpath -Xlinker`, always inject
the rpath afterwards, see `runInjectRPaths`.
* If `-fno-use-rpaths` is passed then *never* inject anything into the
rpath.
Fixes #20004
|
|
|
|
|
| |
Also document deprecation of Wnoncanonical-monadfail-instances
and -Wimplicit-kind-vars
|
| |
|
|
|
|
| |
fixes #19756, updates haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`GHC.Hs.Syn.Type`
The existing `hsPatType`, `hsLPatType` and `hsLitType` functions have also been
moved to this module
This is a less ambitious take on the same problem that !2182 and !3866
attempt to solve. Rather than have the `hsExprType` function attempt to
efficiently compute the `Type` of every subexpression in an `HsExpr`, this
simply computes the overall `Type` of a single `HsExpr`.
- Explicitly forbids the `SplicePat` `HsIPVar`, `HsBracket`, `HsRnBracketOut`
and `HsTcBracketOut` constructors during the typechecking phase by using
`Void` as the TTG extension field
- Also introduces `dataConCantHappen` as a domain specific alternative to `absurd`
to handle cases where the TTG extension points forbid a constructor.
- Turns HIE file generation into a pure function that doesn't need access to the
`DsM` monad to compute types, but uses `hsExprType` instead.
- Computes a few more types during HIE file generation
- Makes GHCi's `:set +c` command also use `hsExprType` instead of going through
the desugarer to compute types.
Updates haddock submodule
Co-authored-by: Zubin Duggal <zubin.duggal@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fixes #17817
|
|
|
|
|
| |
This patch adds OverloadedRecordDot and OverloadedRecordUpdate in
9.2.1's release note.
|
|
|
|
|
|
|
|
| |
The flag is called `-Wprepositive-qualified-module`, not
`-Wprepositive-qualified-syntax`.
Use the `:ghc-flag:` syntax, which would have caught the mistake in the first
place.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After !4741, it was no longer possible to silence a warning about a missing
pattern synonym signature if the `-Wmissing-signatures` flag was on.
Restore the previous semantics while still adhering to the principle "enabling
an additional warning flag should never make prior warnings disappear".
For more symmetry and granularity, introduce
`-Wmissing-exported-pattern-synonym-signatures`.
See Note [Missing signatures] for an overview of all flags involved.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the common case this is a straight performance win
at a compile time cost so we enable it at -O2.
In rare cases it can lead to compile time regressions
because of changed inlining behaviour. Which can very
rarely also affect runtime performance.
Increasing the inlining threshold can help to avoid this
which is documented in the user guide.
In terms of measured results this reduced instructions executed
for nofib by 1%.
However for some cases (e.g. Cabal) enabling this
by default increases compile time by 2-3% so we enable it only
at -O2 where it's clear that a user is willing to trade compile
time for runtime.
Most of the testsuite runs without -O2 so there are few
perf changes.
Increases:
T12545/T18698: We perform more WW work because dicts are now treated strict.
T9198: Also some more work because functions are now subject to W/W
Decreases:
T14697: Compiling empty modules. Probably because of changes inside ghc.
T9203: I can't reproduce this improvement locally. Might be spurious.
-------------------------
Metric Decrease:
T12227
T14697
T9203
Metric Increase:
T9198
T12545
T18698a
T18698b
-------------------------
|
|
|
|
|
|
| |
This is part of #18738
[skip ci]
|
|
|
|
| |
(cherry picked from commit d22e087f7bf74341c4468f11b4eb0273033ca931)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives a more precise type signature to `magicDict` as proposed in #16646.
In addition, this replaces the constant-folding rule for `magicDict` in
`GHC.Core.Opt.ConstantFold` with a special case in the desugarer in
`GHC.HsToCore.Expr.dsHsWrapped`. I have also renamed `magicDict` to `withDict`
in light of the discussion in
https://mail.haskell.org/pipermail/ghc-devs/2021-April/019833.html.
All of this has the following benefits:
* `withDict` is now more type safe than before. Moreover, if a user applies
`withDict` at an incorrect type, the special-casing in `dsHsWrapped` will
now throw an error message indicating what the user did incorrectly.
* `withDict` can now work with classes that have multiple type arguments, such
as `Typeable @k a`. This means that `Data.Typeable.Internal.withTypeable` can
now be implemented in terms of `withDict`.
* Since the special-casing for `withDict` no longer needs to match on the
structure of the expression passed as an argument to `withDict`, it no
longer cares about the presence or absence of `Tick`s. In effect, this
obsoletes the fix for #19667.
The new `T16646` test case demonstrates the new version of `withDict` in
action, both in terms of `base` functions defined in terms of `withDict`
as well as in terms of functions from the `reflection` and `singletons`
libraries. The `T16646Fail` test case demonstrates the error message that GHC
throws when `withDict` is applied incorrectly.
This fixes #16646. By adding more tests for `withDict`, this also
fixes #19673 as a side effect.
|
|
|
|
| |
runtime representations
|
|
|
|
|
|
|
|
| |
Previously -ddump-inlinings and -dverbose-core2core used in conjunction
would have the side-effect of dumping additional information about all
inlinings considered by the simplifier. However, I have sometimes wanted
this inlining information without the firehose of information produced by
-dverbose-core2core. Introduce a new dump flag for this purpose.
|
| |
|
| |
|
|
|
|
| |
See #15304.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Point out that GHC2021 doesn't offer the same degree of stability that
Haskell2010 does, as noted by @phadej.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since d880d6b2e48268f5ed4d3eb751fe24cc833e9221 the parsing of the
environment files was moved to `parseDynamicFlags`, under the assumption
it was typically only called once. It turns out not to be true in GHCi
and this led to continually reparsing the environment file whenever a
new option was set, the options were appended to the package state and
hence all packages reloaded, as it looked like the options were changed.
The simplest fix seems to be a clearer specification:
> Package environment files are only loaded in GHCi during initialisation.
Fixes #19650
|
|
|
|
| |
Also includes small unrelated type fix
|
|
|
|
|
| |
This allows Other Numbers to be used in identifiers, and also documents
other, already existing lexer divergence from Haskell Report
|
|
|
|
|
|
|
| |
- Remove GHC.OldList
- Remove Data.OldList
- compat-unqualified-imports is no-op
- update haddock submodule
|
|
|
|
|
|
| |
This patch corrects some markdown.
[skip ci]
|
|
|
|
|
|
|
|
|
| |
This drops allocateExec for darwin, and replaces it with
a alloc, write, mark executable strategy instead. This prevents
us from trying to allocate an executable range and then write to
it, which X^W will prohibit on darwin.
This will *only* work if we can use mmap.
|
|
|
|
| |
Fixes #19564
|
| |
|
|
|
|
|
| |
Co-authored-by: Daniel Rogozin <daniel.rogozin@serokell.io>
Co-authored-by: Rinat Stryungis <rinat.stryungis@serokell.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds some bullet points to the GHC User's Guide section on `GADTs` to
explain some subtleties in how GHC typechecks GADT patterns. In particular,
this adds examples of programs being rejected for matching on GADTs in a way
that does not mesh with GHC's left-to-right, outside-in order for checking
patterns, which can result in programs being rejected for seemingly
counterintuitive reasons. (See #12018 for examples of confusion that arose
from this.) In addition, now that we have visible type application in data
constructor patterns, I mention a possible workaround of using
`TypeApplications` to repair programs of this sort.
Resolves #12018.
|
|
|
|
|
|
|
|
|
| |
StandaloneKindSignatures
This documents a limitation of `StandaloneKindSignatures`—namely, that it
does not bring type variables bound by an outermost `forall` into scope over
a type-level declaration—in the GHC User's Guide. See #19498 for more
discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal: 0265-unlifted-datatypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265
Issues: https://gitlab.haskell.org/ghc/ghc/-/issues/19523
Implementation Details: Note [Implementation of UnliftedDatatypes]
This patch introduces the `UnliftedDatatypes` extension. When this extension is
enabled, GHC relaxes the restrictions around what result kinds are allowed in
data declarations. This allows data types for which an unlifted or
levity-polymorphic result kind is inferred.
The most significant changes are in `GHC.Tc.TyCl`, where
`Note [Implementation of UnliftedDatatypes]` describes the details of the
implementation.
Fixes #19523.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Implement new debugger command `:ignore` to set an `ignore count`
for a specified breakpoint.
* Allow new optional parameter on `:continue` command to set an
`ignore count` for the current breakpoint.
* In the Interpreter replace the current `Word8` BreakArray with
an `Int` array.
* Change semantics of values in `BreakArray` to:
n < 0 : Breakpoint is disabled.
n == 0 : Breakpoint is enabled.
n > 0 : Breakpoint is enabled, but ignore next `n` iterations.
* Rewrite `:enable`/`:disable` processing as a special case of `:ignore`.
* Remove references to `BreakArray` from `ghc/UI.hs`.
|
| |
|
|
|
|
|
|
| |
This adds support for -XGHC2021, as described in Proposal 0380 [1].
[1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two new methods to the Quasi class, putDoc and getDoc. They
allow Haddock documentation to be added to declarations, module headers,
function arguments and class/type family instances, as well as looked
up.
It works by building up a map of names to attach pieces of
documentation to, which are then added in the extractDocs function in
GHC.HsToCore.Docs. However because these template haskell names need to
be resolved to GHC names at the time they are added, putDoc cannot
directly add documentation to declarations that are currently being
spliced. To remedy this, withDecDoc/withDecsDoc wraps the operation with
addModFinalizer, and provides a more ergonomic interface for doing so.
Similarly, the funD_doc, dataD_doc etc. combinators provide a more
ergonomic interface for documenting functions and their arguments
simultaneously.
This also changes ArgDocMap to use an IntMap rather than an Map Int, for
efficiency.
Part of the work towards #5467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related to #19381 #19359 #14702
After a spike in memory usage we have been conservative about returning
allocated blocks to the OS in case we are still allocating a lot and would
end up just reallocating them. The result of this was that up to 4 * live_bytes
of blocks would be retained once they were allocated even if memory usage ended up
a lot lower.
For a heap of size ~1.5G, this would result in OS memory reporting 6G which is
both misleading and worrying for users.
In long-lived server applications this results in consistent high memory
usage when the live data size is much more reasonable (for example ghcide)
Therefore we have a new (2021) strategy which starts by retaining up to 4 * live_bytes
of blocks before gradually returning uneeded memory back to the OS on subsequent
major GCs which are NOT caused by a heap overflow.
Each major GC which is NOT caused by heap overflow increases the consec_idle_gcs
counter and the amount of memory which is retained is inversely proportional to this number.
By default the excess memory retained is
oldGenFactor (controlled by -F) / 2 ^ (consec_idle_gcs * returnDecayFactor)
On a major GC caused by a heap overflow, the `consec_idle_gcs` variable is reset to 0
(as we could continue to allocate more, so retaining all the memory might make sense).
Therefore setting bigger values for `-Fd` makes the rate at which memory is returned slower.
Smaller values make it get returned faster. Setting `-Fd0` disables the
memory return completely, which is the behaviour of older GHC versions.
The default is `-Fd4` which results in the following scaling:
> mapM print [(x, 1/ (2**(x / 4))) | x <- [1 :: Double ..20]]
(1.0,0.8408964152537146)
(2.0,0.7071067811865475)
(3.0,0.5946035575013605)
(4.0,0.5)
(5.0,0.4204482076268573)
(6.0,0.35355339059327373)
(7.0,0.29730177875068026)
(8.0,0.25)
(9.0,0.21022410381342865)
(10.0,0.17677669529663687)
(11.0,0.14865088937534013)
(12.0,0.125)
(13.0,0.10511205190671433)
(14.0,8.838834764831843e-2)
(15.0,7.432544468767006e-2)
(16.0,6.25e-2)
(17.0,5.255602595335716e-2)
(18.0,4.4194173824159216e-2)
(19.0,3.716272234383503e-2)
(20.0,3.125e-2)
So after 13 consecutive GCs only 0.1 of the maximum memory used will be retained.
Further to this decay factor, the amount of memory we attempt to retain is
also influenced by the GC strategy for the oldest generation. If we are using
a copying strategy then we will need at least 2 * live_bytes for copying to take
place, so we always keep that much. If using compacting or nonmoving then we need a lower number,
so we just retain at least `1.2 * live_bytes` for some protection.
In future we might want to make this behaviour more aggressive, some
relevant literature is
> Ulan Degenbaev, Jochen Eisinger, Manfred Ernst, Ross McIlroy, and Hannes Payer. 2016. Idle time garbage collection scheduling. SIGPLAN Not. 51, 6 (June 2016), 570–583. DOI:https://doi.org/10.1145/2980983.2908106
which describes the "memory reducer" in the V8 javascript engine which
on an idle collection immediately returns as much memory as possible.
|
|
|
|
|
|
| |
This resolves #19457 by making a note of breaking changes (introduced in
GHC 9.2) to the way that GHC typechecks operator sections where the operator
has nested `forall`s or contexts in its type signature.
|