GitLab

When Opt_KeepRawTokenStream is turned on then getOptions fails to find
the language pragmas which can cause unexpected parse errors when using
the GHC API. A simple solution is to make it skip over any comments in
the token
stream.

Test Plan: ./validate

Reviewers: austin, bgamari

Subscribers: alanz, thomie

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

GHC Trac Issues: #10942

Test Plan: validate

Reviewers: goldfire, erikd, rwbarton, simonpj, austin, simonmar, hvr

Reviewed By: simonpj

Subscribers: simonmar, thomie

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

GHC Trac Issues: #10678

Test Plan: Validate

Reviewers: austin, thomie

Reviewed By: thomie

Subscribers: kgardas, thomie

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

Foreign calls may not be strict for lifted arguments. Fixes Trac #11076.

Test Plan: ./validate

Reviewers: simonpj, bgamari, austin

Subscribers: thomie

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

GHC Trac Issues: #11076

This adds a flag -split-sections that does similar things to
-split-objs, but using sections in single object files instead of
relying on the Satanic Splitter and other abominations. This is very
similar to the GCC flags -ffunction-sections and -fdata-sections.

The --gc-sections linker flag, which allows unused sections to actually
be removed, is added to all link commands (if the linker supports it) so
that space savings from having base compiled with sections can be
realized.

Supported both in LLVM and the native code-gen, in theory for all
architectures, but really tested on x86 only.

In the GHC build, a new SplitSections variable enables -split-sections
for relevant parts of the build.

Test Plan: validate with both settings of SplitSections

Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari

Reviewed By: simonmar, thomie, bgamari

Subscribers: hsyl20, erikd, kgardas, thomie

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

GHC Trac Issues: #8405

Summary:
This patch fixes RTS Linker compilation issues on platforms
where SHN_XINDEX is not defined. Tested on OpenBSD. When SHN_XINDEX
is not defined, the code reverts to the old behavior, that means
behavior of the Linker before D1357 which added SHN_XINDEX based
functionality.

Reviewers: bgamari, austin, erikd

Subscribers: thomie

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

ExportSyntaxImport will fail if this test would have ever failed.

This also fixes a bug which causes intermittent test failures due to
interdependent tests.

Since `mkGadtDecl` does not use any of the functions specific to the `P`
monad we can extract it from that monad and reuse in other parts of the
compiler.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, mpickering

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

Arithmetic right shifts of more than 31 bits set all bits to
the sign bit on PowerPC. iThe assembler does not allow shift
amounts larger than 32 so do an arithemetic right shift of 31
bit instead.

Fixes #10870

Test Plan: validate (especially on powerpc)

Reviewers: austin, erikd, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10870

The bytecode compiler doesn't handle every foreign import calling
convention. Instead of crashing during the generation of the foreign
call, we display an error.

Fix lint warnings

Test Plan: prog014 ghci test added

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #10462

When you reverse the order of uniques you get the core lint
error from the testcase. The testcase is copied from
tests/simplCore/should_compile/T10689a.hs.

The problem is that we would put type and kind variables ordered by
unique order, which happened to be the right order for this testcase to
pass under normal conditions.

I think it's enough to sort them with `sortQuantVars`, but I'm not
really sure if some more sophisticated dependency analysis isn't needed.

Test Plan: added a new testcase

Reviewers: simonpj, goldfire, simonmar, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

- Document behavior on some inputs.
- Add some examples.

Reviewers: bgamari, osa1, hvr, dolio, #core_libraries_committee,
nomeata, austin

Reviewed By: bgamari, dolio, #core_libraries_committee, nomeata, austin

Subscribers: dolio, glguy, nomeata, thomie

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

This patch tackles two issues:

1) GHC stores a "link info" string into a ELF section. Initially a
section with type "note" was used but GHC didn't follow the ELF
specification which specifies a record-based format for these sections.
With D1375 we switched to a "progbits" section type for which there
isn't any format constraint. This is an issue for D1242 which use GCC's
--gc-sections which collects "unused" sections, such as our section
containing link info... In this patch, we fall back to a section with
type "note" but we respect the specified format.

2) Reading back the ELF section was done by parsing the result of a
call to "readelf". Calling readelf is problematic because the program
may not be available or it may be renamed on some platforms (see
D1326). Moreover we have no garanty that its output layout will stay
the same in future releases of readelf. Finally we would need to fix
the parsing to support  "note" sections because of 1. Instead, this
patch proposes to use Data.Binary.Get to directly read the "link info"
note into its section. ELF has a specification, hence it should work on
every conforming platform.

This patch "reverts" D1375, hence it supersedes D1432. It makes D1326
not necessary anymore.

