| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Headers should be associated with the RTS, and subject to less hacks.
The most subtle issue was that the package-grained dependencies on
generated files were being `need`ed before calculating Haskell deps, but
not before calculating C/C++ deps.
|
| |
|
|
|
|
|
| |
It appears that libstdc++ is no longer available in recent XCode
distributions.
Closes #16083.
|
| |
|
|
|
|
|
| |
It appears that Darwin's toolchain includes system headers in the
dependency makefiles it generates with `-M` with older
`MACOSX_DEPLOYMENT_TARGETS`. To avoid this we have bumped the deployment
target for x86-64/Darwin to 10.10.
|
| |
|
|
|
| |
This avoids the need to build `text` without Cabal, in turn avoiding the
need to reproduce the workaround for #20010 contained therein.
|
| |
|
|
|
|
|
| |
Accommodates text-2.0.
Metric Decrease:
T15578
|
| | |
|
| |
|
|
| |
Co-Authored By: Matthew Pickering <matthew@well-typed.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of testsuite/tests/typecheck/should_fail/T17563.hs is to
make sure we do validity checking on quantified constraints.
In particular, see the following functions in GHC.Tc.Validity:
* check_quant_pred
* check_pred_help
* check_class_pred
The original bug report used a~b constraints as an example of a
constraint that requires validity checking. But with GHC Proposal #371,
equality constraints no longer require GADTs or TypeFamilies; instead,
they require TypeOperators, which are checked earlier in the pipeline,
in the renamer.
Rather than simply remove this test, we change the example to use
another extension: FlexibleContexts. Since we decide whether a
constraint requires this extension in check_class_pred, the regression
test continues to exercise the relevant code path.
|
| |
|
|
|
|
|
| |
Ticket #19815 suggested changing coToMCo to use
isReflexiveCo rather than isReflCo. But perf results
weren't encouraging. This patch just adds a comment to
point to the data, such as it is.
|
| |
|
| |
This reverts commit 41117d71bb58e001f6a2b6a11c9314d5b70b9182
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently in GHCi, when given a line of user input we:
1. Attempt to parse and handle it as a statement
2. Otherwise, attempt to parse and handle a single import
3. Otherwise, check if there are imports present (and if so display an error message)
4. Otherwise, attempt to parse a module and only handle the declarations
This patch simplifies the process to:
Attempt to parse and handle it as a statement
Otherwise, attempt to parse a module and handle the imports and declarations
This means that multiple imports in a multiline are now accepted, and a multiline containing both imports and declarations is now accepted (as well as when separated by semicolons).
|
| |
|
|
| |
They were added in 33173a51c77d9960d5009576ad9b67b646dfda3c, which constitutes GHC 8.10.1 / base-4.14.0.0
|
| |
|
|
|
|
| |
Haddock doesn't know how to render SAKS, so the only current way to make
the documentation show the kind is to write what it should say into the
type family declaration.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since 8.10, when formatting a pattern match warning, we'd case split on a
wildcard match such as
```hs
foo :: [a] -> [a]
foo [] = []
foo xs = ys
where
(_, ys@(_:_)) = splitAt 0 xs
-- Pattern match(es) are non-exhaustive
-- In a pattern binding:
-- Patterns not matched:
-- ([], [])
-- ((_:_), [])
```
But that's quite verbose and distracts from which part of the pattern was
actually the inexhaustive one. We'd prefer a wildcard for the first pair
component here, like it used to be in GHC 8.8.
On the other hand, case splitting is pretty handy for `-XEmptyCase` to know the
different constructors we could've matched on:
```hs
f :: Bool -> ()
f x = case x of {}
-- Pattern match(es) are non-exhaustive
-- In a pattern binding:
-- Patterns not matched:
-- False
-- True
```
The solution is to communicate that we want a top-level case split to
`generateInhabitingPatterns` for `-XEmptyCase`, which is exactly what
this patch arranges. Details in `Note [Case split inhabiting patterns]`.
Fixes #20642.
|
| |
|
|
|
|
|
|
|
| |
terminfo now requires term.h but previously neither build system offered
any way to add the containing directory to the include search path. Fix
this in Hadrian.
Also adds libnuma includes to global include search path as it was
inexplicably missing earlier.
|
| |
|
|
| |
We repeated this idiom quite a few times. Give it a name.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #20541 by making mkTyConApp do more sharing of types.
In particular, replace
* BoxedRep Lifted ==> LiftedRep
* BoxedRep Unlifted ==> UnliftedRep
* TupleRep '[] ==> ZeroBitRep
* TYPE ZeroBitRep ==> ZeroBitType
In each case, the thing on the right is a type synonym
for the thing on the left, declared in ghc-prim:GHC.Types.
See Note [Using synonyms to compress types] in GHC.Core.Type.
The synonyms for ZeroBitRep and ZeroBitType are new, but absolutely
in the same spirit as the other ones. (These synonyms are mainly
for internal use, though the programmer can use them too.)
I also renamed GHC.Core.Ty.Rep.isVoidTy to isZeroBitTy, to be
compatible with the "zero-bit" nomenclature above. See discussion
on !6806.
There is a tricky wrinkle: see GHC.Core.Types
Note [Care using synonyms to compress types]
Compiler allocation decreases by up to 0.8%.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, we improve some of the rules around -I include dirs, and CPP
opts.
Then, we just specify the RTS's include dirs normally (locally per the
package and in the package conf), and then everything should work
normally.
The primops.txt.pp rule needs no extra include dirs at all, as it no
longer bakes in a target platfom.
Reverts some of the extra stage arguments I added in
05419e55cab272ed39790695f448b311f22669f7, as they are no longer needed.
|
| |
|
|
|
| |
Reduce a bit of duplication and a manual step when running builds
manually.
|
| |
|
|
|
| |
Previously we called error, which just prints an error, rather than
fail, which actually fails.
|
| |
|
|
|
| |
This makes it easier to invoke ci.sh on Darwin by teaching it to manage
the nix business.
|
| |
|
|
|
| |
A potential contributor said that they weren't aware of
ghc-proposals. This might increase visibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many small things to fix:
* Hadrian: platform triple is "x86_64-w64-mingw32" and this wasn't recognized by
Hadrian (note "w64" instead of "unknown")
* Hadrian was using the build platform ("isWindowsHost") to detect
the use of the Windows toolchain, which was wrong. We now use the
"targetOs" setting.
* Hadrian was doing the same thing for Darwin so we fixed both at once,
even if cross-compilation to Darwin is unlikely to happen afaik (cf
"osxHost" vs "osxTarget" changes)
* Hadrian: libffi name was computed in two different places and one of
them wasn't taking the different naming on Windows into account.
* Hadrian was passing "-Irts/include" when building the stage1 compiler
leading to the same error as in #18143 (which is using make).
stage1's RTS is stage0's one so mustn't do this.
* Hadrian: Windows linker doesn't seem to support "-zorigin" so we
don't pass it (similarly to Darwin)
* Hadrian: hsc2hs in cross-compilation mode uses a trick (taken from
autoconf): it defines "static int test_array[SOME_EXPR]" where
SOME_EXPR is a constant expression. However GCC reports an error
because SOME_EXPR is supposedly not constant. This is fixed by using
another method enabled with the `--via-asm` flag of hsc2hs. It has been
fixed in `make` build system (5f6fcf7808b16d066ad0fb2068225b3f2e8363f7)
but not in Hadrian.
* Hadrian: some packages are specifically built only on Windows but they
shouldn't be when building a cross-compiler (`touchy` and
`ghci-wrapper`). We now correctly detect this case and disable these
packages.
* Base: we use `iNVALID_HANDLE_VALUE` in a few places. It fixed some
hsc2hs issues before we switched to `--via-asm` (see above). I've kept
these changes are they make the code nicer.
* Base: `base`'s configure tries to detect if it is building for Windows
but for some reason the `$host_alias` value is `x86_64-windows` in my
case and it wasn't properly detected.
* Base: libraries/base/include/winio_structs.h imported "Windows.h" with
a leading uppercase. It doesn't work on case-sensitive systems when
cross-compiling so we have to use "windows.h".
* RTS: rts/win32/ThrIOManager.c was importin "rts\OSThreads.h" but this
path isn't valid when cross-compiling. We replaced "\" with "/".
* DeriveConstants: this tool derives the constants from the target
RTS header files. However these header files define `StgAsyncIOResult`
only when `mingw32_HOST_OS` is set hence it seems we have to set it
explicitly.
Note that deriveConstants is called more than once (why? there is
only one target for now so it shouldn't) and in the second case this
value is correctly defined (probably coming indirectly from the import
of "rts/PosixSource.h"). A better fix would probably be to disable the
unneeded first run of deriveconstants.
|
| |
|
|
|
| |
I've already fixed this 7 months ago in the comments of #16780 but it
never got merged. Now we need this for #20657 too.
|
| |
|
|
|
| |
As GHC has become target agnostic, we've left behind some now-useless
logic in both build systems.
|
| |
|
|
|
|
| |
These dirs should not be included in all stages. Instead make the
per-stage `BUILD_*_INCLUDE_DIR` "plural" to insert `rts/include` in the
right place.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the `deriving` machinery was very loosey-goosey about how it used
the types of data constructor fields when generating code. It would usually
just consult `dataConOrigArgTys`, which returns the _uninstantiated_ field
types of each data constructor. Usually, you can get away with this, but
issues #20375 and #20387 revealed circumstances where this approach fails.
Instead, when generated code for a stock-derived instance
`C (T arg_1 ... arg_n)`, one must take care to instantiate the field types of
each data constructor with `arg_1 ... arg_n`. The particulars of how this is
accomplished is described in the new
`Note [Instantiating field types in stock deriving]` in
`GHC.Tc.Deriv.Generate`. Some highlights:
* `DerivInstTys` now has a new `dit_dc_inst_arg_env :: DataConEnv [Type]`
field that caches the instantiated field types of each data constructor.
Whenever we need to consult the field types somewhere in `GHC.Tc.Deriv.*`
we avoid using `dataConOrigArgTys` and instead look it up in
`dit_dc_inst_arg_env`.
* Because `DerivInstTys` now stores the instantiated field types of each
constructor, some of the details of the `GHC.Tc.Deriv.Generics.mkBindsRep`
function were able to be simplified. In particular, we no longer need to
apply a substitution to instantiate the field types in a `Rep(1)` instance,
as that is already done for us by `DerivInstTys`. We still need a
substitution to implement the "wrinkle" section of
`Note [Generating a correctly typed Rep instance]`, but the code is
nevertheless much simpler than before.
* The `tyConInstArgTys` function has been removed in favor of the new
`GHC.Core.DataCon.dataConInstUnivs` function, which is really the proper tool
for the job. `dataConInstUnivs` is much like `tyConInstArgTys` except that it
takes a data constructor, not a type constructor, as an argument, and it adds
extra universal type variables from that data constructor at the end of the
returned list if need be. `dataConInstUnivs` takes care to instantiate the
kinds of the universal type variables at the end, thereby avoiding a bug in
`tyConInstArgTys` discovered in
https://gitlab.haskell.org/ghc/ghc/-/issues/20387#note_377037.
Fixes #20375. Fixes #20387.
|
| |
|
|
|
| |
`DataConEnv` will prove to be useful in another place besides
`GHC.Core.Opt.SpecConstr` in a follow-up commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
Various functions in GHC.Tc.Deriv.* were passing around `TyCon`s and
`[Type]`s that ultimately come from the same `DerivInstTys`. This patch
moves the definition of `DerivInstTys` to `GHC.Tc.Deriv.Generate` so that
all of these `TyCon` and `[Type]` arguments can be consolidated into a
single `DerivInstTys`. Not only does this make the code easier to read
(in my opinion), this will also be important in a subsequent commit where we
need to add another field to `DerivInstTys` that will also be used from
`GHC.Tc.Deriv.Generate` and friends.
|
| |
|
|
| |
This allows us to clean up the rts include dirs in the package conf.
|
| | |
|
| |
|
|
|
|
|
| |
Before we were violating the convention of every other package. This
fixes that. It matches the changes made in
d5de970dafd5876ef30601697576167f56b9c132 to the location of the files in
the repo.
|
| |
|
|
|
| |
This shouldn't be here. It wasn't causing a problem because this header
was only used from Haskell, but still.
|
