| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
This patch does a few things:
- Always build 64-bit atomic ops in rts/ghc-prim, even on 32-bit
platforms
- Remove legacy "64bit" cabal flag of rts package
- Fix hs_xchg64 function prototype for 32-bit platforms
- Fix AtomicFetch test for wasm32
|
|
|
|
|
|
|
|
| |
Previously we would cast pointers to uint64_t. However, implementations
are allowed to either zero- or sign-extend such casts. Instead cast to
uintptr_t to avoid this.
Fixes #23247.
|
|
|
|
| |
Using req_c is more precise.
|
| |
|
|
|
|
|
|
|
|
| |
Recent egrep displays the following message, breaking golden tests:
egrep: warning: egrep is obsolescent; using grep -E
Switch to using "grep -E" instead
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function GHC.Tc.Utils.TcType.ltPatersonSize would panic when it
encountered a type family on the RHS, as usually these are not allowed
(type families are not allowed on the RHS of class instances or of
quantified constraints). However, it is possible to still encounter
type families on the RHS after doing a bit of constraint solving, as
seen in test case T23171. This could trigger the panic in the call to
ltPatersonSize in GHC.Tc.Solver.Canonical.mk_strict_superclasses, which
is involved in avoiding loopy superclass constraints.
This patch simply changes ltPatersonSize to return "I don't know, because
there's a type family involved" in these cases.
Fixes #23171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch converts all the errors to do with loading interface files
into proper structured diagnostics.
* DriverMessage: Sometimes in the driver we attempt to load an interface
file so we embed the IfaceMessage into the DriverMessage.
* TcRnMessage: Most the time we are loading interface files during
typechecking, so we embed the IfaceMessage
This patch also removes the TcRnInterfaceLookupError constructor which
is superceded by the IfaceMessage, which is now structured compared to
just storing an SDoc before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings the `IrredPred` case in sync with the treatment of `ClassPred`s as
described in `Note [Valid 'deriving' predicate]` in `GHC.Tc.Validity`. Namely,
we should reject `IrredPred`s that are inferred from `deriving` clauses whose
arguments contain other type constructors, as described in `(VD2) Reject exotic
constraints` of that Note. This has the nice property that `deriving` clauses
whose inferred instance context mention `TypeError` will now emit the type
error in the resulting error message, which better matches existing intuitions
about how `TypeError` should work.
While I was in town, I noticed that much of `Note [Valid 'deriving' predicate]`
was duplicated in a separate `Note [Exotic derived instance contexts]` in
`GHC.Tc.Deriv.Infer`. I decided to fold the latter Note into the former so that
there is a single authority on describing the conditions under which an
inferred `deriving` constraint can be considered valid.
This changes the behavior of `deriving` in a way that existing code might
break, so I have made a mention of this in the GHC User's Guide. It seems very,
very unlikely that much code is relying on this strange behavior, however, and
even if there is, there is a clear, backwards-compatible migration path using
`StandaloneDeriving`.
Fixes #22696.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GHC.Prim import is treated quite specially primarily because there
isn't an interface file for GHC.Prim. Therefore we record separately in
the ModSummary if it's imported or not so we don't go looking for it.
This logic hasn't made it's way to `-Wunused-packages` so if you
imported GHC.Prim then the warning would complain you didn't use
`-package ghc-prim`.
Fixes #23212
|
|
|
|
|
|
|
|
|
|
| |
inferResultToType was discarding the ir_frr information, which meant
some metavariables ended up being MetaTvs instead of ConcreteTvs.
This function now creates new ConcreteTvs as necessary, instead of
always creating MetaTvs.
Fixes #23154
|
|
|
|
| |
Fixes #23153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR fixes #23223. The changes are in two places:
* GHC.Tc.Bind.checkMonomorphismRestriction
See the new `Note [When the MR applies]`
We now no longer stupidly attempt to apply the MR when the user
specifies a context, e.g. f :: Eq a => _ -> _
* GHC.Tc.Solver.decideQuantification
See rewritten `Note [Constraints in partial type signatures]`
Fixing this bug apparently breaks three tests:
* partial-sigs/should_compile/T11192
* partial-sigs/should_fail/Defaulting1MROff
* partial-sigs/should_fail/T11122
However they are all symptoms of #23232, so I'm marking them as
expect_broken(23232).
I feel happy about this MR. Nice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR substantially refactors the way in which the constraint
solver deals with equality constraints. The big thing is:
* Intead of a pipeline in which we /first/ canonicalise and /then/
interact (the latter including performing unification) the two steps
are more closely integreated into one. That avoids the current
rather indirect communication between the two steps.
The proximate cause for this refactoring is fixing #22194, which involve
solving [W] alpha[2] ~ Maybe (F beta[4])
by doing this:
alpha[2] := Maybe delta[2]
[W] delta[2] ~ F beta[4]
That is, we don't promote beta[4]! This is very like introducing a cycle
breaker, and was very awkward to do before, but now it is all nice.
See GHC.Tc.Utils.Unify Note [Promotion and level-checking] and
Note [Family applications in canonical constraints].
The big change is this:
* Several canonicalisation checks (occurs-check, cycle-breaking,
checking for concreteness) are combined into one new function:
GHC.Tc.Utils.Unify.checkTyEqRhs
This function is controlled by `TyEqFlags`, which says what to do
for foralls, type families etc.
* `canEqCanLHSFinish` now sees if unification is possible, and if so,
actually does it: see `canEqCanLHSFinish_try_unification`.
There are loads of smaller changes:
* The on-the-fly unifier `GHC.Tc.Utils.Unify.unifyType` has a
cheap-and-cheerful version of `checkTyEqRhs`, called
`simpleUnifyCheck`. If `simpleUnifyCheck` succeeds, it can unify,
otherwise it defers by emitting a constraint. This is simpler than
before.
* I simplified the swapping code in `GHC.Tc.Solver.Equality.canEqCanLHS`.
Especially the nasty stuff involving `swap_for_occurs` and
`canEqTyVarFunEq`. Much nicer now. See
Note [Orienting TyVarLHS/TyFamLHS]
Note [Orienting TyFamLHS/TyFamLHS]
* Added `cteSkolemOccurs`, `cteConcrete`, and `cteCoercionHole` to the
problems that can be discovered by `checkTyEqRhs`.
* I fixed #23199 `pickQuantifiablePreds`, which actually allows GHC to
to accept both cases in #22194 rather than rejecting both.
Yet smaller:
* Added a `synIsConcrete` flag to `SynonymTyCon` (alongside `synIsFamFree`)
to reduce the need for synonym expansion when checking concreteness.
Use it in `isConcreteType`.
* Renamed `isConcrete` to `isConcreteType`
* Defined `GHC.Core.TyCo.FVs.isInjectiveInType` as a more efficient
way to find if a particular type variable is used injectively than
finding all the injective variables. It is called in
`GHC.Tc.Utils.Unify.definitely_poly`, which in turn is used quite a
lot.
* Moved `rewriterView` to `GHC.Core.Type`, so we can use it from the
constraint solver.
Fixes #22194, #23199
Compile times decrease by an average of 0.1%; but there is a 7.4%
drop in compiler allocation on T15703.
Metric Decrease:
T15703
|
|
|
|
|
|
|
|
|
| |
Otherwise we get knock-on errors, such as #23252.
This makes GHC fail a bit sooner, and I have not attempted to add
recovery code, to add a fake TyCon place of the erroneous one,
in an attempt to get more type errors in one pass. We could
do that (perhaps) if there was a call for it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Add the Callback module for "exporting" Haskell functions
to be available to plain JavaScript code
* Fix some primitives defined in GHC.JS.Prim
* Add a JavaScript section to the user guide with instructions
on how to use the JavaScript FFI, building up to using Callbacks
to interact with the browser
* Add tests for the JavaScript FFI and Callbacks
|
|
|
|
| |
Only when the divisor is definitely non-zero.
|
|
|
|
|
|
|
| |
(x / l1) / l2
l1 and l2 /= 0
l1*l2 doesn't overflow
==> x / (l1 * l2)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case quotRemInt# x y of
(# q, _ #) -> body
====>
case quotInt# x y of
q -> body
case quotRemInt# x y of
(# _, r #) -> body
====>
case remInt# x y of
r -> body
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In other words allow generation of typed splices and brackets with
Untyped Template Haskell.
That is useful in cases where a library is build with TTH in mind,
but we still want to generate some auxiliary declarations,
where TTH cannot help us, but untyped TH can.
Such example is e.g. `staged-sop` which works with TTH,
but we would like to derive `Generic` declarations with TH.
An alternative approach is to use `unsafeCodeCoerce`, but then the
derived `Generic` instances would be type-checked only at use sites,
i.e. much later. Also `-ddump-splices` output is quite ugly:
user-written instances would use TTH brackets, not `unsafeCodeCoerce`.
This commit doesn't allow generating of untyped template splices
and brackets with untyped TH, as I don't know why one would want to do
that (instead of merging the splices, e.g.)
|
|
|
|
| |
Fixes #23142
|
|
|
|
| |
Confusingly, GhcDebugged referred to GhcDebugAssertions.
|
|
|
|
|
|
|
|
|
|
| |
When looking up a record field in GHC.Rename.Env.lookupRecFieldOcc,
we could end up calling addUsedGRE on an exact Name, which would then
lead to a panic in the bestImport function: it would be incapable of
processing a GRE which is not local but also not brought into scope
by any imports (as it is referred to by its unique instead).
Fixes #23240
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20117
MR: !10251
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
|
|
|
|
|
|
|
|
|
| |
This issue around solving of constraints arising from superclass
expansion using other constraints also borned from superclass expansion
was the topic of commit aed1974e. That commit made sure we don't emit
a "redundant constraint" warning in a situation in which removing the
constraint would cause errors.
Fixes #23192
|
|
|
|
|
|
| |
unify_ty was incorrectly saying that F x y ~ T x are surely apart,
where F x y is an oversaturated type family and T x is a tyconapp.
As a result, the simplifier dropped a live case alternative (#23134).
|
|
|
|
|
|
|
|
|
|
| |
Previously, the code for converting `INLINE <name>` pragmas from TH splices
used `vNameN`, which assumed that `<name>` must live in the variable namespace.
Pattern synonyms, on the other hand, live in the constructor namespace. I've
fixed the issue by switching to `vcNameN` instead, which works for both the
variable and constructor namespaces.
Fixes #23203.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using Template Haskell, it is possible to re-parent a field OccName
belonging to one data constructor to another data constructor. The
lsp-types package did this in order to "extend" a data constructor
with additional fields.
This ran into an assertion in 'varToRecFieldOcc'. This assertion
can simply be relaxed, as the resulting splices are perfectly sound.
Fixes #23220
|
|
|
|
|
| |
Fixes #21054. Additionally, we can now check for range overlap
when generating Cmm for primops that use memcpy internally.
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. `unsafeCoerce#` was documented in `GHC.Prim`. But since the overhaul
in 74ad75e87317, `unsafeCoerce#` is no longer defined there.
I've combined the documentation in `GHC.Prim` with the `Unsafe.Coerce` module.
2. The documentation of `unsafeCoerce#` stated that you should not
cast a function to an algebraic type, even if you later cast it back
before applying it. But ghci was doing that type of cast, as can be seen
with 'ghci -ddump-ds' and typing 'x = not'. I've changed it to use Any
following the documentation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've turned all occurrences of TcRnUnknownMessage in GHC.Rename.HsType
module into a proper TcRnMessage.
Instead, these TcRnMessage messages were introduced:
TcRnDataKindsError
TcRnUnusedQuantifiedTypeVar
TcRnIllegalKindSignature
TcRnUnexpectedPatSigType
TcRnSectionPrecedenceError
TcRnPrecedenceParsingError
TcRnIllegalKind
TcRnNegativeNumTypeLiteral
TcRnUnexpectedKindVar
TcRnBindMultipleVariables
TcRnBindVarAlreadyInScope
|
|
|
|
| |
Fixes #23206
|
|
|
|
|
|
|
| |
Commit 3f374399 included a breaking-change to the template-haskell
library when it made the GadtC and RecGadtC constructors take non-empty
lists of names. As this has the potential to break many users' packages,
we decided to revert these changes for now.
|
|
|
|
|
|
|
|
|
| |
Tracking ticket: #20117
MR: !10183
This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- this change was approved by the CLC in [1] following a CLC proposal [2]
- make ($) representation polymorphic (adjust the type signature)
- change ($) implementation to allow additional polymorphism
- adjust the haddock of ($) to reflect these changes
- add additional documentation to document these changes
- add changelog entry
- adjust tests (move now succeeding tests and adjust stdout of some
tests)
[1] https://github.com/haskell/core-libraries-committee/issues/132#issuecomment-1487456854
[2] https://github.com/haskell/core-libraries-committee/issues/132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was an outright bug, which Simon fixed in July 2021, as a little side-fix on a complicated patch:
```
commit 6656f0165a30fc2a22208532ba384fc8e2f11b46
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Fri Jul 23 23:57:01 2021 +0100
A bunch of changes related to eta reduction
This is a large collection of changes all relating to eta
reduction, originally triggered by #18993, but there followed
a long saga.
Specifics:
...lots of lines omitted...
Other incidental changes
* Fix a fairly long-standing outright bug in the ApplyToVal case of
GHC.Core.Opt.Simplify.mkDupableContWithDmds. I was failing to take the
tail of 'dmds' in the recursive call, which meant the demands were All
Wrong. I have no idea why this has not caused problems before now.
```
Note this "Fix a fairly longstanding outright bug". This is the specific fix
```
@@ -3552,8 +3556,8 @@ mkDupableContWithDmds env dmds
-- let a = ...arg...
-- in [...hole...] a
-- NB: sc_dup /= OkToDup; that is caught earlier by contIsDupable
- do { let (dmd:_) = dmds -- Never fails
- ; (floats1, cont') <- mkDupableContWithDmds env dmds cont
+ do { let (dmd:cont_dmds) = dmds -- Never fails
+ ; (floats1, cont') <- mkDupableContWithDmds env cont_dmds cont
; let env' = env `setInScopeFromF` floats1
; (_, se', arg') <- simplArg env' dup se arg
; (let_floats2, arg'') <- makeTrivial env NotTopLevel dmd (fsLit "karg") arg'
```
Ticket #23184 is a report of the bug that this diff fixes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors the testsuite driver, gets rid of multi-threading
logic for running test cases concurrently, and uses asyncio &
coroutines instead. This is not yak shaving for its own sake; the
previous multi-threading logic is prone to livelock/deadlock
conditions for some reason, even if the total number of threads is
bounded to a thread pool's capacity.
The asyncify change is an internal implementation detail of the
testsuite driver and does not impact most GHC maintainers out there.
The patch does not touch the .T files, test cases can be
added/modified the exact same way as before.
|
|
|
|
|
|
|
|
| |
This patch changes a thread-local variable to context variable
instead, which works as intended when the testsuite transitions to use
asyncio & coroutines instead of multi-threading to concurrently run
test cases. Note that this also raises the minimum Python version to
3.7.
|
|
|
|
|
| |
This patch fixes some mypy typing errors which weren't caught in
previous linting jobs.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The list_broken make target will transitively depend on the
calibrate.out target, which used STAGE1_GHC instead of TEST_HC. It
really should be TEST_HC since that's what get passed in the gitlab CI
config.
|
| |
|
|
|
|
|
|
|
| |
As noted in #23155, we previously failed to add flushes necessary to
ensure predictable output.
Fixes #23155.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the field-based logic for disambiguating record updates
to the renamer. The type-directed logic, scheduled for removal, remains
in the typechecker.
To do this properly (and fix the myriad of bugs surrounding the treatment
of duplicate record fields), we took the following main steps:
1. Create GREInfo, a renamer-level equivalent to TyThing which stores
information pertinent to the renamer.
This allows us to uniformly treat imported and local Names in the
renamer, as described in Note [GREInfo].
2. Remove GreName. Instead of a GlobalRdrElt storing GreNames, which
distinguished between normal names and field names, we now store
simple Names in GlobalRdrElt, along with the new GREInfo information
which allows us to recover the FieldLabel for record fields.
3. Add namespacing for record fields, within the OccNames themselves.
This allows us to remove the mangling of duplicate field selectors.
This change ensures we don't print mangled names to the user in
error messages, and allows us to handle duplicate record fields
in Template Haskell.
4. Move record disambiguation to the renamer, and operate on the
level of data constructors instead, to handle #21443.
The error message text for ambiguous record updates has also been
changed to reflect that type-directed disambiguation is on the way
out.
(3) means that OccEnv is now a bit more complex: we first key on the
textual name, which gives an inner map keyed on NameSpace:
OccEnv a ~ FastStringEnv (UniqFM NameSpace a)
Note that this change, along with (2), both increase the memory residency
of GlobalRdrEnv = OccEnv [GlobalRdrElt], which causes a few tests to
regress somewhat in compile-time allocation.
Even though (3) simplified a lot of code (in particular the treatment of
field selectors within Template Haskell and in error messages), it came
with one important wrinkle: in the situation of
-- M.hs-boot
module M where { data A; foo :: A -> Int }
-- M.hs
module M where { data A = MkA { foo :: Int } }
we have that M.hs-boot exports a variable foo, which is supposed to match
with the record field foo that M exports. To solve this issue, we add a
new impedance-matching binding to M
foo{var} = foo{fld}
This mimics the logic that existed already for impedance-binding DFunIds,
but getting it right was a bit tricky.
See Note [Record field impedance matching] in GHC.Tc.Module.
We also needed to be careful to avoid introducing space leaks in GHCi.
So we dehydrate the GlobalRdrEnv before storing it anywhere, e.g. in
ModIface. This means stubbing out all the GREInfo fields, with the
function forceGlobalRdrEnv.
When we read it back in, we rehydrate with rehydrateGlobalRdrEnv.
This robustly avoids any space leaks caused by retaining old type
environments.
Fixes #13352 #14848 #17381 #17551 #19664 #21443 #21444 #21720 #21898 #21946 #21959 #22125 #22160 #23010 #23062 #23063
Updates haddock submodule
-------------------------
Metric Increase:
MultiComponentModules
MultiLayerModules
MultiLayerModulesDefsGhci
MultiLayerModulesNoCode
T13701
T14697
hard_hole_fits
-------------------------
|