1. 18 Nov, 2021 3 commits
  2. 17 Nov, 2021 9 commits
    • MorrowM's avatar
      Improve handling of import statements in GHCi (#20473) · 7850142c
      MorrowM authored
      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).
    • arata, mizuki's avatar
      bitReverse functions in GHC.Word are since base-, not · 16d86b97
      arata, mizuki authored
      They were added in 33173a51, which constitutes GHC 8.10.1 / base-
    • Andrew Pritchard's avatar
      Provide in-line kind signatures for Data.Type.Ord.Compare. · 7bcd91f4
      Andrew Pritchard authored
      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.
    • Andrew Pritchard's avatar
    • Sebastian Graf's avatar
      testsuite: Refactor pmcheck all.T · c591ab1f
      Sebastian Graf authored
    • Sebastian Graf's avatar
      Pmc: Don't case split on wildcard matches (#20642) · 29086749
      Sebastian Graf authored
      Since 8.10, when formatting a pattern match warning, we'd case split on a
      wildcard match such as
      foo :: [a] -> [a]
      foo [] = []
      foo xs = ys
        (_, 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:
      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.
    • Ben Gamari's avatar
      hadrian: Ensure that term.h is in include search path · 4cec6cf2
      Ben Gamari authored
      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.
    • Ben Gamari's avatar
      hadrian: Factor out --extra-*-dirs=... pattern · 20a4f251
      Ben Gamari authored
      We repeated this idiom quite a few times. Give it a name.
    • Ben Gamari's avatar
      Increase type sharing · 083a7583
      Ben Gamari authored
      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%.
  3. 16 Nov, 2021 4 commits
  4. 15 Nov, 2021 8 commits
    • Richard Eisenberg's avatar
      Link to ghc-proposals repo from README · cc635da1
      Richard Eisenberg authored
      A potential contributor said that they weren't aware of
      ghc-proposals. This might increase visibility.
    • Sylvain Henry's avatar
      Hadrian: fix windows cross-build (#20657) · d9f54905
      Sylvain Henry authored
      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
      * 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
        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.
    • Sylvain Henry's avatar
      Fix windres invocation · 3302f42a
      Sylvain Henry authored
      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.
    • John Ericson's avatar
      Delete dead code knobs for building GHC itself · b679721a
      John Ericson authored
      As GHC has become target agnostic, we've left behind some now-useless
      logic in both build systems.
    • John Ericson's avatar
      Make: Get rid of GHC_INCLUDE_DIRS · 25d36c31
      John Ericson authored
      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.
    • Ryan Scott's avatar
      Instantiate field types properly in stock-derived instances · 3e5f0595
      Ryan Scott authored
      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
      * 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
        ghc/ghc#20387 (comment 377037).
      Fixes #20375. Fixes #20387.
    • Ryan Scott's avatar
      Refactoring: Move DataConEnv to GHC.Core.DataCon · 564a19af
      Ryan Scott authored
      `DataConEnv` will prove to be useful in another place besides
      `GHC.Core.Opt.SpecConstr` in a follow-up commit.
    • Ryan Scott's avatar
      Refactoring: Consolidate some arguments with DerivInstTys · aa372972
      Ryan Scott authored
      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.
  5. 13 Nov, 2021 16 commits