| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
No-op assignments like R1 = R1 are not only wasteful. They can also
inhibit other optimizations like inlining assignments that read from
R1.
We now check for assignments being a no-op before and after we
simplify the RHS in Cmm sink which should eliminate most of these
no-ops.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is, rather unintuitively, part of the goal of making the packages
that make of the GHC distribution more freestanding. `ghcversion.h` is
very simple, so we easily can move it out of the main build systems
(make and Hadrian). By doing so, the RTS becomes less of a special case
to those build systems as the header, already existing in the source
tree, appears like any other.
We could do this with the upcomming RTS configure, but it hardly matters
because there is nothing platform-specific here, it is just versioning
information like the other files the top-level configure can be
responsible for.
|
| |
|
|
|
|
|
| |
This was accidentally added back in
28334b475a109bdeb8d53d58c48adb1690e2c9b4 after it is was no longer
needed by the compiler proper in
20956e5784fe43781d156dd7ab02f0bff4ab41fb.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Addresses #20623 by allowing draft MRs to fail linting jobs.
|
| |
|
|
|
| |
This was a simple (but long standing) error in simplArg,
revealed by #20639
|
| |
|
|
| |
/usr/bin/env doesn't work within a nix build.
|
| |
|
|
|
|
|
|
|
|
| |
In accordance with GHC Proposal #281 "Visible forall in types of terms":
For three releases before this change takes place, include a new
warning -Wforall-identifier in -Wdefault. This warning will be triggered
at definition sites (but not use sites) of forall as an identifier.
Updates the haddock submodule.
|
| |
|
|
|
|
|
|
|
|
| |
See new Note [Use only the best local instance] in
GHC.Tc.Solver.Interact.
This commit also refactors the InstSC/OtherSC mechanism
slightly.
Close #20582.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we reported things wrong with
f :: (Eq a, Ord a) => a -> Bool
f x = x == x
saying that Eq a was redundant. This is fixed now, along with
some simplification in Note [Replacement vs keeping]. There's
a tiny bit of extra complexity in setImplicationStatus, but
it's explained in Note [Tracking redundant constraints].
Close #20602
|
| |
|
|
|
| |
GHC should get everything it needs from the RTS, which for stage0 is the
"old" RTS that comes from the bootstrap compiler.
|
| | |
|
| |
|
|
| |
Fixes #20598, which is mostly a duplicate of #18824 but for GHC 9.2.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, these flags were passed when both compiling and linking
code. However, `-pie` and `-no-pie` are link-time-only options. Usually,
this does not cause issues, but when using Clang with `-Werror` set
results in errors:
clang: error: argument unused during compilation: '-nopie' [-Werror,-Wunused-command-line-argument]
This is unused by Clang because this flag has no effect at compile time
(it’s called `-nopie` internally by Clang but called `-no-pie` in GHC
for compatibility with GCC). Just passing these flags at linking time
resolves this.
Additionally, update #15319 hack to look for `-pgml` instead.
Because of the main change, the value of `-pgmc` does not matter when
checking for the workaround of #15319. However, `-pgml` *does* still
matter as not all `-pgml` values support `-no-pie`.
To cover all potential values, we assume that no custom `-pgml` values
support `-no-pie`. This means that we run the risk of not using
`-no-pie` when it is otherwise necessary for in auto-hardened
toolchains! This could be a problem at some point, but this workaround
was already introduced in 8d008b71 and we might as well continue
supporting it.
Likewise, mark `-pgmc-supports-no-pie` as deprecated and create a new
`-pgml-supports-no-pie`.
|
| |
|
|
|
|
|
|
|
|
| |
This saves a lot of repeated work on big dependency graphs.
-------------------------
Metric Decrease:
MultiLayerModules
T13719
-------------------------
|
| |
|
|
|
|
|
|
| |
Two reasons for this change:
1. Avoid computing the transitive dependencies when compiling each
module, this can save a lot of repeated work.
2. More robust to forthcoming changes to support multiple home units.
|
| |
|
|
| |
Fixes #20621
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The user guide wrongly stated that default methods should not
be included in hs-boot files. In fact, if the class is not left
abstract (no methods, no superclass constraints, ...) then the
defaults must be provided and match with those given in the .hs
file.
We add some tests for this, as there were no tests in the testsuite
that gave rise to the "missing default methods" error.
Fixes #20588
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- rename the function f4 to h1 for consistency with
the naming convention
- be more explicit about the difference between
`Int -> (forall a. a -> a)`
and
`forall a. Int -> (a -> a)`
- reorder the section to make it flow better
Fixes #20585
|
