| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple Given quantified constraints match a Wanted, and there is
a quantified constraint that dominates all others, we now pick it
to solve the Wanted.
See Note [Use only the best matching quantified constraint].
For example:
[G] d1: forall a b. ( Eq a, Num b, C a b ) => D a b
[G] d2: forall a . C a Int => D a Int
[W] {w}: D a Int
When solving the Wanted, we find that both Givens match, but we pick
the second, because it has a weaker precondition, C a Int, compared
to (Eq a, Num Int, C a Int). We thus say that d2 dominates d1;
see Note [When does a quantified instance dominate another?].
This domination test is done purely in terms of superclass expansion,
in the function GHC.Tc.Solver.Interact.impliedBySCs. We don't attempt
to do a full round of constraint solving; this simple check suffices
for now.
Fixes #22216 and #22223
|
|
|
|
| |
includes corresponding changes to haddock submodule
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current docs are misleading and suggest that it is possible to use
LLVM codegen from an unregisterised build. This is not the case;
attempting to pass `-fllvm` to an unregisterised build warns:
```
when making flags consistent: warning:
Target platform uses unregisterised ABI, so compiling via C
```
and uses the C codegen anyway.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to an oversight, the initial specification and implementation of
-Woperator-whitespace focused on varsym exclusively and completely
ignored consym.
This meant that expressions such as "x+ y" would produce a warning,
while "x:+ y" would not.
The specification was corrected in ghc-proposals pull request #404,
and this patch updates the implementation accordingly.
Regression test included.
|
| |
|
|
|
|
| |
fixes #22176
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a module `M` exports two fields `f` (using DuplicateRecordFields), we can
still accept
import M (f)
import M hiding (f)
and treat `f` as referencing both of them. This was accepted in GHC 9.0, but gave
rise to an ambiguity error in GHC 9.2. See #21625.
This patch also documents this behaviour in the user's guide, and updates the
test for #16745 which is now treated differently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR adds diagnostic codes, assigning unique numeric codes to
error and warnings, e.g.
error: [GHC-53633]
Pattern match is redundant
This is achieved as follows:
- a type family GhcDiagnosticCode that gives the diagnostic code
for each diagnostic constructor,
- a type family ConRecursInto that specifies whether to recur into
an argument of the constructor to obtain a more fine-grained code
(e.g. different error codes for different 'deriving' errors),
- generics machinery to generate the value-level function assigning
each diagnostic its error code; see Note [Diagnostic codes using generics]
in GHC.Types.Error.Codes.
The upshot is that, to add a new diagnostic code, contributors only need
to modify the two type families mentioned above. All logic relating to
diagnostic codes is thus contained to the GHC.Types.Error.Codes module,
with no code duplication.
This MR also refactors error message datatypes a bit, ensuring we can
derive Generic for them, and cleans up the logic around constraint
solver reports by splitting up 'TcSolverReportInfo' into separate
datatypes (see #20772).
Fixes #21684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements GHC proposal 313, "Delimited continuation
primops", by adding native support for delimited continuations to the
GHC RTS.
All things considered, the patch is relatively small. It almost
exclusively consists of changes to the RTS; the compiler itself is
essentially unaffected. The primops come with fairly extensive Haddock
documentation, and an overview of the implementation strategy is given
in the Notes in rts/Continuation.c.
This first stab at the implementation prioritizes simplicity over
performance. Most notably, every continuation is always stored as a
single, contiguous chunk of stack. If one of these chunks is
particularly large, it can result in poor performance, as the current
implementation does not attempt to cleverly squeeze a subset of the
stack frames into the existing stack: it must fit all at once. If this
proves to be a performance issue in practice, a cleverer strategy would
be a worthwhile target for future improvements.
|
| |
|
|
|
|
| |
Fixes #22103
|
|
|
|
| |
Approved by CLC in https://github.com/haskell/core-libraries-committee/issues/24#issuecomment-1233331267
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Here we at long last remove the `make`-based build system, it having
been replaced with the Shake-based Hadrian build system. Users are
encouraged to refer to the documentation in `hadrian/doc` and this [1]
blog post for details on using Hadrian.
Closes #17527.
[1] https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html
|
| |
|
| |
|
|
|
|
|
|
| |
Previously the wording was a tad unclear. Fix this.
Closes #21114.
|
|
|
|
| |
As noted in #21988, some users rely on this.
|
| |
|
| |
|
|
|
|
| |
Fixes #22052.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new command-line flag:
-fplugin-library=<file-path>;<unit-id>;<module>;<args>
used like this:
-fplugin-library=path/to/plugin.so;package-123;Plugin.Module;["Argument","List"]
It allows a plugin to be loaded directly from a shared library. With
this approach, GHC doesn't compile anything for the plugin and doesn't
load any .hi file for the plugin and its dependencies. As such GHC
doesn't need to support two environments (one for plugins, one for
target code), which was the more ambitious approach tracked in #14335.
Fix #20964
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding a 'Status' field with a few values:
- Deprecated
- Experimental
- InternalUseOnly
- Noting if included in 'GHC2021', 'Haskell2010' or 'Haskell98'
Those values are pulled from the existing descriptions or elsewhere in
the documentation.
While at it, include the :implied by: where appropriate, to provide
more detail.
Fixes #21475
|
|
|
|
|
|
|
|
| |
GHC is happy to parse `(f) x y = x + y` when it should be a parse error
based on the Haskell report. Seems harmless enough so we won't fix it
but it's documented now.
Fixes #19788
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The former behaviour of adding cost centres after optimization but
before unfoldings are created is not available via the flag
`prof-late-inline` instead.
I also reduced the overhead of -fprof-late* by pushing the cost centres
into lambdas. This means the cost centres will only account for
execution of functions and not their partial application.
Further I made LATE_CC cost centres it's own CC flavour so they now
won't clash with user defined ones if a user uses the same string for
a custom scc.
LateCC: Don't put cost centres inside constructor workers.
With -fprof-late they are rarely useful as the worker is usually
inlined. Even if the worker is not inlined or we use -fprof-late-linline
they are generally not helpful but bloat compile and run time
significantly. So we just don't add sccs inside constructor workers.
-------------------------
Metric Decrease:
T13701
-------------------------
|
|
|
|
|
| |
They have been backported to 9.4 in commits 5423d84bd9a28f,
13c81cb6be95c5, 67ccbd6b2d4b9b.
|
|
|
|
| |
Fixes #21950
|
|
|
|
|
| |
Instead of `` `cast` <Co:11> :: (Some -> Really -> Large Type)``
simply print `` `cast` <Co:11> :: ... ``
|
|
|
|
|
|
|
|
|
| |
This patch fixes #21806 by rectifying an incorrect claim about
the usage of kind variables in the header of a data declaration with
a standalone kind signature.
It also adds some clarifications about the number of parameters expected
in GADT declarations and in type family declarations.
|
|
|
|
| |
Fixes #21902.
|
|
|
|
|
|
|
|
|
|
|
| |
GHC doesn't consistently require the ConstraintKinds extension to
be enabled, as it allows programs such as type families returning
a constraint without this extension.
MR !7784 fixes this infelicity, but breaking user programs was deemed
to not be worth it, so we document it instead.
Fixes #21061.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR adds the language extension -XDeepSubsumption, implementing
GHC proposal #511. This change mitigates the impact of GHC proposal
The changes are highly localised, by design. See Note [Deep subsumption]
in GHC.Tc.Utils.Unify.
The main changes are:
* Add -XDeepSubsumption, which is on by default in Haskell98 and Haskell2010,
but off in Haskell2021.
-XDeepSubsumption largely restores the behaviour before the "simple subsumption" change.
-XDeepSubsumpition has a similar flavour as -XNoMonoLocalBinds:
it makes type inference more complicated and less predictable, but it
may be convenient in practice.
* The main changes are in:
* GHC.Tc.Utils.Unify.tcSubType, which does deep susumption and eta-expanansion
* GHC.Tc.Utils.Unify.tcSkolemiseET, which does deep skolemisation
* In GHC.Tc.Gen.App.tcApp we call tcSubTypeNC to match the result
type. Without deep subsumption, unifyExpectedType would be sufficent.
See Note [Deep subsumption] in GHC.Tc.Utils.Unify.
* There are no changes to Quick Look at all.
* The type of `withDict` becomes ambiguous; so add -XAllowAmbiguousTypes to
GHC.Magic.Dict
* I fixed a small but egregious bug in GHC.Core.FVs.varTypeTyCoFVs, where
we'd forgotten to take the free vars of the multiplicity of an Id.
* I also had to fix tcSplitNestedSigmaTys
When I did the shallow-subsumption patch
commit 2b792facab46f7cdd09d12e79499f4e0dcd4293f
Date: Sun Feb 2 18:23:11 2020 +0000
Simple subsumption
I changed tcSplitNestedSigmaTys to not look through function arrows
any more. But that was actually an un-forced change. This function
is used only in
* Improving error messages in GHC.Tc.Gen.Head.addFunResCtxt
* Validity checking for default methods: GHC.Tc.TyCl.checkValidClass
* A couple of calls in the GHCi debugger: GHC.Runtime.Heap.Inspect
All to do with validity checking and error messages. Acutally its
fine to look under function arrows here, and quite useful a test
DeepSubsumption05 (a test motivated by a build failure in the
`lens` package) shows.
The fix is easy. I added Note [tcSplitNestedSigmaTys].
|
|
|
|
| |
Since we have backported the fix to 9.4.1.
|
|
|
|
| |
equivalent to the `runghc` command. Add an entry to the index for `runhaskell`. See https://gitlab.haskell.org/ghc/ghc/-/issues/21411
|
|
|
|
|
|
|
|
|
|
|
| |
We were not updating the [copied,any_work,scav_find_work, max_n_todo_overflow]
counters during sequential collections. As well, we were double counting for
parallel collections.
To fix this we add an `else` clause to the `if (is_par_gc())`.
The par_* counters do not need to be updated in the sequential case
because they must be 0.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-flocal-float-out-top-level CLI flags
These flags affect the behaviour of local let floating.
If `-flocal-float-out` is disabled (the default) then we disable all
local floating.
```
…(let x = let y = e in (a,b) in body)...
===>
…(let y = e; x = (a,b) in body)...
```
Further to this, top-level local floating can be disabled on it's own by
passing -fno-local-float-out-top-level.
```
x = let y = e in (a,b)
===>
y = e; x = (a,b)
```
Note that this is only about local floating, ie, floating two adjacent
lets past each other and doesn't say anything about the global floating
pass which is controlled by `-fno-float`.
Fixes #13663
|
|
|
|
|
|
|
|
|
| |
Previously we could construct a `Box` of a NULL pointer from the `link`
field of `StgWeak`. Now we take care to avoid ever introducing such
pointers in `collect_pointers` and ensure that the `link` field is
represented as a `Maybe` in the `Closure` type.
Fixes #21622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes #20312
It deprecates "TypeInType" extension
according to the following proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0083-no-type-in-type.rst
It has been already implemented.
The migration strategy:
1. Disable TypeInType
2. Enable both DataKinds and PolyKinds extensions
Metric Decrease:
T16875
|
|
|
|
|
|
|
|
| |
This is a follow-up to !7247 (closed) making the inclusion of compact unwinding
sections the default.
Also a slight refactoring/simplification of the flag handling to add
-fno-compact-unwind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This introduces a global hook which is called when an exception is
thrown during finalization.
|