1. 06 Nov, 2020 5 commits
    • Krzysztof Gogolewski's avatar
      2753e13a
    • Ben Gamari's avatar
      rts/Sanity: Avoid nasty race in weak pointer sanity-checking · b1d2c1f3
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      See Note [Racing weak pointer evacuation] for all of the gory details.
      b1d2c1f3
    • Moritz Angermann's avatar
      [AArch64] Aarch64 Always PIC · 2cb87909
      Moritz Angermann authored and Marge Bot's avatar Marge Bot committed
      2cb87909
    • Sylvain Henry's avatar
      Refactor -dynamic-too handling · c85f4928
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      1) Don't modify DynFlags (too much) for -dynamic-too: now when we
         generate dynamic outputs for "-dynamic-too", we only set "dynamicNow"
         boolean field in DynFlags instead of modifying several other fields.
         These fields now have accessors that take dynamicNow into account.
      
      2) Use DynamicTooState ADT to represent -dynamic-too state. It's much
         clearer than the undocumented "DynamicTooConditional" that was used
         before.
      
      As a result, we can finally remove the hscs_iface_dflags field in
      HscRecomp. There was a comment on this field saying:
      
         "FIXME (osa): I don't understand why this is necessary, but I spent
         almost two days trying to figure this out and I couldn't .. perhaps
         someone who understands this code better will remove this later."
      
      I don't fully understand the details, but it was needed because of the
      changes made to the DynFlags for -dynamic-too.
      
      There is still something very dubious in GHC.Iface.Recomp: we have to
      disable the "dynamicNow" flag at some point for some Backpack's "heinous
      hack" to continue to work. It may be because interfaces for indefinite
      units are always non-dynamic, or because we mix and match dynamic and
      non-dynamic interfaces (#9176), or something else, who knows?
      c85f4928
    • Ryan Scott's avatar
      Replace HsImplicitBndrs with HsOuterTyVarBndrs · e07e383a
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      
      
      This refactors the GHC AST to remove `HsImplicitBndrs` and replace it with
      `HsOuterTyVarBndrs`, a type which records whether the outermost quantification
      in a type is explicit (i.e., with an outermost, invisible `forall`) or
      implicit. As a result of this refactoring, it is now evident in the AST where
      the `forall`-or-nothing rule applies: it's all the places that use
      `HsOuterTyVarBndrs`. See the revamped `Note [forall-or-nothing rule]` in
      `GHC.Hs.Type` (previously in `GHC.Rename.HsType`).
      
      Moreover, the places where `ScopedTypeVariables` brings lexically scoped type
      variables into scope are a subset of the places that adhere to the
      `forall`-or-nothing rule, so this also makes places that interact with
      `ScopedTypeVariables` easier to find. See the revamped
      `Note [Lexically scoped type variables]` in `GHC.Hs.Type` (previously in
      `GHC.Tc.Gen.Sig`).
      
      `HsOuterTyVarBndrs` are used in type signatures (see `HsOuterSigTyVarBndrs`)
      and type family equations (see `HsOuterFamEqnTyVarBndrs`). The main difference
      between the former and the latter is that the former cares about specificity
      but the latter does not.
      
      There are a number of knock-on consequences:
      
      * There is now a dedicated `HsSigType` type, which is the combination of
        `HsOuterSigTyVarBndrs` and `HsType`. `LHsSigType` is now an alias for an
        `XRec` of `HsSigType`.
      * Working out the details led us to a substantial refactoring of
        the handling of explicit (user-written) and implicit type-variable
        bindings in `GHC.Tc.Gen.HsType`.
      
        Instead of a confusing family of higher order functions, we now
        have a local data type, `SkolemInfo`, that controls how these
        binders are kind-checked.
      
        It remains very fiddly, not fully satisfying. But it's better
        than it was.
      
      Fixes #16762. Bumps the Haddock submodule.
      
      Co-authored-by: default avatarSimon Peyton Jones <simonpj@microsoft.com>
      Co-authored-by: Richard Eisenberg's avatarRichard Eisenberg <rae@richarde.dev>
      Co-authored-by: Zubin's avatarZubin Duggal <zubin@cmi.ac.in>
      e07e383a
  2. 05 Nov, 2020 2 commits
    • Ryan Scott's avatar
      Add a regression test for #18920 · 2125b1d6
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      Commit f594a68a
      (`Use level numbers for generalisation`) ended up fixing #18920. Let's add a
      regression test to ensure that it stays fixed.
      
      Fixes #18920.
      2125b1d6
    • vdukhovni's avatar
      Naming, value types and tests for Addr# atomics · 17d5c518
      vdukhovni authored and Marge Bot's avatar Marge Bot committed
      The atomic Exchange and CAS operations on integral types are updated to
      take and return more natural `Word#` rather than `Int#` values.  These
      are bit-block not arithmetic operations, and the sign bit plays no
      special role.
      
      Standardises the names to `atomic<OpType><ValType>Addr#`, where `OpType` is one
      of `Cas` or `Exchange` and `ValType` is presently either `Word` or `Addr`.
      Eventually, variants for `Word32` and `Word64` can and should be added,
      once #11953 and related issues (e.g. #13825) are resolved.
      
      Adds tests for `Addr#` CAS that mirror existing tests for
      `MutableByteArray#`.
      17d5c518
  3. 04 Nov, 2020 3 commits
  4. 03 Nov, 2020 12 commits
    • Sylvain Henry's avatar
      Bignum: make GMP's bignat_add not recursive · bff74de7
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      bignat_add was a loopbreaker with an INLINE pragma (spotted by
      @mpickering). This patch makes it non recursive to avoid the issue.
      bff74de7
    • Sylvain Henry's avatar
      Constant-folding: don't pass through GHC's Int/Word (fix #11704) · 37f0434d
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      Constant-folding rules for integerToWord/integerToInt were performing
      the following coercions at compilation time:
      
          integerToWord: target's Integer -> ghc's Word -> target's Word
          integerToInt : target's Integer -> ghc's Int -> target's Int
      
      1) It was wrong for cross-compilers when GHC's word size is smaller than
         the target one. This patch avoids passing through GHC's word-sized
         types:
      
          integerToWord: target's Integer -> ghc's Integer -> target's Word
          integerToInt : target's Integer -> ghc's Integer -> target's Int
      
      2) Additionally we didn't wrap the target word/int literal to make it
         fit into the target's range! This broke the invariant of literals
         only containing values in range.
      
         The existing code is wrong only with a 64-bit cross-compiling GHC,
         targeting a 32-bit platform, and performing constant folding on a
         literal that doesn't fit in a 32-bit word. If GHC was built with
         DEBUG, the assertion in GHC.Types.Literal.mkLitWord would fail.
         Otherwise the bad transformation would go unnoticed.
      37f0434d
    • Sylvain Henry's avatar
      Hadrian: don't fail if ghc-tarballs dir doesn't exist · 3486ebe6
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      3486ebe6
    • Alan Zimmerman's avatar
      Restrict Linear arrow %1 to exactly literal 1 only · 616bec0d
      Alan Zimmerman authored and Marge Bot's avatar Marge Bot committed
      This disallows `a %001 -> b`, and makes sure the type literal is
      printed from its SourceText so it is clear why.
      
      Closes #18888
      616bec0d
    • Sylvain Henry's avatar
      Linker: reorganize linker related code · 14ce454f
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      Move linker related code into GHC.Linker. Previously it was scattered
      into GHC.Unit.State, GHC.Driver.Pipeline, GHC.Runtime.Linker, etc.
      
      Add documentation in GHC.Linker
      14ce454f
    • Matthew Pickering's avatar
      Update inlining flags documentation · 78f2767d
      Matthew Pickering authored and Marge Bot's avatar Marge Bot committed
      78f2767d
    • Ben Gamari's avatar
      hadrian: Don't capture RunTest output · 1370eda7
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      There are a few reasons why capturing the output of the RunTest builder
      is undesirable:
      
       * there is a large amount of output which then gets unnecessarily
         duplicated by Hadrian if the builder fails
      
       * the output may contain codepoints which are unrepresentable in the
         current codepage on Windows, causing Hadrian to crash
      
       * capturing the output causes the testsuite driver to disable
         its colorisation logic, making the output less legible.
      1370eda7
    • Simon Peyton Jones's avatar
      Expand type synonyms with :kind! · a9e5f52c
      Simon Peyton Jones authored and Marge Bot's avatar Marge Bot committed
      
      
      The User's Guide claims that `:kind!` should expand type synonyms,
      but GHCi wasn't doing this in practice. Let's just update the implementation
      to match the specification in the User's Guide.
      
      Fixes #13795. Fixes #18828.
      
      Co-authored-by: Ryan Scott's avatarRyan Scott <ryan.gl.scott@gmail.com>
      a9e5f52c
    • Ryan Scott's avatar
      Display results of GHC.Core.Lint.lint* functions consistently · bfb1e272
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      Previously, the functions in `GHC.Core.Lint` used a patchwork of
      different ways to display Core Lint errors:
      
      * `lintPassResult` (which is the source of most Core Lint errors) renders
        Core Lint errors with a distinctive banner (e.g.,
        `*** Core Lint errors : in result of ... ***`) that sets them apart
        from ordinary GHC error messages.
      * `lintAxioms`, in contrast, uses a completely different code path that
        displays Core Lint errors in a rather confusing manner. For example,
        the program in #18770 would give these results:
      
        ```
        Bug.hs:1:1: error:
            Bug.hs:12:1: warning:
                Non-*-like kind when *-like expected: RuntimeRep
                when checking the body of forall: 'TupleRep '[r]
                In the coercion axiom Bug.N:T :: []. Bug.T ~_R Any
                Substitution: [TCvSubst
                                 In scope: InScope {r}
                                 Type env: [axl :-> r]
                                 Co env: []]
          |
        1 | {-# LANGUAGE DataKinds #-}
          | ^
        ```
      * Further digging reveals that `GHC.IfaceToCore` displays Core Lint
        errors for iface unfoldings as though they were a GHC panic. See, for
        example, this excerpt from #17723:
      
        ```
        ghc: panic! (the 'impossible' happened)
          (GHC version 8.8.2 for x86_64-unknown-linux):
                Iface Lint failure
          In interface for Lib
          ...
        ```
      
      This patch makes all of these code paths display Core Lint errors and
      warnings consistently. I decided to adopt the conventions that
      `lintPassResult` currently uses, as they appear to have been around the
      longest (and look the best, in my subjective opinion). We now use the
      `displayLintResult` function for all three scenarios mentioned above.
      For example, here is what the Core Lint error for the program in #18770 looks
      like after this patch:
      
      ```
      [1 of 1] Compiling Bug              ( Bug.hs, Bug.o )
      *** Core Lint errors : in result of TcGblEnv axioms ***
      Bug.hs:12:1: warning:
          Non-*-like kind when *-like expected: RuntimeRep
          when checking the body of forall: 'TupleRep '[r_axn]
          In the coercion axiom N:T :: []. T ~_R Any
          Substitution: [TCvSubst
                           In scope: InScope {r_axn}
                           Type env: [axn :-> r_axn]
                           Co env: []]
      *** Offending Program ***
      axiom N:T :: T = Any -- Defined at Bug.hs:12:1
      *** End of Offense ***
      
      <no location info>: error:
      Compilation had errors
      ```
      
      Fixes #18770.
      bfb1e272
    • David Eichmann's avatar
      RtsAPI: pause and resume the RTS · 81006a06
      David Eichmann authored and Marge Bot's avatar Marge Bot committed
      
      
      The `rts_pause` and `rts_resume` functions have been added to `RtsAPI.h` and
      allow an external process to completely pause and resume the RTS.
      
      Co-authored-by: Sven Tennie's avatarSven Tennie <sven.tennie@gmail.com>
      Co-authored-by: Matthew Pickering's avatarMatthew Pickering <matthewtpickering@gmail.com>
      Co-authored-by: default avatarBen Gamari <bgamari.foss@gmail.com>
      81006a06
    • Ben Gamari's avatar
      Document that ccall convention doesn't support varargs · 0b772221
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      We do not support foreign "C" imports of varargs functions. While this
      works on amd64, in general the platform's calling convention may need
      more type information that our Cmm representation can currently provide.
      For instance, this is the case with Darwin's AArch64 calling convention.
      Document this fact in the users guide and fix T5423 which makes use of a
      disallowed foreign import.
      
      Closes #18854.
      0b772221
    • GHC GitLab CI's avatar
      testsuite: Add --top flag to driver · 4ce2f7d6
      GHC GitLab CI authored and Marge Bot's avatar Marge Bot committed
      This allows us to make `config.top` a proper Path. Previously it was a
      str, which caused the Ghostscript detection logic to break.
      4ce2f7d6
  5. 01 Nov, 2020 4 commits
  6. 31 Oct, 2020 8 commits
    • Andrzej Rybczak's avatar
      Add testcase for #816 · eb368078
      Andrzej Rybczak authored and Marge Bot's avatar Marge Bot committed
      eb368078
    • Tamar Christina's avatar
      winio: Fix unused variables warnings · cb1f755c
      Tamar Christina authored and Marge Bot's avatar Marge Bot committed
      cb1f755c
    • Sylvain Henry's avatar
      Move loadDecl into IfaceToCore · 08e6993a
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      08e6993a
    • Ben Gamari's avatar
      primops: Generate ByteArray# index/read/write primops · b4278a41
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Previously these were mostly undocumented and was ripe for potential
      inconsistencies.
      b4278a41
    • Ben Gamari's avatar
      primops.txt.pp: Move ByteArray# primops to separate file · d5a53c1a
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      This file will be generated.
      d5a53c1a
    • Sylvain Henry's avatar
      Simplify constant-folding (#18032) · 730ef38f
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      See #18032 for the details.
      
      * Use `Lit (LitNumber _ i)` instead of `isLitValue_maybe` which does
        more work but that is not needed for constant-folding
      * Don't export `GHC.Types.Literal.isLitValue_maybe`
      * Kill `GHC.Types.Literal.isLitValue` which isn't used
      730ef38f
    • Sylvain Henry's avatar
      Refactor numeric constant folding rules · a98593f0
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      Avoid the use of global pattern synonyms.
      
      1) I think it's going to be helpful to implement constant folding for
         other numeric types, especially Natural which doesn't have a wrapping
         behavior. We'll have to refactor these rules even more so we'd better
         make them less cryptic.
      
      2) It should also be slightly faster because global pattern synonyms
         matched operations for every numeric types instead of the current one:
         e.g., ":**:" pattern was matching multiplication for both Int# and
         Word# types. As we will probably want to implement constant folding
         for other numeric types (Int8#, Int16#, etc.), it is more efficient
         to only match primops for a given type as we do now.
      a98593f0
    • Ryan Scott's avatar
      Make typechecker equality consider visibility in ForAllTys · 57c3db96
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      Previously, `can_eq_nc'` would equate `ForAllTy`s regardless of their
      `ArgFlag`, including `forall i -> i -> Type` and `forall i. i -> Type`! To fix
      this, `can_eq_nc'` now uses the `sameVis` function to first check if the
      `ArgFlag`s are equal modulo specificity. I have also updated `tcEqType`'s
      implementation to match this behavior. For more explanation on the "modulo
      specificity" part, see the new `Note [ForAllTy and typechecker equality]`
      in `GHC.Tc.Solver.Canonical`.
      
      While I was in town, I fixed some related documentation issues:
      
      * I added `Note [Typechecker equality]` to `GHC.Tc.Utils.TcType` to describe
        what exactly distinguishes `can_eq_nc'` and `tcEqType` (which implement
        typechecker equality) from `eqType` (which implements definitional equality,
        which does not care about the `ArgFlags` of `ForAllTy`s at all).
      * The User's Guide had some outdated prose on the specified/inferred
        distinction being different for types and kinds, a holdover from #15079. This
        is no longer the case on today's GHC, so I removed this prose, added some new
        prose to take its place, and added a regression test for the programs in
        #15079.
      * The User's Guide had some _more_ outdated prose on inferred type variables
        not being allowed in `default` type signatures for class methods, which is no
        longer true as of the resolution of #18432.
      * The related `Note [Deferred Unification]` was being referenced as
        `Note [Deferred unification]` elsewhere, which made it harder to `grep`
        for. I decided to change the name of the Note to `Deferred unification`
        for consistency with the capitalization style used for most other Notes.
      
      Fixes #18863.
      57c3db96
  7. 30 Oct, 2020 3 commits
    • Ryan Scott's avatar
      Split HsConDecl{H98,GADT}Details · 31fcb55f
      Ryan Scott authored and Marge Bot's avatar Marge Bot committed
      Haskell98 and GADT constructors both use `HsConDeclDetails`, which includes
      `InfixCon`. But `InfixCon` is never used for GADT constructors, which results
      in an awkward unrepresentable state. This removes the unrepresentable state by:
      
      * Renaming the existing `HsConDeclDetails` synonym to `HsConDeclH98Details`,
        which emphasizes the fact that it is now only used for Haskell98-style data
        constructors, and
      * Creating a new `HsConDeclGADTDetails` data type with `PrefixConGADT` and
        `RecConGADT` constructors that closely resemble `PrefixCon` and `InfixCon`
        in `HsConDeclH98Details`. The key difference is that `HsConDeclGADTDetails`
        lacks any way to represent infix constructors.
      
      The rest of the patch is refactoring to accommodate the new structure of
      `HsConDecl{H98,GADT}Details`. Some highlights:
      
      * The `getConArgs` and `hsConDeclArgTys` functions have been removed, as
        there is no way to implement these functions uniformly for all
        `ConDecl`s. For the most part, their previous call sites now
        pattern match on the `ConDecl`s directly and do different things for
        `ConDeclH98`s and `ConDeclGADT`s.
      
        I did introduce one new function to make the transition easier:
        `getRecConArgs_maybe`, which extracts the arguments from a `RecCon(GADT)`.
        This is still possible since `RecCon(GADT)`s still use the same representation
        in both `HsConDeclH98Details` and `HsConDeclGADTDetails`, and since the
        pattern that `getRecConArgs_maybe` implements is used in several places,
        I thought it worthwhile to factor it out into its own function.
      * Previously, the `con_args` fields in `ConDeclH98` and `ConDeclGADT` were
        both of type `HsConDeclDetails`. Now, the former is of type
        `HsConDeclH98Details`, and the latter is of type `HsConDeclGADTDetails`,
        which are distinct types. As a result, I had to rename the `con_args` field
        in `ConDeclGADT` to `con_g_args` to make it typecheck.
      
        A consequence of all this is that the `con_args` field is now partial, so
        using `con_args` as a top-level field selector is dangerous. (Indeed, Haddock
        was using `con_args` at the top-level, which caused it to crash at runtime
        before I noticed what was wrong!) I decided to add a disclaimer in the 9.2.1
        release notes to advertise this pitfall.
      
      Fixes #18844. Bumps the `haddock` submodule.
      31fcb55f
    • vdukhovni's avatar
      [skip ci] Fix typo in `callocBytes` haddock. · 9902d9ec
      vdukhovni authored
      9902d9ec
    • Richard Eisenberg's avatar
      Remove unnecessary gender from comments/docs · 7f8be3eb
      Richard Eisenberg authored and Marge Bot's avatar Marge Bot committed
      While, say, alternating "he" and "she" in sequential writing
      may be nicer than always using "they", reading code/documentation
      is almost never sequential. If this small change makes individuals
      feel more welcome in GHC's codebase, that's a good thing.
      7f8be3eb
  8. 29 Oct, 2020 3 commits
    • Ryan Scott's avatar
      Check for large tuples more thoroughly · 2ef2fac4
      Ryan Scott authored
      This fixes #18723 by:
      
      * Moving the existing `GHC.Tc.Gen.HsType.bigConstraintTuple` validity
        check to `GHC.Rename.Utils.checkCTupSize` for consistency with
        `GHC.Rename.Utils.checkTupSize`, and
      * Using `check(C)TupSize` when checking tuple _types_, in addition
        to checking names, expressions, and patterns.
      
      Note that I put as many of these checks as possible in the typechecker so
      that GHC can properly distinguish between boxed and constraint tuples. The
      exception to this rule is checking names, which I perform in the renamer
      (in `GHC.Rename.Env`) so that we can rule out `(,, ... ,,)` and
      `''(,, ... ,,)` alike in one fell swoop.
      
      While I was in town, I also removed the `HsConstraintTuple` and
      `HsBoxedTuple` constructors of `HsTupleSort`, which are functionally
      unused. This requires a `haddock` submodule bump.
      2ef2fac4
    • Sylvain Henry's avatar
      GC: Avoid data race (#18717, #17964) · 22f5d9a9
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      22f5d9a9
    • Sylvain Henry's avatar
      Split GHC.Driver.Types · 0e9f6def
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      I was working on making DynFlags stateless (#17957), especially by
      storing loaded plugins into HscEnv instead of DynFlags. It turned out to
      be complicated because HscEnv is in GHC.Driver.Types but LoadedPlugin
      isn't: it is in GHC.Driver.Plugins which depends on GHC.Driver.Types. I
      didn't feel like introducing yet another hs-boot file to break the loop.
      
      Additionally I remember that while we introduced the module hierarchy
      (#13009) we talked about splitting GHC.Driver.Types because it contained
      various unrelated types and functions, but we never executed. I didn't
      feel like making GHC.Driver.Types bigger with more unrelated Plugins
      related types, so finally I bit the bullet and split GHC.Driver.Types.
      
      As a consequence this patch moves a lot of things. I've tried to put
      them into appropriate modules but nothing is set in stone.
      
      Several other things moved to avoid loops.
      
      * Removed Binary instances from GHC.Utils.Binary for random compiler
        things
      * Moved Typeable Binary instances into GHC.Utils.Binary.Typeable: they
        import a lot of things that users of GHC.Utils.Binary don't want to
        depend on.
      * put everything related to Units/Modules under GHC.Unit:
        GHC.Unit.Finder, GHC.Unit.Module.{ModGuts,ModIface,Deps,etc.}
      * Created several modules under GHC.Types: GHC.Types.Fixity, SourceText,
        etc.
      * Split GHC.Utils.Error (into GHC.Types.Error)
      * Finally removed GHC.Driver.Types
      
      Note that this patch doesn't put loaded plugins into HscEnv. It's left
      for another patch.
      
      Bump haddock submodule
      0e9f6def