GitLab

Apparently _POSIX_CPUTIME may be defined as -1 if
CLOCK_PROCESS_CPUTIME_ID isn't defined.

Test Plan: Validate

Reviewers: austin, hvr, erikd, goldfire

Reviewed By: erikd, goldfire

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2028

GHC Trac Issues: #11733

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2032

GHC Trac Issues: #11145

The desugarer had a fragile case to generate the Unfolding for a
DFun. This patch moves the unfolding generation to TcInstDcls, where
all the pieces are to hand.

Fixes Trac #11742

addDataConStupidTheta includes comments that the types list
might be longer than the tvs list. And the check in zipTvSubst
doesn't appear to be terribly recent. I am utterly flummoxed
as to why this worked before. It was clearly just broken.
And now it's fixed.

The free vars of `ty2` need to be in scope to satisfy the substitution
invariant.
As far as I can tell we don't have the free vars of `ty2` when
substituting, so unfortunately we have to compute them.

Test Plan: ./validate

Reviewers: austin, bgamari, simonpj, goldfire

Subscribers: thomie, simonmar

Differential Revision: https://phabricator.haskell.org/D2024

GHC Trac Issues: #11371

Use `fcmpu 0, ...` rather than `fcmpu cr0, ...` for better
portability since some non-GNU assembler (such as IBM's `as`) tend to not
support the symbolic register name `cr0`. This matches the syntax that
GCC emits for PPC targets.

This is valid behaviour for `malloc()` according to ISO C99 and POSIX,
and there's at least one operating system (AIX) which actually does return
NULL for 0-sized allocations.

The `createAdjustor()` routine is currently the only known use-site of
`stgMallocBytes` which may call `stgMallocBytes()` requesting a 0-size
allocation.

Reviewed By: bgamari, austin

Differential Revision: https://phabricator.haskell.org/D2022

Test cases: typecheck/should_fail/T1172{3,4}

It was Utterly Wrong before.

Note to self: Never, ever take the free vars of an unzonked type.

In particular, this allows correct tracking of specified/invisible
for variables in Haskell98 data constructors and in pattern synonyms.
GADT-syntax constructors are harder, and are left until #11721.

This was all inspired by Simon's comments to my fix for #11512,
which this subsumes.

Test case: ghci/scripts/TypeAppData

[skip ci]  (The test case fails because of an unrelated problem
fixed in the next commit.)

See Note [Prevent unification with type families]
in TcUnify for the details.

Instead of creating a new meta-tyvar and then unifying it with
a known kind in a KindedTyVar in a LHsQTyVars, just use the known kind.

Sadly, this still doesn't make #11719 usable, because while you can
now define a higher-kinded type family, you can't write any equations
for it, which is a larger problem.

test cases: dependent/should_compile/T{11635,11719}

- Optimize zonking * to avoid allocation.
- Try to avoid looking at the free variables of a type in the
  pure unifier. We need look at the variables only in the case
  of a forall.

The performance results updates included in this also include
a regression, but the regression is not due to this patch. When
validating previous patches, the test case failed, but I was
unable to reproduce outside of validation, so I let it go by, thinking
the failure was spurious. Upon closer inspection, the perf number
was right at the line, and the wibble between a valiation environment
and a regular test run was enough to make the difference.

Originally I wanted to only remove substTyWithBindersUnchecked, but
since both of them are unused maybe we don't need them.

Test Plan: ./validate

Reviewers: austin, goldfire, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie, simonmar

Differential Revision: https://phabricator.haskell.org/D2025

GHC Trac Issues: #11371

The Ord instance for ConLike uses Unique order which is bad for
determinism. Fortunately it's not used, so we can just delete it.
The is part of the effort to make Unique comparisons explicit.

Test Plan: ./validate

Reviewers: austin, simonmar, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2018

GHC Trac Issues: #4012

`Ord` for `TyCon` uses `Uniques` and it's not lexicographic.
I did some archeology and in
rGHC6c381e873e222417d9a67aeec77b9555eca7b7a8 the comment was introduced,
where there was something like `Ord3 Tycon` which *was* lexicographic.
In rGHC9dd6e1c216993624a2cd74b62ca0f0569c02c26b `Ord3 TyCon` was already
not lexicographic and `Ord3` got removed.

Test Plan: make someone take a look

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, simonmar

Differential Revision: https://phabricator.haskell.org/D2017

Arg, silly CPP.

The uniques seem to keep changing here.

This started when I noticed that `getCPUTime` only provides 1
millisecond resolution on Linux. Unfortunately the previous
implementation was quite unmaintainable, so this ended up being a bit
more involved than I expected.

Here we do several things,

 * Split up `System.CPUTime`

 * Add support for `clock_gettime`, allowing for significantly more
   precise timing information when available

 * Fix System.CPUTime resolution for Windows. While it's hard to get
   reliable numbers, the consensus is that Windows only provides 16
   millisecond resolution in GetProcessTimes (see Python PEP 0418 [1])

 * Eliminate terrible hack wherein we would cast between `CTime` and
   `Integer` through `Double`

[1] https://www.python.org/dev/peps/pep-0418/#id59

Test Plan: Validate on various platforms

Reviewers: austin, hvr, erikd

Reviewed By: erikd

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2001

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2013

GHC Trac Issues: #11580

Desugaring long lists with build trades large static data for large
code, which is likely a poor trade-off. See #11707.

Test Plan: Validate, nofib

Reviewers: simonpj, austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2007

GHC Trac Issues: #11707

The heap census now handles large ARR_WORDS objects which have
been shrunk by shrinkMutableByteArray# or resizeMutableByteArray#.

Test Plan: ./validate && make test WAY=profasm

Reviewers: hvr, bgamari, austin, thomie

Reviewed By: thomie

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2005

GHC Trac Issues: #11627

Test Plan: Look at DWARF output.

Reviewers: scpmw, austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1734

For #9646.

This reverts commit 89bdac76 as
this test is duplicated with dependent/should_fail/T11473, added by
aade1112.

Previously they were merely specialised at Int and Integer. It seems to
me that these are cheap enough to be worth inlining. See #11701 for
motivation.

Test Plan: Validate

Reviewers: austin, hvr, simonpj

Reviewed By: simonpj

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1997

GHC Trac Issues: #11701

Test Plan: Validate with testcase in D2002

Reviewers: austin, simonpj

Reviewed By: simonpj

Subscribers: simonpj, thomie

Differential Revision: https://phabricator.haskell.org/D2004

GHC Trac Issues: #11702

Test Plan: Test that it passes git HEAD and fails with GHC 7.8.

Reviewers: bgamari, hvr, austin, goldfire, thomie

Differential Revision: https://phabricator.haskell.org/D2009

GHC Trac Issues: #9646