| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This commit includes the necessary changes in code and
documentation to support a primop that reverses a word's
bits. It also includes a test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #16228. The included test case is adapted from the reproduction in
the issue, and fails without this patch.
------
We compute an initial visilibity mapping for units based on what is
present in the package databases. To seed this, we compute a set of all
the package configs to add visibilities for.
However, this set was keyed off the unit's *package name*. This is
correct, since we compare packages across databases by version. However,
we would only ever consider a single, most-preferable unit from the
database in which it was found.
The effect of this was that only one of the libraries in a Cabal package
would be added to this initial set. This would cause attempts to use
modules from the omitted libraries to fail, claiming that the package
was hidden (even though `ghc-pkg` would correctly show it as visible).
A solution is to do the selection of the most preferable packages
separately, and then be sure to consider exposing all units in the
same package in the same package db. We can do this by picking a
most-preferable unit for each package name, and then considering
exposing all units that are equi-preferable with that unit.
------
Why wasn't this bug apparent to all people trying to use sub-libraries
in Cabal? The answer is that Cabal explicitly passes `-package` and
`-package-id` flags for all the packages it wants to use, rather than
relying on the state of the package database. So this bug only really
affects people who are trying to use package databases produced by Cabal
outside of Cabal itself.
One particular example of this is the way that the
Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these
are equipped with a package database containing all the needed
package dependencies, and the user is not expected to pass
`-package` flags explicitly.
|
|
|
|
| |
This patch only attempts to fix links that don't automatically re-direct to the correct URL.
|
|
|
|
|
|
|
|
|
|
| |
- `emitCopySmallArray` now checks size before generating code and
doesn't generate any code when size is 0. `emitCopyArray` already does
this so this makes small/large array cases the same in argument
checking.
- In both `emitCopySmallArray` and `emitCopyArray` read the `dflags`
after checking the argument.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.
This substitution is classified as follows:
1. Automated substitution using sed with Ben's mapping rule [1]
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
2. Manual substitution for URLs containing `#` index
Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
3. Manual substitution for strings starting with `Commentary`
Old: Commentary/XxxYyy...
New: commentary/xxx-yyy...
See also !539
[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
|
|
|
|
|
|
| |
As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail
Coauthored-by: Ben Gamari <ben@well-typed.com>
|
|
|
|
|
|
| |
!301 removed the `HsArrApp` and `HsArrForm` constructors, which
renders the corresponding extension points `XArrApp` and `XArrForm`
useless. This patch finally rips them out.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When GHC attempts to unify a metavariable with a type containing
foralls, it will be rejected as an occurrence of impredicativity.
GHC was /not/ extending the same treatment to predicate types, such
as in the following (erroneous) example from #11514:
```haskell
foo :: forall a. (Show a => a -> a) -> ()
foo = undefined
```
This will attempt to instantiate `undefined` at
`(Show a => a -> a) -> ()`, which is impredicative. This patch
catches impredicativity arising from predicates in this fashion.
Since GHC is pickier about impredicative instantiations, some test
cases needed to be updated to be updated so as not to fall afoul of
the new validity check. (There were a surprising number of
impredicative uses of `undefined`!) Moreover, the `T14828` test case
now has slightly less informative types shown with `:print`. This is
due to a a much deeper issue with the GHCi debugger (see #14828).
Fixes #11514.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This function allows the user to compute the (non-transitive) size of a
heap object in words. The "closure" in the name is admittedly confusing
but we are stuck with this nomenclature at this point.
|
|
|
|
|
| |
As discussed in #16450, this feature regresses CI on Windows, causing
non-deterministic failures due to missing files.
|
|
|
|
|
|
|
| |
The extra-constraints wildcard had lost its location
(issue #16431).
Happily this is easy to fix. Lots of error improvements.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #16418 showed that we were carrying on too eagerly after a bogus
type signature was identified (a bad telescope in fact), leading to a
subsequent crash.
This led me in to a maze of twisty little passages in the typechecker's
error recovery, and I ended up doing some refactoring in TcRnMonad.
Some specfifics
* TcRnMonad.try_m is now called attemptM.
* I switched the order of the result pair in tryTc,
to make it consistent with other similar functions.
* The actual exception used in the Tc monad is irrelevant so,
to avoid polluting type signatures, I made tcTryM, a simple
wrapper around tryM, and used it.
The more important changes are in
* TcSimplify.captureTopConstraints, where we should have been calling
simplifyTop rather than reportUnsolved, so that levity defaulting
takes place properly.
* TcUnify.emitResidualTvConstraint, where we need to set the correct
status for a new implication constraint. (Previously we ended up
with an Insoluble constraint wrapped in an Unsolved implication,
which meant that insolubleWC gave the wrong answer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We make liveness information for global registers
available on `JMP` and `BCTR`, which were the last instructions
missing. With complete liveness information we do not need to
reserve global registers in `freeReg` anymore. Moreover we
assign R9 and R10 to callee saves registers.
Cleanup by removing `Reg_Su`, which was unused, from `freeReg`
and removing unused register definitions.
The calculation of the number of floating point registers is too
conservative. Just follow X86 and specify the constants directly.
Overall on PowerPC this results in 0.3 % smaller code size in nofib
while runtime is slightly better in some tests.
|
|
|
|
| |
This addresses issue #16427. An easy fix.
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GHCi debugger has never been that robust in the face of
higher-rank types, or even types that are _interally_ higher-rank,
such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
however, things became even worse, as the debugger would start to
_panic_ when a user tries passing the name of a higher-rank thing
to `:print`. This all ties back to a strange `isUnliftedType` check
in `Debugger` that was mysteriously added 11 years ago
(in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no
explanation whatsoever.
After some experimentation, no one is quite sure what this
`isUnliftedType` check is actually accomplishing. The test suite
still passes if it's removed, and I am unable to observe any
differences in debugger before even with data types that _do_ have
fields of unlifted types (e.g., `data T = MkT Int#`). Given that
this is actively causing problems (see #14828), the prudent thing
to do seems to be just removing this `isUnliftedType` check, and
waiting to see if anyone shouts about it. This patch accomplishes
just that.
Note that this patch fix the underlying issues behind #14828, as the
debugger will still print unhelpful info if you try this:
```
λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
λ> :print f
f = (_t1::t1)
```
But fixing this will require much more work, so let's start with the
simple stuff for now.
|
|
|
|
|
|
|
|
| |
The `dataConCannotMatch` function (which powers the
`-Wpartial-fields` warning, among other things) had special reasoning
for explicit equality constraints of the form `a ~ b`, but it did
not extend that reasoning to `a ~~ b` constraints, leading to #16411.
Easily fixed.
|
|
|
|
| |
Also remove unused arg from get_Regtable_addr_from_offset
|
|
|
|
|
|
|
|
|
|
| |
Code in TcErrors was recursively using immSuperClasses,
which loops in the presence of UndecidableSuperClasses.
Better to use transSuperClasses instead, which has a loop-breaker
mechanism built in.
Fixes issue #16414.
|
|
|
|
|
|
|
| |
We'd like to enforce the substitution invariant (Trac #11371).
In a492af06d326453 the assertion was downgraded to a warning;
I'm restoring the assertion and making the calls that
don't maintain the invariant as unchecked.
|
|
|
|
|
| |
GHC native code generator generates .incbin and .file directives. We
need to escape those strings correctly on Windows (see #16389).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue was reproduced with, and the fix confirmed with,
the `hatrace` tool for syscall-based fault injection:
https://github.com/nh2/hatrace
The concrete test case for GHC is at
https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185
A previous, nondeterministic reproducer for the issue was provided by
Alexey Kuleshevich in
https://github.com/lehins/exec-kill-loop
Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com>
Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch GHC was trying to be too clever
(Trac #16344); it succeeded in kind-checking this
polymorphic-recursive declaration
data T ka (a::ka) b
= MkT (T Type Int Bool)
(T (Type -> Type) Maybe Bool)
As Note [No polymorphic recursion] discusses, the "solution" was
horribly fragile. So this patch deletes the key lines in
TcHsType, and a wodge of supporting stuff in the renamer.
There were two regressions, both the same: a closed type family
decl like this (T12785b) does not have a CUSK:
type family Payload (n :: Peano) (s :: HTree n x) where
Payload Z (Point a) = a
Payload (S n) (a `Branch` stru) = a
To kind-check the equations we need a dependent kind for
Payload, and we don't get that any more. Solution: make it
a CUSK by giving the result kind -- probably a good thing anyway.
The other case (T12442) was very similar: a close type family
declaration without a CUSK.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC represents String literals as ByteString internally for efficiency
reasons. However, until now it wasn't possible to efficiently create
large string literals with TH (e.g. to embed a file in a binary, cf #14741):
TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
into a ByteString.
This patch adds the possibility to efficiently create a "string" literal
from raw bytes. We get the following compile times for different sizes
of TH created literals:
|| Size || Before || After || Gain ||
|| 30K || 2.307s || 2.299 || 0% ||
|| 3M || 3.073s || 2.400s || 21% ||
|| 30M || 8.517s || 3.390s || 60% ||
Ticket #14741 can be fixed if the original code uses this new TH feature.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #16376 showed the danger of failing to report an error
that exists only in the unsolved constraints, if an exception
is raised (via failM).
Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
did just that -- i.e. it found errors in the constraints, and
called failM to avoid a misleading cascade.
So we need to be sure to call captureTopConstraints to report
those insolubles. This was wrong in TcRnDriver.tcRnExpr and
in TcRnDriver.tcRnType.
As a result the error messages from test T13466 improved slightly,
a happy outcome.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trac #10069 revealed that small NOINLINE functions didn't get split
into worker and wrapper. This was due to `certainlyWillInline`
saying that any unfoldings with a guidance of `UnfWhen` inline
unconditionally. That isn't the case for NOINLINE functions, so we
catch this case earlier now.
Nofib results:
--------------------------------------------------------------------------------
Program Allocs Instrs
--------------------------------------------------------------------------------
fannkuch-redux -0.3% 0.0%
gg +0.0% +0.1%
maillist -0.2% -0.2%
minimax 0.0% -0.8%
--------------------------------------------------------------------------------
Min -0.3% -0.8%
Max +0.0% +0.1%
Geometric Mean -0.0% -0.0%
Fixes #10069.
-------------------------
Metric Increase:
T9233
-------------------------
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type-variables-escaping-their-scope-via-kinds check in
`TcValidity` was failing to properly expand type synonyms, which led
to #16391. This is easily fixed by using `occCheckExpand` before
performing the validity check.
Along the way, I refactored this check out into its own function,
and sprinkled references to Notes to better explain all of the moving
parts. Many thanks to @simonpj for the suggestions.
Bumps the haddock submodule.
|
|
|
|
|
|
|
|
|
| |
`instance forall c. c` claimed that `c` was out of scope because the
renamer was invoking `lookupGlobalOcc` on `c` (in
`RnNames.getLocalNonValBinders`) without binding `c` first. To avoid
this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c`
instead, and if that returns `Nothing`, then bail out, resulting
in a better error message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The splitter is an evil Perl script that processes assembler code.
Its job can be done better by the linker's --gc-sections flag. GHC
passes this flag to the linker whenever -split-sections is passed on
the command line.
This is based on @DemiMarie's D2768.
Fixes Trac #11315
Fixes Trac #9832
Fixes Trac #8964
Fixes Trac #8685
Fixes Trac #8629
|
|
|
|
|
|
|
|
| |
This addresses Trac #16208 by marking newtype wrapper
unfoldings as compulsory.
Furthermore, we can remove the special case for newtypes
in exprIsConApp_maybe (introduced in 7833cf407d1f).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two rather gnarly test cases:
* Trac #16342 (mutual recursion)
See Note [Tricky scoping in generaliseTcTyCon]
* Trac #16221 (shadowing)
See Note [Unification variables need fresh Names]
The main changes are:
* Substantial reworking of TcTyClsDecls.generaliseTcTyCon
This is the big change, and involves the rather tricky
function TcHsSyn.zonkRecTyVarBndrs.
See Note [Inferring kinds for type declarations] and
Note [Tricky scoping in generaliseTcTyCon] for the details.
* bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now
allocate /freshly-named/ unification variables. Indeed, more
generally, unification variables are always fresh; see
Note [Unification variables need fresh Names] in TcMType
* Clarify the role of tcTyConScopedTyVars.
See Note [Scoped tyvars in a TcTyCon] in TyCon
As usual, this dragged in some more refactoring:
* Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise
* I renamed checkValidTelescope to checkTyConTelescope;
it's only used on TyCons, and indeed takes a TyCon as argument.
* I folded the slightly-mysterious reportFloatingKvs into
checkTyConTelescope. (Previously all its calls immediately
followed a call to checkTyConTelescope.) It makes much more
sense there.
* I inlined some called-once functions to simplify
checkValidTyFamEqn. It's less spaghetti-like now.
* This patch also fixes Trac #16251. I'm not quite sure why #16251
went wrong in the first place, nor how this patch fixes it, but
hey, it's good, and life is short.
|
|
|
|
| |
This reverts commit 0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d.
|
|
|
|
| |
This reverts commit e8a08f400744a860d1366c6680c8419d30f7cc2a.
|
|
|
|
|
|
|
|
|
|
| |
The following previously fatal lexer errors are now non-fatal:
* errors about enabling `LambdaCase`
* errors about enabling `NumericUnderscores`
* errors about having valid characters in primitive strings
See #16270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements GHC proposal 35
(https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
by adding the ability to write kinds with
visible dependent quantification (VDQ).
Most of the work for supporting VDQ was actually done _before_ this
patch. That is, GHC has been able to reason about kinds with VDQ for
some time, but it lacked the ability to let programmers directly
write these kinds in the source syntax. This patch is primarly about
exposing this ability, by:
* Changing `HsForAllTy` to add an additional field of type
`ForallVisFlag` to distinguish between invisible `forall`s (i.e,
with dots) and visible `forall`s (i.e., with arrows)
* Changing `Parser.y` accordingly
The rest of the patch mostly concerns adding validity checking to
ensure that VDQ is never used in the type of a term (as permitting
this would require full-spectrum dependent types). This is
accomplished by:
* Adding a `vdqAllowed` predicate to `TcValidity`.
* Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
that only splits invisible `forall`s. This function is used in
certain places (e.g., in instance declarations) to ensure that GHC
doesn't try to split visible `forall`s (e.g., if it tried splitting
`instance forall a -> Show (Blah a)`, then GHC would mistakenly
allow that declaration!)
This also updates Template Haskell by introducing a new `ForallVisT`
constructor to `Type`.
Fixes #16326. Also fixes #15658 by documenting this feature in the
users' guide.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
Fixes Trac #16334, Trac #16315
With this patch, scoping rules for type and kind variables have been
unified: kind variables no longer receieve special treatment. This
simplifies both the language and the implementation.
User-facing changes
-------------------
* Kind variables are no longer implicitly quantified when an explicit
forall is used:
p :: Proxy (a :: k) -- still accepted
p :: forall k a. Proxy (a :: k) -- still accepted
p :: forall a. Proxy (a :: k) -- no longer accepted
In other words, now we adhere to the "forall-or-nothing" rule more
strictly.
Related function: RnTypes.rnImplicitBndrs
* The -Wimplicit-kind-vars warning has been deprecated.
* Kind variables are no longer implicitly quantified in constructor
declarations:
data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted
data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted
Related function: RnTypes.extractRdrKindSigVars
* Implicitly quantified kind variables are no longer put in front of
other variables:
f :: Proxy (a :: k) -> Proxy (b :: j)
f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order
f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order
This is a breaking change for users of TypeApplications. Note that
we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
See "Ordering of specified variables" in the User's Guide.
Related function: RnTypes.rnImplicitBndrs
* In type synonyms and type family equations, free variables on the RHS
are no longer implicitly quantified unless used in an outermost kind
annotation:
type T = Just (Nothing :: Maybe a) -- no longer accepted
type T = Just Nothing :: Maybe (Maybe a) -- still accepted
The latter form is a workaround due to temporary lack of an explicit
quantification method. Ideally, we would write something along these
lines:
type T @a = Just (Nothing :: Maybe a)
Related function: RnTypes.extractHsTyRdrTyVarsKindVars
* Named wildcards in kinds are fixed (Trac #16334):
x :: (Int :: _t) -- this compiles, infers (_t ~ Type)
Related function: RnTypes.partition_nwcs
Implementation notes
--------------------
* One of the key changes is the removal of FKTV in RnTypes:
- data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName]
- , fktv_tys :: [Located RdrName] }
+ type FreeKiTyVars = [Located RdrName]
We used to keep track of type and kind variables separately, but
now that they are on equal footing when it comes to scoping, we
can put them in the same list.
* extract_lty and family are no longer parametrized by TypeOrKind,
as we now do not distinguish kind variables from type variables.
* PatSynExPE and the related Note [Pattern synonym existentials do not scope]
have been removed (Trac #16315). With no implicit kind quantification,
we can no longer trigger the error.
* reportFloatingKvs and the related Note [Free-floating kind vars]
have been removed. With no implicit kind quantification,
we can no longer trigger the error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #14037.
Metric Decrease:
T9872b
T9872d
Reviewers: bgamari, simonpj, hvr
Reviewed By: simonpj
Subscribers: AndreasK, simonpj, osa1, dfeuer, rwbarton, carter
GHC Trac Issues: #14037
Differential Revision: https://phabricator.haskell.org/D5249
|
|
|
|
|
|
|
|
|
|
|
| |
While playing around with late lambda lifting, I realised that
StgLamLift.Analysis doesn't consider the removed closure header in its
allocation estimations.
That's because contrary to what I thought, the total word count returned
by `mkVirtHeapOffsets` doesn't include the size of the closure header.
We just add the header size manually now.
|
|
|
|
|
|
|
|
| |
`--supported-languages` must only advertise language extensions
which are supported by the compiler in order for tooling such
as Cabal relying on this signalling not to behave incorrectly.
Fixes #16331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
introducing a new ambiguity resolution system in the parser.
Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a command:
proc x -> do { (stuff) -< x } -- 'stuff' is an expression
proc x -> do { (stuff) } -- 'stuff' is a command
Until we encounter arrow syntax (-<) we don't know whether to parse
'stuff' as an expression or a command.
The old solution was to parse as HsExpr always, and rejig later:
checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
This meant polluting 'HsExpr' with command-related constructors. In
other words, limitations of the parser were affecting the AST, and
all other code (the renamer, the typechecker) had to deal with these
extra constructors by panicking.
We fix this abstraction leak by parsing into an intermediate
representation, 'ExpCmd':
data ExpCmdG b where
ExpG :: ExpCmdG HsExpr
CmdG :: ExpCmdG HsCmd
type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
checkExp f = f ExpG -- interpret as an expression
checkCmd f = f CmdG -- interpret as a command
See Note [Ambiguous syntactic categories] for details.
Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/command ambiguity.
Future work: apply the same principles to the expression/pattern
ambiguity.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The big payload of this patch is:
Add an AnonArgFlag to the FunTy constructor
of Type, so that
(FunTy VisArg t1 t2) means (t1 -> t2)
(FunTy InvisArg t1 t2) means (t1 => t2)
The big payoff is that we have a simple, local test to make
when decomposing a type, leading to many fewer calls to
isPredTy. To me the code seems a lot tidier, and probably
more efficient (isPredTy has to take the kind of the type).
See Note [Function types] in TyCoRep.
There are lots of consequences
* I made FunTy into a record, so that it'll be easier
when we add a linearity field, something that is coming
down the road.
* Lots of code gets touched in a routine way, simply because it
pattern matches on FunTy.
* I wanted to make a pattern synonym for (FunTy2 arg res), which
picks out just the argument and result type from the record. But
alas the pattern-match overlap checker has a heart attack, and
either reports false positives, or takes too long. In the end
I gave up on pattern synonyms.
There's some commented-out code in TyCoRep that shows what I
wanted to do.
* Much more clarity about predicate types, constraint types
and (in particular) equality constraints in kinds. See TyCoRep
Note [Types for coercions, predicates, and evidence]
and Note [Constraints in kinds].
This made me realise that we need an AnonArgFlag on
AnonTCB in a TyConBinder, something that was really plain
wrong before. See TyCon Note [AnonTCB InivsArg]
* When building function types we must know whether we
need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
This turned out to be pretty easy in practice.
* Pretty-printing of types, esp in IfaceType, gets
tidier, because we were already recording the (->)
vs (=>) distinction in an ad-hoc way. Death to
IfaceFunTy.
* mkLamType needs to keep track of whether it is building
(t1 -> t2) or (t1 => t2). See Type
Note [mkLamType: dictionary arguments]
Other minor stuff
* Some tidy-up in validity checking involving constraints;
Trac #16263
|
|
|
|
|
|
|
| |
Remove a bogus assertion in FamInst.newFamInst
(There is a comment to explain.)
This fixes Trac #16112.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this commit
commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6
Date: Thu Jan 24 17:58:50 2019 +0100
Look through newtype wrappers (Trac #16254)
we made exprIsConApp_maybe quite a bit cleverer. But I had not paid
enough attention to keeping exactly the correct substitution and
in-scope set, which led to Trac #16348.
There were several buglets (like applying the substitution twice in
exprIsConApp_maybe, but the proximate source of the bug was that we were
calling addNewInScopeIds, which deleted things from the substitution as
well as adding them to the in-scope set. That's usually right, but not
here!
This was quite tricky to track down. But it is nicer now.
|