GitLab

The code fragment

  type family Proxy2' ∷ ∀ k → k → Type where
    Proxy2' = Proxy'

Generates AnnRarrow instead of AnnRarrowU for the first →.

Fixes #17519

NixOS development environments often require that LD_LIBRARY_PATH
be set in order to find system libraries. T1407 was overriding
LD_LIBRARY_PATH, dropping these directories. Now it merely prepends,
its directory.

While backporting MR !1806 to 8.8.2 (!1885) I learnt the following:

* Tests with `expect_fail` do not compare `*.stderr` output files. So a test using `expect_fail` will not detect future regressions on the `stderr` output.
* To compare the `*.stderr` output files, I have to use the `exit_code(n)` function.
* When a release is made, tests with `makefile_test` are converted to use `run_command`.
* For the test `T17171a` the return code is `1` when running `makefile_test`, however it's `2` when running `run_command`.

Therefore I decided:

* To improve my tests for #17171
* To change test T17171a from `expect_fail` to `exit_code(2)`
* To change both tests from  `makefile_test` to `run_command`

Metric Decrease:
    haddock.compiler

This is a refactoring with no user-visible changes (except for GHC API
users). Consider the HsExpr constructors that correspond to user-written
pragmas:

  HsSCC         representing  {-# SCC ... #-}
  HsCoreAnn     representing  {-# CORE ... #-}
  HsTickPragma  representing  {-# GENERATED ... #-}

We can factor them out into a separate datatype, HsPragE. It makes the
code a bit tidier, especially in the parser.

Before this patch:

  hpc_annot :: { Located ( (([AddAnn],SourceText),(StringLiteral,(Int,Int),(Int,Int))),
                           ((SourceText,SourceText),(SourceText,SourceText))
                         ) }

After this patch:

  prag_hpc :: { Located ([AddAnn], HsPragE GhcPs) }

This patch implements a part of GHC Proposal #229 that covers five
operators:

* the bang operator (!)
* the tilde operator (~)
* the at operator (@)
* the dollar operator ($)
* the double dollar operator ($$)

Based on surrounding whitespace, these operators are disambiguated into
bang patterns, lazy patterns, strictness annotations, type
applications, splices, and typed splices.

This patch doesn't cover the (-) operator or the -Woperator-whitespace
warning, which are left as future work.

In #17270 we have the pattern-match checker emit incorrect warnings. The
reason for that behavior is ultimately an inconsistency in whether we
treat TH splices as written by the user (`FromSource :: Origin`) or as
generated code (`Generated`). This was first reported in #14838.

The current solution is to TH splices as `Generated` by default and only
treat them as `FromSource` when the user requests so
(-fenable-th-splice-warnings). There are multiple reasons for opt-in
rather than opt-out:

  * It's not clear that the user that compiles a splice is the author of the code
    that produces the warning. Think of the situation where she just splices in
    code from a third-party library that produces incomplete pattern matches.
    In this scenario, the user isn't even able to fix that warning.
  * Gathering information for producing the warnings (pattern-match check
    warnings in particular) is costly. There's no point in doing so if the user
    is not interested in those warnings.

Fixes #17270, but not #14838, because the proper solution needs a GHC
proposal extending the TH AST syntax.

This reverts the change in #9096.

The specialcasing done for prefix (->) is brittle and
does not support VTA, type families, type synonyms etc.

This brings `Natural` on par with `Integer` and fixes #17499.
Also does some manual CSE for 0 and 1 literals.

This reverts a part of commit
7bc5d6c6 that causes all arguments
to `-optc` (and `-optcxx`) to be passed twice to the C/C++ compiler,
once in reverse order and then again in the correct order. While
passing duplicate arguments is usually harmless it can cause breakage
in this pattern, which is employed by Hackage libraries in the wild:

```
ghc Foo.hs foo.c -optc-D -optcFOO
```

As `FOO -D -D FOO` will cause compilers to error.

Fixes #17471.

CorePrep already had a check to prevent it from eta-reducing Ids that
respond true to hasNoBinding (foreign calls, constructors for unboxed
sums and products, and Ids with compulsory unfoldings). It did not,
however, consider join points as ids that 'must be saturated'.

Checking whether the Id responds True to 'isJoinId' should prevent
CorePrep from turning saturated jumps like the following (from #17429)
into undersaturated ones:

      (\ eta_XP ->
         join { mapped_s1vo _ = lvl_s1vs } in jump mapped_s1vo eta_XP)

This exposes a set of interfaces from the GHC API for configuring
EventLogWriters. These can be used by consumers like
[ghc-eventlog-socket](https://github.com/bgamari/ghc-eventlog-socket).

This makes error messages a tad less noisy.

* Make sure files are being read/written in UTF-8. Set encoding while writing
  HTML output. Also set encoding while writing and reading .tix files although
  we don't yet have a ticket complaining that this poses problems.
* Set encoding in html header to utf8
* Upgrade to new version of 'hpc' library and reuse `readFileUtf8`
  and `writeFileUtf8` functions
* Update git submodule for `hpc`
* Bump up `hpc` executable version
Co-authored-by: Ben Gamari <ben@smart-cactus.org>

Previously the returned tuple seemed to fit in registers on amd64. This
meant that non-moving collector bug would cause the test to fail on i386
yet not amd64.

`GHC.Prim.seq` previously had the rather plain type:

    seq :: forall a b. a -> b -> b

However, it also had a special typing rule to applications
where `b` is not of kind `Type`.

Issue #17440 noted that levity polymorphism allows us to rather give
it the more precise type:

    seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b

This allows us to remove the special typing rule that we previously
required to allow applications on unlifted arguments. T9404 contains a
non-Type application of `seq` which should verify that this works as
expected.

Closes #17440.

I previously increased the size of the acceptance window from 2% to 5%
but this still isn't enough. Regardless, measuring bytes allocated
should be sufficient to catch any regressions.

This statistic is rather unstable. Hopefully fixes #17475.

Metric Increase:
    T4801

Issue #17461 was occurring because the `Outputable` instance for
standalone kind signatures was simply calling `ppr` on the name in
the kind signature, which does not add parentheses to infix names.
The solution is simple: use `pprPrefixOcc` instead.

Fixes #17461.

As noted in #17458, QuantifiedConstraints and UndecideableInstances
could previously be used to write programs which can loop at runtime.
This was fixed in !1870.

As suggested in #17387; this helps reduce the variance in our residency
sampling.

Metric Increase:
    T10370
    T3586
    lazy-bs-alloc

Metric Decrease 'compile_time/peak_megabytes_allocated':
    T1969

Metric Decrease 'runtime/bytes allocated':
    space_leak_001

Metric Increase 'compile_time/bytes allocated':
    T1969

Metric Increase 'runtime/peak_megabytes_allocated':
    space_leak_001

Metric Decrease:
    T3064
    T9675

Previously, we checked all imported type family equations
for injectivity. This is very silly. Now, we check only
for conflicts.

Before I could even imagine doing the fix, I needed to untangle
several functions that were (in my opinion) overly complicated.
It's still not quite as perfect as I'd like, but it's good enough
for now.

Test case: typecheck/should_compile/T17405

A missing prime meant that we were considering the wrong
type in the GHCi debugger, when doing :force on multiple
arguments (issue #17431).

The fix is trivial.

As noted in #17452, this test produces very long file paths which
exceed the Windows MAX_PATH limitation. Mark the test as fragile for not
until we can come up with a better solution.

This test is quite sensitive to the build configuration as it requires that ghc
have unfoldings, which isn't true in the quick build flavours. I considered
various options to make the test more robust but none of them seemed
particularly appealing. Moreover, Simon PJ was a bit skeptical of the value of
the test to begin with and I strongly suspect that any regression in #7995
would be accompanied by failures in our other compiler performance tests.

Closes #17399.

Bizarrely, `saks028` previously failed reliably, but only on Windows
(#17450). The test would exit with a zero exit code but simply didn't
emit the expected text to stderr.

I believe this was due to the fact that the test used `putStrLn`,
resulting in the output ending up on stdout. This worked on other
platforms since (apparently) we redirect stdout to stderr when
evaluating splices. However, on Windows it seems that the redirected
output wasn't flushed as it was on other platforms.

Anyways, it seems like the right thing to do here is to be explicit
about our desire for the output to end up on stderr.

Closes #17450.

As described in #17449, PartialDownsweep is currently fragile due to its
dependence on the error messages produced by the C preprocessor. To eliminate
this dependence we simply ignore stderr output, instead relying on the fact
that the test will exit with a non-zero exit code on failure.

Fixes #17449.

The GHCi script for T16511 had some `rm` commands to clean up output
from previous runs. This should be harmless since stderr was redirected
to /dev/null; however, it seems that this redirection doesn't work on
Windows (perhaps because GHCi uses `cmd` to execute the command-line;
I'm not sure). I tried to fix it but was unable to find a sensible
solution.

Regardless, the cleaning logic is quite redundant now that we run each
test in a hermetic environment. Let's just remove it.

This was previously broken due to #16386 yet it passes for me locally.

It was previously marked as broken due to #12236 however it passes for
me locally while failing on CI.

Due to #17447.

<Rts.h> must always come first.