GitLab

Summary:
GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's
that are not on the standard Windows load path:

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory,
   but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.
   Note that this does not include the per-application path specified by the
   AppPaths registry key. The App Paths key is not used when computing the DLL search path.

So what this means is given two DLLs `A` and `B` and `B` depending on `A`.
If we put both DLLs into a new folder bin and then call GHC with:

`ghc -L$(PWD)/bin -lB`

the loading will fail as the Windows loader will try to load the dependency of `B` and fail
since it cannot find `A`.

*IMPORTANT* this patch drops XP Support.
The  APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista
via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has
not been installed on certain machines. For those machines I display a warning and
temporarily expand the `PATH` to allow it to load.

This patch will make sure that paths provided by the user with `-L` *and* the folder in which a
DLL is found are added to the search path. It does so using one of two methods depending upon how
new of a Windows version we are running on:

- If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`.
   The order of which these directories are searched is nondeterministic.
- If the APIs are not available it means that we're running on a pretty old unpatched machine.
  But if it's being used in an environment with no internet access it may be the case.
  So if the APIs are not available we temporarily extend the `PATH` with the directories.
  A warning is also displayed to the user informing them that the linking may fail,
  and if it does, install the needed patch. The `PATH` variable has limitations.

Test Plan:
./validate

Added two new test T10955 and T10955dyn

Reviewers: erikd, bgamari, thomie, hvr, austin

Reviewed By: erikd, thomie

Subscribers: #ghc_windows_task_force

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

GHC Trac Issues: #10955

Summary:
Amazingly, there were zero changes to the byte code generator and very
few changes to the interpreter - mainly because we've used good
abstractions that hide the differences between profiling and
non-profiling.  So that bit was pleasantly straightforward, but there
were a pile of other wibbles to get the whole test suite through.

Note that a compiler built with -prof is now like one built with
-dynamic, in that to use TH you have to build the code the same way.
For dynamic, we automatically enable -dynamic-too when TH is required,
but we don't have anything equivalent for profiling, so you have to
explicitly use -prof when building code that uses TH with a profiled
compiler.  For this reason Cabal won't work with TH.  We don't expect
to ship a profiled compiler, so I think that's OK.

Test Plan: validate with GhcProfiled=YES in validate.mk

Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang

Reviewed By: ezyang

Subscribers: thomie

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

GHC Trac Issues: #4837, #545

in contrast to "e (f x)", where CorePrep will turn it into "let y = f x
in e x". So in
  let f = ...
  in e (f x)
we know that f is called at most once, but in
  let f = ...
  in e f
we do not know that.

Previously Call Arity would assume that in "e x", "x" is evaluated at
most once. This rarely would make a difference (the argument "x" is
analized with an incoming arity of 0, so no eta-expansion would be done
anyways), but of course this should still be fixed.

This fixes #11064.

Note the corresponding code dmdTransformThunkDmd in DmdAnal.

Test Plan:
 - Run tests on x86_64/linux and powerpc/linux
 - Cross compile rts/Linker.c with the i686-w64-mingw32-gcc and
   x86_64-w64-mingw32-gcc Linux to Windows cross-compilers.

Reviewers: bgamari, austin, hvr, Phyx

Subscribers: thomie

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

Previously something like `/usr/bin/opt-3.7` was being shortened to
`opt-3` using the `takeBaseName` function. This shortened form is
actually not correct. We should use `takeFileName` instead.

Reviewers: bgamari, austin, hvr

Subscribers: thomie

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

* The LLVM backend does not currently work on PowerPC so disable it.
* Only run LLVM tests if the needed LLVM tools have been detected at
  configure time.

Test Plan: Run LLVM tests on x86_64 and powerpc

Reviewers: austin, bgamari, hvr, thomie

Subscribers: thomie

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

This helps catch cabal-flag misconfiguration early on during `cabal
configure`, rather than much later in the build-process during
compilation.

Reviewed By: austin

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

Problem: 'SRC_HC_OPTS += -Wall' in 'mk/warnings.mk' was getting
overwritten by 'SRC_HC_OPTS = ...' in 'mk/flavours/*.mk'.

It didn't affect the compiler or most other libraries, because most
.cabal files define 'ghc-options: -Wall'.

Bug introduced in commit
2c24fd70, when moving validate settings
from 'mk/validate-settings.mk' to 'mk/flavours/validate.mk'.

Reviewed By: austin

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

This seems like an obvious place to apply `const`

Reviewed By: simonmar, austin

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

This requires adding a new primitive `mplusIO` to `GHC.IO`

Update transformers submodule to accomodate extant orphan instances.

Reviewed By: austin, bgamari

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

GHC Trac Issues: #10755

This is based on David's initial patch augmented by more extensive
Haddock comments.

This has been broken out of D1248 to reduce its size
by splitting the patch into smaller logical pieces.

On its own, this new module does nothing interesting yet.
Later patches will add support for a different desugaring of
`do`-blocks, at which point the new `MonadFail` class will
become more useful.

Reviewed By: ekmett, austin

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

This missed to perform in f8ba4b55

This pulls in a minor version bump to v1.4.1, this way
GHC HEAD nightly builds report a proper version number.

Summary:
D1357 introduces usage of Elf32_Section/Elf64_Section in RTS linker
code. Unfortunately this is a non-portable Linux-ism and such types are not
defined anywhere except the Linux-land probably. I've checked Solaris 11.2,
Solaris 11.3, FreeBSD 10.1, NetBSD 6.1.5 and OpenBSD current. The fix
is easy to use `unsigned short' as this is also an underlying type
of those Elf*_Section defines in Linux.

