[Git][ghc/ghc][wip/D5082] 12 commits: ErrUtils: Emit progress messages to eventlog

John Ericson gitlab at gitlab.haskell.org
Fri May 3 20:47:31 UTC 2019 


John Ericson pushed to branch wip/D5082 at Glasgow Haskell Compiler / GHC


Commits:
1bef62c3 by Ben Gamari at 2019-05-01T00:41:42Z
ErrUtils: Emit progress messages to eventlog

- - - - -
ebfa3528 by Ben Gamari at 2019-05-01T00:41:42Z
Emit GHC timing events to eventlog

- - - - -
4186b410 by Sven Tennie at 2019-05-03T17:40:36Z
Typeset Big-O complexities with Tex-style notation (#16090)

Use `\min` instead of `min` to typeset it as an operator.

- - - - -
9047f184 by Shayne Fletcher at 2019-05-03T18:54:50Z
Make Extension derive Bounded

- - - - -
0dde64f2 by Ben Gamari at 2019-05-03T18:54:50Z
testsuite: Mark concprog001 as fragile

Due to #16604.
- - - - -
8f929388 by Alp Mestanogullari at 2019-05-03T18:54:50Z
Hadrian: generate JUnit testsuite report in Linux CI job

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.

- - - - -
52fc2719 by Vladislav Zavialov at 2019-05-03T18:54:50Z
Pattern/expression ambiguity resolution

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.

- - - - -
9b59e126 by Ningning Xie at 2019-05-03T18:54:50Z
Only skip decls with CUSKs with PolyKinds on (fix #16609)

- - - - -
87bc954a by Ömer Sinan Ağacan at 2019-05-03T18:54:50Z
Fix interface version number printing in --show-iface

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

- - - - -
cc495d57 by Ryan Scott at 2019-05-03T18:54:50Z
Make equality constraints in kinds invisible

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
(https://gitlab.haskell.org/ghc/ghc/issues/12102#note_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 `InvisArg` to `Inferred`. As a
  consequence, the iface pretty-printer correctly recognizes that
  equality coercions are inferred arguments, and as a result,
  only displays them in `-fprint-explicit-kinds` is enabled.
* Speaking of iface pretty-printing, `Anon InvisArg` binders were
  previously being pretty-printed like `T (a :: b ~ c)`, as if they
  were required. This seemed inconsistent with other invisible
  arguments (that are printed like `T @{d}`), so I decided to switch
  this to `T @{a :: b ~ c}`.

Along the way, I also cleaned up a minor inaccuracy in the users'
guide section for constraints in kinds that was spotted in
https://gitlab.haskell.org/ghc/ghc/issues/12102#note_136220.

Fixes #12102 and #15872.

- - - - -
777896a6 by John Ericson at 2019-05-03T20:47:05Z
Remove cGhcEnableTablesNextToCode

Get "Tables next to code" from the settings file instead.

- - - - -
84cb3212 by Joachim Breitner at 2019-05-03T20:47:05Z
Make tablesNextToCode a proper dynamic flag (#15548)

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

- - - - -


30 changed files:

- .gitlab-ci.yml
- compiler/deSugar/DsExpr.hs
- compiler/ghc.mk
- compiler/ghci/ByteCodeItbls.hs
- compiler/hieFile/HieAst.hs
- compiler/hsSyn/HsExpr.hs
- compiler/hsSyn/HsExtension.hs
- compiler/iface/BinIface.hs
- compiler/iface/IfaceType.hs
- compiler/iface/ToIface.hs
- compiler/main/DynFlags.hs
- compiler/main/ErrUtils.hs
- compiler/main/SysTools.hs
- compiler/parser/Lexer.x
- compiler/parser/Parser.y
- compiler/parser/RdrHsSyn.hs
- compiler/rename/RnExpr.hs
- compiler/typecheck/TcHsType.hs
- compiler/typecheck/TcRnTypes.hs
- compiler/typecheck/TcTyClsDecls.hs
- compiler/types/TyCon.hs
- compiler/utils/Util.hs
- docs/users_guide/glasgow_exts.rst
- hadrian/src/Rules/Generate.hs
- hadrian/src/Settings/Packages.hs
- includes/ghc.mk
- libraries/base/Data/OldList.hs
- libraries/base/GHC/List.hs
- libraries/ghc-boot-th/GHC/LanguageExtensions/Type.hs
- libraries/ghci/GHCi/InfoTable.hsc


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/d0820c19ce8a6e84e398aac710d66c3218aa3826...84cb3212ad4c95d70a10998c9f9e8ed121cc77e4

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/d0820c19ce8a6e84e398aac710d66c3218aa3826...84cb3212ad4c95d70a10998c9f9e8ed121cc77e4
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20190503/939b728d/attachment-0001.html>

More information about the ghc-commits mailing list