Test Plan:
- recomp011 should pass (test that relinking is avoided when both "link
info" match)
- we should add a test for ELF objects with more than 0xff00 sections
=> added test "recomp015"
- we should check that GAS generates 32-bit words with .int on every
supported platform using ELF (or find a place where this is
documented). harbomaster and I (@hsyl20) only tested on x86-64. On
platforms where it is not true, it should make recomp011 fail. =>
tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64

Reviewers: olsner, ony, thomie, kgardas, austin, bgamari

Reviewed By: thomie, bgamari

Subscribers: kgardas, rwbarton, thomie

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

GHC Trac Issues: #10974, #11022

One of the changes D538 introduced is to add `m_fun_id_infix` to `Match`

```lang=hs
data Match id body
  = Match {
        m_fun_id_infix :: (Maybe (Located id,Bool)),
          -- fun_id and fun_infix for functions with multiple equations
          -- only present for a RdrName. See note [fun_id in Match]
        m_pats :: [LPat id], -- The patterns
        m_type :: (Maybe (LHsType id)),
                                 -- A type signature for the result of the match
                                 -- Nothing after typechecking
        m_grhss :: (GRHSs id body)
  } deriving (Typeable)
```

This was done to track the individual locations and fixity of the
`fun_id` for each of the defining equations for a function when there
are more than one.

For example, the function `(&&&)` is defined with some prefix and some
infix equations below.

```lang=hs
    (&&&  ) [] [] =  []
    xs    &&&   [] =  xs
    (  &&&  ) [] ys =  ys
```

This means that the fun_infix is now superfluous in the `FunBind`. This
has not been removed as a potentially risky change just before 7.10 RC2,
and so must be done after.

This ticket captures that task, which includes processing these fields
through the renamer and beyond.

Ticket #9988 introduced these fields into `Match` through renaming, this
ticket it to continue through type checking and then remove it from
`FunBind` completely.

The split happened so that #9988 could land in 7.10

Trac ticket : #10061

Test Plan: ./validate

Reviewers: goldfire, austin, simonpj, bgamari

Reviewed By: bgamari

Subscribers: simonpj, thomie, mpickering

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

GHC Trac Issues: #10061

We no longer parse old-style GADT syntax but there was some left-over
code for emitting deprecation warnings.

Updates haddock submodule.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

When a .hsc contains `#define FOO "bar baz"`, hsc2hs emits:

    {-# OPTIONS_GHC -optc-DFOO="bar baz" #-}

Make sure GHC can compile this, by tweaking `HeaderInfo.getOptions` a
bit.

Test Plan: driver/T4931

Reviewers: austin, bgamari

Reviewed By: bgamari

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

GHC Trac Issues: #4931

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: mpickering, thomie

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

This patch implements #10653.

It adds the ability to bundle pattern synonyms with type constructors in
export lists so that users can treat pattern synonyms more like data
constructors.

Updates haddock submodule.

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Reviewed By: bgamari

Subscribers: simonpj, gridaphobe, thomie

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

GHC Trac Issues: #10653

Summary:
For abstract type families we incorrectly rejected their injectivity
annotation.  Fixes #11007.

Test Plan: #6018

Reviewers: goldfire, austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11007

Summary:
Multiple tests use the same source C file.
GHC was previously writing the resulting .o files
in the same folder as the source. When these tests
are run in parallel, sometimes one of the calls would
use the partial .o file and throw an error.

The .o files are moved into different folders with this
change.

Test Plan: make test -C testsuite/tests/ghci/linking/dyn

Reviewers: thomie, austin, bgamari

Reviewed By: bgamari

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

This patch adds OpenBSD specific RTS symbols.  The patch is taken from
the OpenBSD ports tree, provided by the OpenBSD community.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11063

I've spent quite a bit of time giving unique labels to my `pprTrace`
calls and then trying to intuit where the function is called from.
Thanks to the new implicit parameter CallStack functionality I don't
have to do that anymore.

Test Plan: harbormaster

Reviewers: austin, simonmar, bgamari

Reviewed By: simonmar, bgamari

Subscribers: thomie

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

Test Plan: harbormaster

Reviewers: bgamari, simonmar, austin

Reviewed By: austin

Subscribers: thomie

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

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie

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

This should work,

    {-# DEPRECATED someFunction [] #-}

Test Plan: parser/should_compile/T3303

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: mpickering

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

GHC Trac Issues: #11044

When cross-compiling ghc itself, this prevents:

  "dll-split: cannot execute binary file: Exec format error"

Test Plan:
   * ./configure --target=arm-linux-gnueabihf
   * DYNAMIC_GHC_PROGRAMS=YES
   * Stage1Only=NO

Reviewers: rwbarton, bgamari, austin

Reviewed By: austin

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

Summary:
It was only used to pass field labels between the typechecker and
desugarer. Instead we add an extra field the RecordCon to carry this
information.

Reviewers: austin, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #11057

Test Plan: validate

Reviewers: bgamari, austin, goldfire

Reviewed By: goldfire

Subscribers: thomie

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

GHC Trac Issues: #10734

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