| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Our new CPP linter enforces this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This both says what we mean and silences a bunch of spurious CPP linting
warnings. This pragma is supported by all CPP implementations which we
support.
Reviewers: austin, erikd, simonmar, hvr
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3482
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a unfortunate workaround in place for the fact that most
packages out there use POSIX names for symbols even on Windows. This
means that we have to recognize e.g. both `_ungetch` and `ungetch`.
The former is the actual symbol name on windows and the latter is the
POSIX variant. The problem is that on normal windows programs `ungetch`
should not be in the global namespace.
To work around this, we now mark the deprecated symbols as weak symbols
in the global namespace. This provides the flexibility we need:
* If you use the symbol without defining it, we assume you meant to use
the POSIX variant.
* If you actually define the symbol, we'll hence forth use that
definition and assume you didn't mean to use POSIX code. This is how
MingW64's wrapper also works.
This requires D3028.
Fixes #13210.
Test Plan: ./validate
Reviewers: austin, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D3154
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These will be needed across source files shortly.
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2647
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With the introduction of 8.0.1 We've stopped supporting in GHCi
the use of POSIX functions under their deprecated names on Windows.
This to be compatible with object and libraries from the most
popular compilers on the platform (Microsoft and Intel compilers).
However this brings a confusing disparity between the compiled and
interpreted behavior since MingW-W64 does support the deprecated names.
Also It seems clear that package writers won't update their packages to
properly support Windows. As such I have added redirects in the RTS
for the deprecated functions as listed on
https://msdn.microsoft.com/en-us/library/ms235384.aspx.
This won't export the functions (as in, they won't be in the symbol table
of compiled code for the RTS.) but we inject them into the symbol table
of the dynamic linker at startup.
Test Plan:
./validate
and
make test TEST="ffi017 ffi021"
Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd
Reviewed By: simonmar, bgamari
Subscribers: RyanGlScott, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2500
GHC Trac Issues: #12209, #12497, #12496
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Take the pointer notation out of the typedef such that it preserves the
fact that these are pointers at the use site.
Test Plan:
./validate on all platforms that use the runtime linker.
For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is
added to your validate file.
Continuation of D2250
Reviewers: austin, bgamari, simonmar, erikd
Reviewed By: erikd
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2302
GHC Trac Issues: #11816
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace `char*` and `void*` with `SymbolName` and `SymbolAddr` in
`Linker.c`. Gives some useful information about what the variables are
used for and also normalizes the types used in Mac, Linux and Windows
Test Plan:
./validate on all platforms that use the runtime linker.
For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is
added to your validate file.
This is a continuation from D2184
Reviewers: austin, erikd, simonmar, bgamari
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2250
GHC Trac Issues: #11816
|
| |
|
|
|
|
|
|
|
| |
LEADING_UNDERSCORE is defined in a header file, so we need to #include
that file where we use LEADING_UNDERSCORE.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D1382
|
|
|
Pull the RtsSymbolVal typedef and rtsSyms[] array out into a separate
header and C file. No change in functionality.
Test Plan: validate
Reviewers: simonmar, austin, bgamari
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D1362
|
