| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
As noted in #20327, the previous guidance was out-of-date.
|
| |
|
|
| |
As noted in #17568.
|
| |
|
|
|
|
| |
Previously the Darwin installation logic would attempt to call xattr
unconditionally. This would break on older Darwin releases where this
utility did not exist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch follows the rules specified in note [Constant folding through
nested expressions]. Modifications are summarized below.
- Added andFoldingRules, orFoldingRules to primOpRules under those
xxxxAndOp, xxxxOrOp
- Refactored some helper functions
- Modify data NumOps to include two fields: numAnd and numOr
Resolves: #20203
See also: #19204
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Judging from the Assumption, we should never call `roundingMode#` on a negative
number. Yet the strange "dummy" conversion from `IN` to `IP` and the following
recursive call where making the function recursive.
Replacing the call by a panic makes `roundingMode#` non-recursive, so that we
may be able to inline it.
Fixes #20352.
It seems we trigger #19414 on some jobs, hence
Metric Decrease:
T12545
|
| |
|
|
|
|
| |
As noted in #18183, these cases were previously incorrect and unused.
Closes #18183.
|
| |
|
|
|
| |
As noted in #20324, previously we would drop the fact that an unfolding
was evaluated, despite what the documentation claims.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch Integer and Natural literals were desugared into "real"
Core in Core prep. Now we desugar them directly into their final ConApp
form in HsToCore. We only keep the double representation for BigNat#
(literals larger than a machine Word/Int) which are still desugared in
Core prep.
Using the final form directly allows case-of-known-constructor to fire
for bignum literals, fixing #20245.
Slight increase (+2.3) in T4801 which is a pathological case with
Integer literals.
Metric Increase:
T4801
T11545
|
| |
|
|
|
| |
None of the configure options defined by `FP_GMP` are applicable to
binary distributions.
|
| | |
|
| |
|
|
|
|
|
| |
The location of the plus symbol was being discarded, we now capture
it.
Closes #20243
|
| |
|
|
| |
Just a small refactoring to perhaps enable code reuse later.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- Fix markup in 9.4 release notes
- Document -ddump-cs-trace
- Mention that ImpredicativeTypes is really supported only since 9.2
- Remove "There are some restrictions on the use of unboxed tuples".
This used to be a list, but all those restrictions were removed.
- Mark -fimplicit-import-qualified as documented
- Remove "The :main and :run command" - duplicated verbatim in options
- Avoid calling "main" a function (cf. #7816)
- Update System.getArgs: the old location was before hierarchical modules
- Note that multiplicity multiplication is not supported (#20319)
|
| |
|
|
| |
Fixes #20272
|
| |
|
|
|
|
|
|
|
|
| |
The constraint was there in order to show the 'Integral' value in case
of error. Instead we can show the result of `toInteger`, which will be
close (i.e. it will still show the same integer except if the 'Show'
instance was funky).
This changes a bit runtime semantic (i.e. exception string may be a bit
different).
|
| | |
|
| |
|
| |
ie `succ (0000) == 0001` -- (not 1001)
|
| |
|
|
|
|
| |
NCG needs to call slow FFI functions where we "borrow" the C compiler's
implementation, but there is no reason why we need to do that for LLVM,
or the unregisterized backend where everything is via C anyways!
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the following constructors to the TcRnMessage type and
uses them to replace sdoc-based diagnostics in some parts of GHC (e.g.
TcRnUnknownMessage). It includes:
* Add TcRnMonomorphicBindings diagnostic
* Convert TcRnUnknownMessage in Tc.Solver.Interact
* Add and use the TcRnOrphanInstance constructor to TcRnMessage
* Add TcRnFunDepConflict and TcRnDupInstanceDecls constructors to TcRnMessage
* Add and use TcRnConflictingFamInstDecls constructor to TcRnMessage
* Get rid of TcRnUnknownMessage from GHC.Tc.Instance.Family
|
| |
|
|
|
|
| |
As described in https://stackoverflow.com/questions/7577052,
safely expanding bash arrays is very-nearly impossible. The previous
incantation failed under the bash version shipped with Centos 7.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously Hadrian would simply install the settings file generated in
the build environment during the binary distribution installation. This
is wrong since these environments may differ (e.g. different `cc`
versions).
We noticed on Darwin when installation of a binary distribution produced
on a newer Darwin release resulted in a broken compiler due to the
installed `settings` file incorrectly claiming that `cc` supported
`-no-pie`.
Fixing this sadly requires a bit of code duplication since `settings` is
produced by Hadrian and not `configure`. For now I have simply
duplicated the `settings` generation logic used by the Make build system
into Hadrian's bindist Makefile.
Ultimately the solution will probably involve shipping a freestanding
utility to replace `configure`'s toolchain probing logic and generate a
toolchain description file (similar to `settings`) as described
in #19877.
Fixes #20253.
|
| |
|
|
|
|
|
|
| |
* make "passthrough" rules non built-in: they don't need to
* enhance note about efficient conversions between numeric types
* make integerFromNatural a little more efficient
* fix noinline pragma for naturalToWordClamp# (at least with non
built-in rules, we get warnings in cases like this)
|
| |
|
|
| |
Fix regression introduced in ecfd0278
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
A comment followed by a semicolon at the top level resulted in the
preceding comments being attached to the following declaration.
Capture the comments as belonging to the declaration preceding the
semicolon instead.
Closes #20258
|
| |
|
|
|
|
|
|
| |
Starting with commit fe770c21, an error was thrown only for the values
2^63 to 2^64-1 inclusive (on a 64-bit machine), but not for higher
values. Now, errors are thrown for all non-representable values again.
Fixes #20291
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| | |
|
| |
|
|
| |
Closes #20275
|
| |
|
|
|
|
| |
Converts uses of TcRnUnknownMessage in GHC.Iface.Rename.
Closes #19927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* The `Solo` type is intended to be the canonical lifted
unary tuple. Up until now, it has only been available from
`GHC.Tuple` in `ghc-prim`. Export it from `Data.Tuple` in
`base`.
I proposed this on the libraries list in December, 2020.
https://mail.haskell.org/pipermail/libraries/2020-December/031061.html
Responses from chessai
https://mail.haskell.org/pipermail/libraries/2020-December/031062.html
and George Wilson
https://mail.haskell.org/pipermail/libraries/2021-January/031077.html
were positive. There were no other responses.
* Add Haddock documentation for Solo.
* Give `Solo` a single field, `getSolo`, a custom `Show` instance that
does *not* use record syntax, and a `Read` instance that accepts
either record syntax or non-record syntax.
|
| |
|
|
|
|
|
|
| |
Converts uses of `TcRnUnknownMessage` in these modules:
- compiler/GHC/Tc/Gen/Annotation.hs
- compiler/GHC/Tc/Gen/App.hs
- compiler/GHC/Tc/Gen/Arrow.hs
- compiler/GHC/Tc/Gen/Bind.hs
|
| |
|
|
|
|
|
| |
substDVarSet looked up coercion variables in the wrong environment!
The fix is easy. It is still a pretty strange looking function, but
the bug is gone. This fixes another manifestation of #20200.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #20283, we saw a regression in `simple` due to CallArity for a very subtle
reason: It simply didn't handle shadowing of case binders and constructor field
binders!
The test case T20283 has a very interesting binding `n_X1` that we want to
eta-expand and that has a Unique (on GHC HEAD) that is reused by the Simplifier
for a case binder:
```
let { n_X1 = ... } in
...
let {
lvl_s1Ul
= ... case x_a1Rg of wild_X1 {
__DEFAULT -> f_s1Tx rho_value_awA (GHC.Types.I# wild_X1);
0# -> lvl_s1TN
} ...
} in
letrec {
go3_X3
= \ (x_X4 :: GHC.Prim.Int#) (v_a1P9 [OS=OneShot] :: Double) ->
let {
karg_s1Wu = ...
case lvl_s1Ul of { GHC.Types.D# y_a1Qf ->
...
} } in
case GHC.Prim.==# x_X4 y_a1R7 of {
__DEFAULT -> go3_X3 (GHC.Prim.+# x_X4 1#) karg_s1Wu;
1# -> n_X1 karg_s1Wu -- Here we will assume that karg calls n_X1!
}; } in
go3_X3 0#;
```
Since the Case case of CallArity doesn't delete `X1` from the set of variables
it is interested in knowing the usages of, we leak a very boring usage (of the
case binder!) into the co-call graph that we mistakenly take for a usage of
`n_X1`. We conclude that `lvl_s1Ul` and transitively `karg_s1Wu` call `n_X1`
when really they don't. That culminates in the conclusion that `n_X1 karg_s1Wu`
calls `n_X1` more than once. Wrong!
Fortunately, this bug (which has been there right from CallArity's inception,
I suppose) will never lead to a CallArity that is too optimistic. So by fixing
this bug, we get strictly more opportunities for CallArity and all of them
should be sound to exploit.
Fixes #20283.
|
| |
|
|
|
|
|
|
|
|
| |
This fixes an outright bug in which the desugarer did not bring the
existentially quantified type variables of a record GADT into `in_subst`'s
in-scope set, leading to #20278. It also addresses a minor inefficiency in
which `out_subst` was made into a substitution when a simpler `TvSubstEnv`
would suffice.
Fixes #20278.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a small mistake in 4dc681c7c0345ee8ae268749d98b419dabf6a3bc
which forced the dump rather than user style for error messages.
In particular, this change replaced `defaultUserStyle` with
`log_default_dump_context` rather than `log_default_user_context` which
meant the PprStyle was PprDump rather than PprUser for error messages.
https://gitlab.haskell.org/ghc/ghc/-/commit/4dc681c7c0345ee8ae268749d98b419dabf6a3bc?expanded=1&page=4#b62120081f64009b94c12d04ded5c68870d8c647_285_405
Fixes #20276
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For some inexplicable reason `-P` only takes effect on the mac version
of p when you also pass `-R`.
> Symbolic links are always followed unless the -R flag is set, in which case symbolic
> links are not followed, by default.
> -P If the -R option is specified, no symbolic links are followed. This is the
> default.
Fixes #20254
|
| |
|
|
|
|
| |
This test tests that if there are two modules which use a plugin
specified on the command line then both are recompiled when the plugin
changes.
|
| |
|
|
|
|
|
| |
This fixes an error message regression and is a slight performance
improvement.
See #20250
|
| |
|
|
| |
This was an oversight from !6718
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This changes the TcPlugin datatype to allow type-checking plugins
to report insoluble constraints while at the same time solve
some other constraints. This allows better error messages, as
the plugin can still simplify constraints, even when it wishes
to report a contradiction.
Pattern synonyms TcPluginContradiction and TcPluginOk are provided
for backwards compatibility: existing type-checking plugins should
continue to work without modification.
|
| |
|
|
| |
RST is brittle...
|
| | |
|
