Commits on Source (12)
-
-
-
Use `\min` instead of `min` to typeset it as an operator.
-
-
Due to #16604.
-
We also keep it as an artifact, like we do for non-Hadrian jobs, and list it as a junit report, so that the test results are reported in the GitLab UI for merge requests.
-
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 = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) } See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/pattern ambiguity. -
-
Ö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 -
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 (#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...
-
Get "Tables next to code" from the settings file instead.
-
Summary: There is no more use of the TABLES_NEXT_TO_CODE CPP macro in `compiler/`. GHCI_TABLES_NEXT_TO_CODE is also removed entirely. The default value of `tablesNextToCode` is calculated as before, but now users of the GHCI API can modify this flag. That said, GHC still is hardcoded to define TABLES_NEXT_TO_CODE based on that default value. This is bad, but neccessary until the remaining uses of TABLES_NEXT_TO_CODE get it from make/Hadrian. Reviewers: Subscribers: TerrorJack, rwbarton, carter GHC Trac Issues: #15548 Differential Revision: https://phabricator.haskell.org/D5082
This diff is collapsed.