| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
`mkBootModDetailsTc`, which creates a special `ModDetails` when
`-fno-code` is enabled, was not properly filling in the `COMPLETE`
signatures from the `TcGblEnv`, resulting in incorrect pattern-match
coverage warnings. Easily fixed.
Fixes #16682.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if we had
f |> co
where `f` had arity type `ABot N` and `co` had arity M and M < N,
`arityType` would return `ABot M` which is wrong, because `f` is only
known to diverge when applied to `N` args, as described in Note
[ArityType]:
If at = ABot n, then (f x1..xn) definitely diverges. Partial
applications to fewer than n args may *or may not* diverge.
This caused incorrect eta expansion in the simplifier, causing #16066.
We now return `ATop M` for the same expression so the simplifier can't
assume partial applications of `f |> co` is divergent.
A regression test T16066 is also added.
|
| | |
|
| |
|
|
|
|
|
| |
These were meant to be added in !214 but for some reason wasn't included
in the patch.
Update Haddock submodule for new Types.hs hyperlinker output
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When ghc was built for powerpc32 built failed as:
It's a fallout of commit 3f46cffcc2850e68405a1
("PPC NCG: Refactor stack allocation code") where
word size used to be
II32/II64
and changed to
II8/panic "no width for given number of bytes"
widthFromBytes ((platformWordSize platform) `quot` 8)
The change restores initial behaviour by removing extra division.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On powerpc32 64-bit comparison code generated dangling
target labels. This caused ghc build failure as:
$ ./configure --target=powerpc-unknown-linux-gnu && make
...
SCCs aren't in reverse dependent order
bad blockId n3U
This happened because condIntCode' in PPC codegen generated
label name but did not place the label into `cmp_lo` code block.
The change adds the `cmp_lo` label into the case of negative
comparison.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
| | |
|
| |
|
|
|
|
| |
As per @mpickering's suggestion on IRC this is to make the partial
module-graph more easily accessible for API clients which don't intend to
re-implementing depanal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the way preprocessor failures are presented to the
user. Previously the user would simply get an unlocated message on stderr
such as:
`gcc' failed in phase `C pre-processor'. (Exit code: 1)
Now at the problematic source file is mentioned:
A.hs:1:1: error:
`gcc' failed in phase `C pre-processor'. (Exit code: 1)
This also makes live easier for GHC API clients as the preprocessor error
is now thrown as a SourceError exception.
|
| |
|
|
|
|
|
|
| |
This enables API clients to handle such errors instead of immideately
crashing in the face of some kinds of user errors, which is arguably quite
bad UX.
Fixes #10887
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces a slight change of behaviour in the interrest of keeping
the code simple: Previously summariseModule would not call
addHomeModuleToFinder for summaries that are being re-used but now we do.
We're forced to to do this in summariseFile because the file being
summarised might not even be on the regular search path! So if GHC is to
find it at all we have to pre-populate the cache with its location. For
modules however the finder cache is really just a cache so we don't have to
pre-populate it with the module's location.
As straightforward as that seems I did almost manage to introduce a bug (or
so I thought) because the call to addHomeModuleToFinder I copied from
summariseFile used to use `ms_location old_summary` instead of the
`location` argument to checkSummaryTimestamp. If this call were to
overwrite the existing entry in the cache that would have resulted in us
using the old location of any module even if it was, say, moved to a
different directory between calls to 'depanal'.
However it turns out the cache just ignores the location if the module is
already in the cache. Since summariseModule has to search for the module,
which has the side effect of populating the cache, everything would have
been fine either way.
Well I'm adding a test for this anyways: tests/depanal/OldModLocation.hs.
|
| | |
|
| | |
|
| |
|
|
|
| |
This is to enable #10887 as well as to make it possible to test downsweep
on its own in the testsuite.
|
| |
|
|
|
|
|
|
|
|
| |
After the previous commit, `Settings` is just a thin wrapper around
other groups of settings. While `Settings` is used by GHC-the-executable
to initalize `DynFlags`, in principle another consumer of
GHC-the-library could initialize `DynFlags` a different way. It
therefore doesn't make sense for `DynFlags` itself (library code) to
separate the settings that typically come from `Settings` from the
settings that typically don't.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As far as I can tell, the fields within `Settings` aren't *intrinsicly*
related. They just happen to be initialized the same way (in particular
prior to the rest of `DynFlags`), and that is why they are grouped
together.
Within `Settings`, however, there are groups of settings that clearly do
share something in common, regardless of how they anything is
initialized.
In the spirit of GHC being a library, where the end cosumer may choose
to initialize this configuration in arbitrary ways, I made some new data
types for thoses groups internal to `Settings`, and used them to define
`Settings` instead. Hopefully this is a baby step towards a general
decoupling of the stateful and stateless parts of GHC.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Currently 'getRootSummary' will fail with an exception if a 'TargetFile' is
given but it does not exist even if an input buffer is passed along for
this target.
In this case it is not necessary for the file to exist since the buffer
will be used as input for the compilation pipeline instead of the file
anyways.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows GHC API clients, most notably tooling such as
Haskell-IDE-Engine, to pass unsaved files to GHC more easily.
Currently when targetContents is used but the module requires preprocessing
'preprocessFile' simply throws an error because the pipeline does not
support passing a buffer.
This change extends `runPipeline` to allow passing the input buffer into
the pipeline. Before proceeding with the actual pipeline loop the input
buffer is immediately written out to a new tempfile.
I briefly considered refactoring the pipeline at large to pass around
in-memory buffers instead of files, but this seems needlessly complicated
since no pipeline stages other than Hsc could really support this at the
moment.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Unboxed tuples and sums take extra RuntimeRep arguments,
which must be manually passed in a few places.
This was not done in deSugar/Check.
This error was hidden because zipping functions in TyCoRep
ignored lists with mismatching length. This is now fixed;
the lengths are now checked by calling zipEqual.
As suggested in #16565, I moved checking for isTyVar and
isCoVar to zipTyEnv and zipCoEnv.
|
| |
|
|
|
| |
We fetch the ArgFlag for every argument by using splitForAllVarBndrs
instead of splitForAllTys in unwrapTypeVars.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously -ddump-cmm was generating code with unbalanced curly braces:
stg_atomically_entry() // [R1]
{ info_tbls: [(cfl,
label: stg_atomically_info
rep: tag:16 HeapRep 1 ptrs { Thunk }
srt: Nothing)]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
cfl: // cfk
unwind Sp = Just Sp + 0;
_cfk::P64 = R1;
//tick src<rts/PrimOps.cmm:(1243,1)-(1245,1)>
R1 = I64[_cfk::P64 + 8 + 8 + 0 * 8];
call stg_atomicallyzh(R1) args: 8, res: 0, upd: 8;
}
}, <---- OPENING BRACE MISSING
After this patch:
stg_atomically_entry() { // [R1] <---- MISSING OPENING BRACE HERE
{ info_tbls: [(cfl,
label: stg_atomically_info
rep: tag:16 HeapRep 1 ptrs { Thunk }
srt: Nothing)]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
cfl: // cfk
unwind Sp = Just Sp + 0;
_cfk::P64 = R1;
//tick src<rts/PrimOps.cmm:(1243,1)-(1245,1)>
R1 = I64[_cfk::P64 + 8 + 8 + 0 * 8];
call stg_atomicallyzh(R1) args: 8, res: 0, upd: 8;
}
},
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following the discussion under #16473, this change allows the
specializer to work on any dicts in a lambda, not just those that occur
at the beginning.
For example, if you use data types which contain dictionaries and
higher-rank functions then once these are erased by the optimiser you
end up with functions such as:
```
go_s4K9
Int#
-> forall (m :: * -> *).
Monad m =>
(forall x. Union '[State (Sum Int)] x -> m x) -> m ()
```
The dictionary argument is after the Int# value argument, this patch
allows `go` to be specialised.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit splits out a subset of GhcException which do not depend on
pretty printing (SDoc), as a new datatype called
PlainGhcException. These exceptions can be caught as GhcException,
because 'fromException' will convert them.
The motivation for this change is that that the Panic module
transitively depends on many modules, primarily due to pretty printing
code. It's on the order of about 130 modules. This large set of
dependencies has a few implications:
1. To avoid cycles / use of boot files, these dependencies cannot
throw GhcException.
2. There are some utility modules that use UnboxedTuples and also use
`panic`. This means that when loading GHC into GHCi, about 130
additional modules would need to be compiled instead of
interpreted. Splitting the non-pprint exception throwing into a new
module resolves this issue. See #13101
|
| |
|
|
|
|
|
|
| |
* Tweak the parser to allow `deriving` clauses to mention explicit
`forall`s or kind signatures without gratuitous parentheses.
(This fixes #14332 as a consequence.)
* Allow Haddock comments on `deriving` clauses with explicit
`forall`s. This requires corresponding changes in Haddock.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Associated type family default declarations behave strangely in a
couple of ways:
1. If one tries to bind the type variables with an explicit `forall`,
the `forall`'d part will simply be ignored. (#16110)
2. One cannot use visible kind application syntax on the left-hand
sides of associated default equations, unlike every other form
of type family equation. (#16356)
Both of these issues have a common solution. Instead of using
`LHsQTyVars` to represent the left-hand side arguments of an
associated default equation, we instead use `HsTyPats`, which is what
other forms of type family equations use. In particular, here are
some highlights of this patch:
* `FamEqn` is no longer parameterized by a `pats` type variable, as
the `feqn_pats` field is now always `HsTyPats`.
* The new design for `FamEqn` in chronicled in
`Note [Type family instance declarations in HsSyn]`.
* `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
means that many of `TyFamDefltEqn`'s code paths can now reuse the
code paths for `TyFamInstEqn`, resulting in substantial
simplifications to various parts of the code dealing with
associated type family defaults.
Fixes #16110 and #16356.
|
| |
|
|
| |
See #13101 and #15454
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The idea is to automatically enable -fobject-code for modules that use
UnboxedTuples, along with all the modules they depend on. When looking
into how to solve this, I was pleased to find that there was already
highly similar logic for enabling code generation when -fno-code is
specified but TemplateHaskell is used.
The state before this patch was that if you used unboxed tuples then you
had to enable `-fobject-code` globally rather than on a per module
basis.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Most places where we convert contexts in `Convert` are actually in
positions that are to the left of some `=>`, such as in superclasses
and instance contexts. Accordingly, these contexts need to be
parenthesized at `funPrec`. To accomplish this, this patch changes
`cvtContext` to require a precedence argument for the purposes of
calling `parenthesizeHsContext` and adjusts all `cvtContext` call
sites accordingly.
|
| |
|
|
| |
Issue #16521
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC Proposal #36 describes a transition plan away from CUSKs and to
top-level kind signatures:
1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs
as they currently exist.
2. We turn off the -XCUSKs extension in a few releases and remove it
sometime thereafter.
This patch implements phase 1 of this plan, introducing a new language
extension to control whether CUSKs are enabled. When top-level kind
signatures are implemented, we can transition to phase 2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. If GHC is to be multi-target, these cannot be baked in at compile
time.
2. Compile-time flags have a higher maintenance than run-time flags.
3. The old way makes build system implementation (various bootstrapping
details) with the thing being built. E.g. GHC doesn't need to care
about which integer library *will* be used---this is purely a crutch
so the build system doesn't need to pass flags later when using that
library.
4. Experience with cross compilation in Nixpkgs has shown things work
nicer when compiler's can *optionally* delegate the bootstrapping the
package manager. The package manager knows the entire end-goal build
plan, and thus can make top-down decisions on bootstrapping. GHC can
just worry about GHC, not even core library like base and ghc-prim!
|
| | |
|
| | |
|
| |
|
|
|
|
| |
`checkTyClHdr`'s case for `HsTyVar` was grabbing the wrong `SrcSpan`,
which lead to error messages pointing to the wrong location. Easily
fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A follow-up to !696's, which attempted to clean up the error messages
for ill formed associated type family default equations. The previous
attempt, !696, forgot to account for the possibility of duplicate
kind variable arguments, as in the following example:
```hs
class C (a :: j) where
type T (a :: j) (b :: k)
type T (a :: k) (b :: k) = k
```
This patch addresses this shortcoming by adding an additional check
for this. Fixes #13971 (hopefully for good this time).
|
| |
|
|
| |
is available
|
| |
|
|
| |
Get "Tables next to code" from the settings file instead.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issues #12102 and #15872 revealed something strange about the way GHC
handles equality constraints in kinds: it treats them as _visible_
arguments! This causes a litany of strange effects, from strange
error messages
(https://gitlab.haskell.org/ghc/ghc/issues/12102#note_169035)
to bizarre `Eq#`-related things leaking through to GHCi output, even
without any special flags enabled.
This patch is an attempt to contain some of this strangeness.
In particular:
* In `TcHsType.etaExpandAlgTyCon`, we propagate through the
`AnonArgFlag`s of any `Anon` binders. Previously, we were always
hard-coding them to `VisArg`, which meant that invisible binders
(like those whose kinds were equality constraint) would mistakenly
get flagged as visible.
* In `ToIface.toIfaceAppArgsX`, we previously assumed that the
argument to a `FunTy` always corresponding to a `Required`
argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
`VisArg` to `Required` and `InvisArg` to `Inferred`. As a
consequence, the iface pretty-printer correctly recognizes that
equality coercions are inferred arguments, and as a result,
only displays them in `-fprint-explicit-kinds` is enabled.
* Speaking of iface pretty-printing, `Anon InvisArg` binders were
previously being pretty-printed like `T (a :: b ~ c)`, as if they
were required. This seemed inconsistent with other invisible
arguments (that are printed like `T @{d}`), so I decided to switch
this to `T @{a :: b ~ c}`.
Along the way, I also cleaned up a minor inaccuracy in the users'
guide section for constraints in kinds that was spotted in
https://gitlab.haskell.org/ghc/ghc/issues/12102#note_136220.
Fixes #12102 and #15872.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before
Version: Wanted [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5],
got [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5]
After
Version: Wanted 809020190425,
got 809020190425
|
