| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This MR is in response to the discussion on #22719
|
|
|
|
|
|
|
|
| |
When performing GC without work stealing there was no guarantee that
spark pruning was happening after marking of the sparks. This could
cause us to GC live sparks under certain circumstances.
Fixes #22528.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch completely re-engineers how we deal with loopy superclass
dictionaries in instance declarations. It fixes #20666 and #19690
The highlights are
* Recognise that the loopy-superclass business should use precisely
the Paterson conditions. This is much much nicer. See
Note [Recursive superclasses] in GHC.Tc.TyCl.Instance
* With that in mind, define "Paterson-smaller" in
Note [Paterson conditions] in GHC.Tc.Validity, and the new
data type `PatersonSize` in GHC.Tc.Utils.TcType, along with
functions to compute and compare PatsonSizes
* Use the new PatersonSize stuff when solving superclass constraints
See Note [Solving superclass constraints] in GHC.Tc.TyCl.Instance
* In GHC.Tc.Solver.Monad.lookupInInerts, add a missing call to
prohibitedSuperClassSolve. This was the original cause of #20666.
* Treat (TypeError "stuff") as having PatersonSize zero. See
Note [Paterson size for type family applications] in GHC.Tc.Utils.TcType.
* Treat the head of a Wanted quantified constraint in the same way
as the superclass of an instance decl; this is what fixes #19690.
See GHC.Tc.Solver.Canonical Note [Solving a Wanted forall-constraint]
(Thanks to Matthew Craven for this insight.)
This entailed refactoring the GivenSc constructor of CtOrigin a bit,
to say whether it comes from an instance decl or quantified constraint.
* Some refactoring way in which redundant constraints are reported; we
don't want to complain about the extra, apparently-redundant
constraints that we must add to an instance decl because of the
loopy-superclass thing. I moved some work from GHC.Tc.Errors to
GHC.Tc.Solver.
* Add a new section to the user manual to describe the loopy
superclass issue and what rules it follows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposals #448 "Modern scoped type variables"
and #425 "Invisible binders in type declarations"
introduce a new language extension flag: TypeAbstractions.
Part of the functionality guarded by this flag has already been
implemented, namely type abstractions in constructor patterns, but it
was guarded by a combination of TypeApplications and ScopedTypeVariables
instead of a dedicated language extension flag.
This patch does the following:
* introduces a new language extension flag TypeAbstractions
* requires TypeAbstractions for @a-syntax in constructor patterns
instead of TypeApplications and ScopedTypeVariables
* creates a User's Guide page for TypeAbstractions and
moves the "Type Applications in Patterns" section there
To avoid a breaking change, the new flag is implied by
ScopedTypeVariables and is retroactively added to GHC2021.
Metric Decrease:
MultiLayerModulesTH_OneShot
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new warning
that indicates code incompatible with
future extension: RequiredTypeArguments.
Enabling this extension may break some code and the warning
will help to make it compatible in advance.
|
|
|
|
|
|
|
|
|
| |
- Remove unused uniques and hs-boot declarations
- Fix types of seq and unsafeCoerce#
- Remove FastString/String roundtrip in JS
- Use TTG to enforce totality
- Remove enumeration in Heap/Inspect; the 'otherwise' clause
serves the primitive types well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the following build error:
```
Command line: /opt/homebrew/opt/sphinx-doc/bin/sphinx-build -b man -d /private/tmp/extra-dir-55768274273/.doctrees-man -n -w /private/tmp/extra-dir-55768274273/.log docs/users_guide /private/tmp/extra-dir-55768274273
===> Command failed with error code: 2
Exception occurred:
File "/opt/homebrew/Cellar/sphinx-doc/6.0.0/libexec/lib/python3.11/site-packages/sphinx/ext/extlinks.py", line 101, in role
title = caption % part
~~~~~~~~^~~~~~
TypeError: not all arguments converted during string formatting
```
I tested on Sphinx-5.1.1 and Sphinx-6.0.0
Thanks for sterni for providing instructions about how to test using
sphinx-6.0.0.
Fixes #22690
|
|
|
|
|
|
|
|
| |
Here we add a `-fsplit-sections` flag which may some day replace
`-split-sections`. This has the advantage of automatically providing a
`-fno-split-sections` flag, which is useful for our packaging because we
enable `-split-sections` by default but want to disable it in certain
configurations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements proposal 547 and closes ticket #22298.
See the proposal and ticket for motivation.
Compiler perf improves a bit
Metrics: compile_time/bytes allocated
-------------------------------------
CoOpt_Singletons(normal) -2.4% GOOD
T12545(normal) +1.0%
T13035(normal) -13.5% GOOD
T18478(normal) +0.9%
T9872d(normal) -2.2% GOOD
geo. mean -0.2%
minimum -13.5%
maximum +1.0%
Metric Decrease:
CoOpt_Singletons
T13035
T9872d
|
|
|
|
|
|
| |
This introduces a new Cmm pass which instruments the program with
ThreadSanitizer annotations, allowing full tracking of mutator memory
accesses via TSAN.
|
| |
|
|
|
|
|
|
|
|
|
| |
Top-level declaration splices can having surprising interactions with
`INCOHERENT` instances, as observed in #22492. This patch
resolves #22492 by documenting this strange interaction in the GHC User's
Guide.
[ci skip]
|
|
|
|
|
|
|
| |
Unboxed sums might store a Int8# value as Int64#. This patch
makes sure we keep track of the actual value type.
See Note [Casting slot arguments] for the details.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add JS backend adapted from the GHCJS project by Luite Stegeman.
Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.
Bump array submodule
Work funded by IOG.
Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, GHC unconditionally printed ticks before promoted
data constructors:
ghci> type T = True -- unticked (user-written)
ghci> :kind! T
T :: Bool
= 'True -- ticked (compiler output)
After this patch, GHC prints ticks only when necessary:
ghci> type F = False -- unticked (user-written)
ghci> :kind! F
F :: Bool
= False -- unticked (compiler output)
ghci> data False -- introduce ambiguity
ghci> :kind! F
F :: Bool
= 'False -- ticked by necessity (compiler output)
The old behavior can be enabled by -fprint-redundant-promotion-ticks.
Summary of changes:
* Rename PrintUnqualified to NamePprCtx
* Add QueryPromotionTick to it
* Consult the GlobalRdrEnv to decide whether to print a tick (see mkPromTick)
* Introduce -fprint-redundant-promotion-ticks
Co-authored-by: Artyom Kuznetsov <hi@wzrd.ht>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when using `capi` calling convention in foreign declarations,
code generator failed to handle const-cualified pointer return types.
This resulted in CC toolchain throwing `-Wincompatible-pointer-types-discards-qualifiers`
warning.
`Foreign.C.Types.ConstPtr` newtype was introduced to handle these cases -
special treatment was put in place to generate appropritetly qualified C
wrapper that no longer triggers the above mentioned warning.
Fixes #22043
|
|
|
|
| |
Specifically, custom Prelude modules that are named `Prelude`.
|
|
|
|
|
|
|
| |
* Replace catMaybes . map f with mapMaybe f
* Use concatFS to concatenate multiple FastStrings
* Fix documentation of -exclude-module
* Cleanup getIgnoreCount in GHCi.UI
|
|
|
|
|
|
|
| |
This is based on osa's unpack_sums PR from ages past.
The meat of the patch is implemented in dataConArgUnpackSum
and described in Note [UNPACK for sum types].
|
| |
|
| |
|
|
|
|
|
|
|
| |
Quoting a name for Template Haskell is a bit tricky if the second
character of that name is a single quote. The User's Guide falsely
claimed that it was impossible. Document how to do it.
Fixes #22236
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In many development environments, the source span is the primary means
of seeing what an error message relates to, and the In the expression:
and In an equation for: clauses are not particularly relevant. However,
they can grow to be quite long, which can make the message itself both
feel overwhelming and interact badly with limited-space areas.
It's simple to implement this flag so we might as well do it and give
the user control about how they see their messages.
Fixes #21722
|
| |
|
|
|
|
|
|
|
|
| |
These predicates use the standard Unicode case properties and are more intuitive than isUpper and isLower.
Approved by CLC in https://github.com/haskell/core-libraries-committee/issues/90#issuecomment-1276649403.
Fixes #14589
|
|
|
| |
(the name of the original source file is $1, not $2)
|
|
|
|
|
| |
Implements GHC proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-unrestricted-overloadedlabels.rst
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch teachs the code generation logic of -fno-code about
-fprefer-byte-code, so that if we need to generate code for a module
which prefers byte code, then we generate byte code rather than object
code.
We keep track separately which modules need object code and which byte
code and then enable the relevant code generation for each. Typically
the option will be enabled globally so one of these sets should be empty
and we will just turn on byte code or object code generation.
We also fix the bug where we would generate code for a module which
enables Template Haskell despite the fact it was unecessary.
Fixes #22016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds three new flags
* -fwrite-if-simplified-core: Writes the whole core program into an interface
file
* -fbyte-code-and-object-code: Generate both byte code and object code
when compiling a file
* -fprefer-byte-code: Prefer to use byte-code if it's available when
running TH splices.
The goal for including the core bindings in an interface file is to be able to restart the compiler pipeline
at the point just after simplification and before code generation. Once compilation is
restarted then code can be created for the byte code backend.
This can significantly speed up
start-times for projects in GHCi. HLS already implements its own version of these extended interface
files for this reason.
Preferring to use byte-code means that we can avoid some potentially
expensive code generation steps (see #21700)
* Producing object code is much slower than producing bytecode, and normally you
need to compile with `-dynamic-too` to produce code in the static and dynamic way, the
dynamic way just for Template Haskell execution when using a dynamically linked compiler.
* Linking many large object files, which happens once per splice, can be quite
expensive compared to linking bytecode.
And you can get GHC to compile the necessary byte code so
`-fprefer-byte-code` has access to it by using
`-fbyte-code-and-object-code`.
Fixes #21067
|
|
|
|
|
| |
- Fix changelog for Unicode 15.0.0
- Fix the checksums of the downloaded Unicode files, in base's tool: "ucd2haskell".
|
| |
|
|
|
|
|
|
|
|
| |
Justification in #22231. Short form: In a demand like `1C1(C1(L))`
it was too easy to confuse which `1` belongs to which `C`. Now
that should be more obvious.
Fixes #22231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|