- Nov 17, 2021
-
-
They were added in 33173a51, 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%.
-
- Nov 16, 2021
-
-
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 05419e55, 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.
-
- Nov 15, 2021
-
-
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 (5f6fcf78) 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. -
-
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 #20387 (comment 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.
-
- Nov 13, 2021
-
-
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 d5de970d 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.
-
-
-
-
-
-
-
-
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.
-
-
