1. 14 May, 2019 7 commits
    • Vladislav Zavialov's avatar
      Guard CUSKs behind a language pragma · a5fdd185
      Vladislav Zavialov authored
      GHC Proposal #36 describes a transition plan away from CUSKs and to
      top-level kind signatures:
      
      1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs
         as they currently exist.
      2. We turn off the -XCUSKs extension in a few releases and remove it
         sometime thereafter.
      
      This patch implements phase 1 of this plan, introducing a new language
      extension to control whether CUSKs are enabled. When top-level kind
      signatures are implemented, we can transition to phase 2.
      a5fdd185
    • Vladislav Zavialov's avatar
      c72c369b
    • Oleg Grenrus's avatar
      Update terminal title while running test-suite · 5cf8032e
      Oleg Grenrus authored
      Useful progress indicator even when `make test VERBOSE=1`,
      and when you do something else, but have terminal title visible.
      5cf8032e
    • John Ericson's avatar
      Remove all target-specific portions of Config.hs · e529c65e
      John Ericson authored
      1. If GHC is to be multi-target, these cannot be baked in at compile
         time.
      
      2. Compile-time flags have a higher maintenance than run-time flags.
      
      3. The old way makes build system implementation (various bootstrapping
         details) with the thing being built. E.g. GHC doesn't need to care
         about which integer library *will* be used---this is purely a crutch
         so the build system doesn't need to pass flags later when using that
         library.
      
      4. Experience with cross compilation in Nixpkgs has shown things work
         nicer when compiler's can *optionally* delegate the bootstrapping the
         package manager. The package manager knows the entire end-goal build
         plan, and thus can make top-down decisions on bootstrapping. GHC can
         just worry about GHC, not even core library like base and ghc-prim!
      e529c65e
    • John Ericson's avatar
      Dont refer to `cLeadingUnderscore` in test · f9e4ea40
      John Ericson authored
      Can't use this config entry because it's about to go away
      f9e4ea40
    • John Ericson's avatar
      hadrian: Make settings stage specific · 015a21b8
      John Ericson authored
      015a21b8
    • KevinBuhr's avatar
      Add regression test for old parser issue #504 · 357be128
      KevinBuhr authored
      357be128
  2. 13 May, 2019 1 commit
  3. 10 May, 2019 5 commits
  4. 08 May, 2019 9 commits
  5. 07 May, 2019 3 commits
  6. 06 May, 2019 4 commits
  7. 05 May, 2019 2 commits
  8. 04 May, 2019 5 commits
  9. 03 May, 2019 4 commits
    • Ryan Scott's avatar
      Make equality constraints in kinds invisible · cc495d57
      Ryan Scott authored
      Issues #12102 and #15872 revealed something strange about the way GHC
      handles equality constraints in kinds: it treats them as _visible_
      arguments! This causes a litany of strange effects, from strange
      error messages
      (ghc/ghc#12102 (comment 169035))
      to bizarre `Eq#`-related things leaking through to GHCi output, even
      without any special flags enabled.
      
      This patch is an attempt to contain some of this strangeness.
      In particular:
      
      * In `TcHsType.etaExpandAlgTyCon`, we propagate through the
        `AnonArgFlag`s of any `Anon` binders. Previously, we were always
        hard-coding them to `VisArg`, which meant that invisible binders
        (like those whose kinds were equality constraint) would mistakenly
        get flagged as visible.
      * In `ToIface.toIfaceAppArgsX`, we previously assumed that the
        argument to a `FunTy` always corresponding to a `Required`
        argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
        `VisArg` to `Required` and `Inv...
      cc495d57
    • Ömer Sinan Ağacan's avatar
      Fix interface version number printing in --show-iface · 87bc954a
      Ömer Sinan Ağacan authored
      Before
      
          Version: Wanted [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5],
                   got    [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5]
      
      After
      
          Version: Wanted 809020190425,
                   got    809020190425
      87bc954a
    • Ningning Xie's avatar
      9b59e126
    • Vladislav Zavialov's avatar
      Pattern/expression ambiguity resolution · 52fc2719
      Vladislav Zavialov authored
      This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
      from 'HsExpr' by using the ambiguity resolution system introduced
      earlier for the command/expression ambiguity.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a pattern, for example:
      
      	do { Con a b <- x } -- 'Con a b' is a pattern
      	do { Con a b }      -- 'Con a b' is an expression
      
      Until we encounter binding syntax (<-) we don't know whether to parse
      'Con a b' as an expression or a pattern.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)
      
      This meant polluting 'HsExpr' with pattern-related constructors. In
      other words, limitations of the parser were affecting the AST, and all
      other code (the renamer, the typechecker) had to deal with these extra
      constructors.
      
      We fix this abstraction leak by parsing into an overloaded
      representation:
      
      	class DisambECP b where ...
      	newtype ECP = ...
      52fc2719