Reviewers: olsner, austin, bgamari, erikd

Subscribers: thomie

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

We already used a process-1.4 snapshot with non-bumped version,
so this commit is mostly a `.cabal` file upper-bound relaxation change.

Test Plan: Validate

Reviewers: austin, simonmar

Reviewed By: simonmar

Subscribers: simonmar, thomie, scpmw

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

Previously the eventlog flush code would fail if `fwrite` wrote less
than the requested amount. Like all Unix stream I/O operations, however,
`fwrite` isn't guaranteed to write the entire buffer. Here we loop as
long as `fwrite` succeeds in writing anything.

Fixes #11041.

Test Plan: Validate with eventlog

Reviewers: austin, simonmar

Reviewed By: simonmar

Subscribers: thomie

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

GHC Trac Issues: #11041

Summary:
Python 3 seems to have fixed the long standing codepage issue with
python on Windows. To be able to reliably build the documentation
we should use the Python 3 version of Sphinx.

See `https://docs.python.org/dev/whatsnew/3.3.html#codecs` and
`https://bugs.python.org/issue13216`. Sphinx also supports Python 3.

Oddly enough `python3-sphinx` is registered as `sphinx-build.exe`
instead of `sphinx-build3.exe`, so the changes in `configure.ac` can
be reverted.

install with `pacman -S mingw-w64-$(uname -m)-python3-sphinx`

Test Plan: ./validate

Reviewers: austin, thomie, bgamari

Reviewed By: bgamari

Subscribers: erikd

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

GHC Trac Issues: #11021

We don't need to update StgCase's AltType, because it's already set
correctly in `CoreToStg.mkStgAltType`, so we can just remove extra
argument passing and return values.

(I think this is a useful refactoring because it makes it clear that we
don't need to update AltTypes)

Reviewers: austin, bgamari, simonpj

Reviewed By: bgamari, simonpj

Subscribers: simonpj, thomie

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

RTS convention is to use camel-case.

This is no longer necessary since this symbol can be unwound through
with its DWARF information.

This is a bit ugly as we need to assume the structure of the C stack as
left by StgRun. Nevertheless, it allows us to unwind all the way back to
`_start` on my machine.

```
Stack trace:
    set_initial_registers (rts/Libdw.c:272.0)
    dwfl_thread_getframes

    dwfl_getthreads
    dwfl_getthread_frames
    libdw_get_backtrace (rts/Libdw.c:243.0)
    base_GHCziExecutionStack_getStackTrace1_info
(libraries/base/GHC/ExecutionStack.hs:43.1)
    base_GHCziExecutionStack_showStackTrace1_info
(libraries/base/GHC/ExecutionStack.hs:47.1)
    base_GHCziBase_bindIO1_info (libraries/base/GHC/Base.hs:1085.1)
    base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
    base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
    base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
    base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
    base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
    stg_catch_frame_info (rts/Exception.cmm:370.1)
    stg_stop_thread_info (rts/StgStartup.cmm:42.1)
    scheduleWaitThread (rts/Schedule.c:465.0)
    hs_main (rts/RtsMain.c:65.0)

    __libc_start_main (/tmp/buildd/glibc-2.19/csu/libc-start.c:321.0)
    _start
```

We will need to use these to setup proper unwinding information for the
stg_stop_thread closure. This pokes a hole in the STG abstraction,
exposing the machine's stack pointer register so that we can accomplish
this. We also expose a dummy return address register, which corresponds
to the register used to hold the DWARF return address.

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

Here we add a `same_value $sp` instruction to our default unwinding
rules to ensure that the implicit `$sp = CFA` rule (which `libdw`
appears to exhibit on x86_64) doesn't overwrite it (necessary since we
don't use $sp to track our call stack).

See Phab Diff D1189 for details on how we arrived at this resolution.

Reviewers: scpmw, austin, simonmar

Reviewed By: austin, simonmar

Subscribers: thomie, simonmar

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

This allows us to remove 4 newly added language pragmas from the T4437
test-case as they were recently added to Cabal 1.23

This flag works under both GHC and GHCi, as pointed out on D1367. Thanks
to @thomie for pointing this out.

Buggy Makefile code meant it was always included, instead of being
included only for the dyn ways.

Test Plan: validate

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

At the moment BooleanFormula is defined as

  data BooleanFormula a = Var a | And [BooleanFormula a]
                        | Or [BooleanFormula a]
       deriving (Eq, Data, Typeable, Functor, Foldable, Traversable)

An API Annotation can only be attached to an item of the form Located a.

Replace this with a properly Located version, and attach the appropriate
API Annotations to it

Updates haddock submodule.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering

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

GHC Trac Issues: #11017

This also needs to update the primitive/vector submodules in order to
relax upper bounds on ghc-prim.

Like in f8ba4b55, a mass-rewrite in testsuite/ via

  sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0')

was performed.

[skip ci]

This also relaxes a few upper bounds on base in the ghc.git repo;

This required a mass-rewrite in testsuite/

  sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')

because it turns out the testsuite is still sensitive to package version
changes.

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`

This also needs to relax a few upper bounds on process in some cabal files

(there will be another process submodule update soon, as a major
version bump of process' version is still pending)

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`

This is needed to prepare for #11026 as this update
relaxes the upper bounds on `base` to allow for `base-4.9.0.0`