[Git][ghc/ghc][wip/run-nofib] 23 commits: Implement the -XUnliftedNewtypes extension.

Ben Gamari gitlab at gitlab.haskell.org
Sun Jun 16 15:32:45 UTC 2019



Ben Gamari pushed to branch wip/run-nofib at Glasgow Haskell Compiler / GHC


Commits:
effdd948 by Andrew Martin at 2019-06-14T14:48:13Z
Implement the -XUnliftedNewtypes extension.

GHC Proposal: 0013-unlifted-newtypes.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
Issues: #15219, #1311, #13595, #15883
Implementation Details:
  Note [Implementation of UnliftedNewtypes]
  Note [Unifying data family kinds]
  Note [Compulsory newtype unfolding]

This patch introduces the -XUnliftedNewtypes extension. When this
extension is enabled, GHC drops the restriction that the field in
a newtype must be of kind (TYPE 'LiftedRep). This allows types
like Int# and ByteArray# to be used in a newtype. Additionally,
coerce is made levity-polymorphic so that it can be used with
newtypes over unlifted types.

The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
getInitialKind is more liberal, introducing a unification variable to
return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
When kind-checking a data constructor with kcConDecl, we attempt to
unify the kind of a newtype with the kind of its field's type. When
typechecking a data declaration with tcTyClDecl, we again perform a
unification. See the implementation note for more on this.

Co-authored-by: Richard Eisenberg <rae at richarde.dev>

- - - - -
5279dda8 by Ben Gamari at 2019-06-14T14:48:51Z
PrelRules: Don't break let/app invariant in shiftRule

Previously shiftRule would rewrite as invalid shift like
```
let x = I# (uncheckedIShiftL# n 80)
in ...
```
to
```
let x = I# (error "invalid shift")
in ...
```
However, this breaks the let/app invariant as `error` is not
okay-for-speculation. There isn't an easy way to avoid this so let's not
try. Instead we just take advantage of the undefined nature of invalid
shifts and return zero.

Fixes #16742.

- - - - -
503e830c by Ben Gamari at 2019-06-15T03:10:08Z
gitlab-ci: Lint testsuite for framework failures

This introduces a new lint job checking for framework failures and
listing broken tests.

- - - - -
b5ea9323 by Ben Gamari at 2019-06-15T03:10:08Z
lint: Only apply --interactive lint to testsuite .T files

- - - - -
5c97211c by Ben Gamari at 2019-06-15T03:10:08Z
gitlab-ci: Lint the linters

- - - - -
257165b4 by Alp Mestanogullari at 2019-06-15T03:10:46Z
Remove duplicates from 'ghc --info' output

- - - - -
5da6c86f by Ben Gamari at 2019-06-15T19:14:01Z
Bump unix submodule

Skips `executeFile001` test in `threaded2` way. Fixes #16814.

- - - - -
20b4d5ec by Ben Gamari at 2019-06-16T03:32:38Z
Disable optimisation when building Cabal lib for stage0

This disables optimisation when building Cabal for Hadrian and
stage0 `ghc-cabal`. Cabal is performance critical in neither case nor
will any performance difference here be visible to the end-user.

See #16817.

- - - - -
76b7f619 by Ben Gamari at 2019-06-16T03:32:38Z
Disable optimisation when building Cabal in development flavours

This updates the make and Hadrian build flavours targetting developers
to disable optimisation when building the Cabal library. Cabal tends to
tickle some very bad compiler performance cases (e.g. #16577) so
disabling optimisation here makes a sizeable impact on overall build
time.

See #16817.

- - - - -
0d2a4258 by Ben Gamari at 2019-06-16T03:33:13Z
testsuite: Introduce concurrent_ways set

Previously we just tested for the threaded2 when determining whether to
skip tests which are fragile under concurrent execution. However, this
isn't the only way which is concurrent.

- - - - -
beacb6fd by Ben Gamari at 2019-06-16T03:33:13Z
testsuite: Skip hDuplicateTo001 in concurrent ways

As noted in #16819, this operation is racy under concurrent execution.

- - - - -
ca721193 by Aiken Cairncross at 2019-06-16T03:33:50Z
Fix typo in error message

- - - - -
57b71848 by Ben Gamari at 2019-06-16T03:34:25Z
testsuite: Add assertions that way lists are in fact lists

Previously there were a few cases where operations like `omit_ways`
were incorrectly passed a single way (e.g. `omit_ways('threaded2')`).
This won't work as the author expected.

- - - - -
25ee60cd by Ryan Scott at 2019-06-16T03:35:03Z
Synchronize ClsInst.doTyConApp with TcTypeable validity checks (#15862)

Issue #15862 demonstrated examples of type constructors on which
`TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable`
constraint solver in `ClsInst` (in particular, `doTyConApp`) would
try to generate `Typeable` evidence for anyway, resulting in
disaster. This incongruity was caused by the fact that `doTyConApp`
was using a weaker validity check than `tyConIsTypeable` to determine
if a type constructor warrants `Typeable` evidence or not. The
solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in
`doTyConApp` instead.

To avoid import cycles between `ClsInst` and `TcTypeable`, I factored
out `tyConIsTypeable` into its own module, `TcTypeableValidity`.

Fixes #15862.

- - - - -
4138bf86 by Krzysztof Gogolewski at 2019-06-16T03:35:38Z
Remove dead code

- - - - -
db313f98 by Ben Gamari at 2019-06-16T10:26:38Z
base/Event/Poll: Drop POLLRDHUP enum item

Previously the Event enumeration produced by hsc2hs would sometimes
include a currently-unused POLLRDHUP item. This unused binding would
result in a build failure. Drop it.

- - - - -
81608e82 by Ben Gamari at 2019-06-16T10:26:38Z
testsuite: Fix T8602 on musl

Musl wants hash-bangs on all executables.

- - - - -
a0f68379 by Ben Gamari at 2019-06-16T10:26:38Z
testsuite: Ensure T5423 flushes C output buffer

Previously T5423 would fail to flush the printf output buffer.
Consequently it was platform-dependent whether the C or Haskell print
output would be emitted first.

- - - - -
543dfaab by Ben Gamari at 2019-06-16T10:26:38Z
testsuite: Flush conc059's printf buffer

Otherwise it the order out the Haskell and C output will be
system-dependent.

- - - - -
e647752e by Ben Gamari at 2019-06-16T10:26:38Z
testsuite: Ensure that ffi005 output order is predictable

The libc output buffer wasn't being flushed, making the order
system-depedent.

- - - - -
338336d3 by Ben Gamari at 2019-06-16T10:26:38Z
gitlab-ci: Build alpine release bindists

- - - - -
75c6ccf7 by Alp Mestanogullari at 2019-06-16T10:27:17Z
fix runghc's GHC detection logic to cover the "in-tree Hadrian build" scenario

Before this patch, runghc would only run the GHC detection logic on Windows and
assume that it was invoked through a wrapper script on all other platforms.
This patch lifts this limitation and makes that logic work for the scenario
where someone is calling the runghc executable directly, without passing an
explicit path to GHC.

- - - - -
7ed710ed by Ben Gamari at 2019-06-16T15:32:43Z
gitlab-ci: Run nofib on binary distributions

Updates docker images to ensure that the `time` utility is available.

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/linters/check-makefiles.py
- .gitlab/linters/linter.py
- compiler/basicTypes/Id.hs
- compiler/basicTypes/MkId.hs
- compiler/codeGen/StgCmmForeign.hs
- compiler/coreSyn/CoreSyn.hs
- compiler/deSugar/Check.hs
- compiler/deSugar/DsExpr.hs
- compiler/ghc.cabal.in
- compiler/hsSyn/HsTypes.hs
- compiler/main/DynFlags.hs
- compiler/main/TidyPgm.hs
- compiler/prelude/PrelRules.hs
- compiler/prelude/PrimOp.hs
- compiler/prelude/TysPrim.hs
- compiler/prelude/primops.txt.pp
- compiler/rename/RnSource.hs
- compiler/rename/RnSplice.hs
- compiler/simplCore/CoreMonad.hs
- compiler/typecheck/ClsInst.hs
- compiler/typecheck/TcErrors.hs
- compiler/typecheck/TcEvidence.hs
- compiler/typecheck/TcHsType.hs
- compiler/typecheck/TcInstDcls.hs
- compiler/typecheck/TcMType.hs
- compiler/typecheck/TcRnMonad.hs
- compiler/typecheck/TcSimplify.hs
- compiler/typecheck/TcTyClsDecls.hs
- compiler/typecheck/TcTypeable.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/058a5e5bf7908451331a14ba68691d4d07fb87c8...7ed710ed8d7cb0841bba52304a53f462cb67b816

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/058a5e5bf7908451331a14ba68691d4d07fb87c8...7ed710ed8d7cb0841bba52304a53f462cb67b816
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/20190616/a0e248c3/attachment.html>


More information about the ghc-commits mailing list