- Jul 24, 2017
-
-
Previously you had to painstakingly construct the URI to the haddock documentation. Now the Python bits have enough smarts to construct this themselves. Reviewers: austin, patrickdoc Reviewed By: patrickdoc Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3785
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
[skip-ci]
-
Ryan Scott authored
Summary: GHC's choice in how it nests `:+:` can sometimes affect the implementaiton of `GHC.Generics`-related code, so we should make a note of this in the examples we provide. Fixes #9453. Test Plan: Read it, like it, build it, ship it Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #9453 Differential Revision: https://phabricator.haskell.org/D3782
-
Ryan Scott authored
Summary: Some summer cleaning. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3783
-
- Jul 23, 2017
-
-
Ben Gamari authored
Fixes #14020, #14016, #14015, #14019
-
Ben Gamari authored
-
This patch does three things: 1.) It simplifies the flag parsing code in `conf.py` to properly display flag definitions created by `.. (ghc|rts)-flag::`. Additionally, all flag references must include the associated arguments. Documentation has been added to `editing-guide.rst` to explain this. 2.) It normalizes all flag definitions to a similar format. Notably, all instances of `<>` have been replaced with `⟨⟩`. All references across the users guide have been updated to match. 3.) It fixes a couple issues with the flag reference table's generation code, which did not handle comma separated flags in the same cell and did not properly reference flags with arguments. Test Plan: `SPHINXOPTS = -n` to activate "nitpicky" mode, which reports all broken references. All remaining errors are references to flags without any documentation. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13980 Differential Revision: https://phabricator.haskell.org/D3778
-
Ben Gamari authored
Somehow the previous version passed on master but fails on ghc-8.2. Will look deeper later. (cherry picked from commit a6774e1d)
-
Ben Gamari authored
(cherry picked from commit 8c5405f6)
-
Ben Gamari authored
(cherry picked from commit 09396ec3)
-
Ben Gamari authored
This pulls over changes that were made in the ghc-8.2 branch.
-
Ben Gamari authored
-
Ben Gamari authored
Otherwise you end up with ("target has RTS linker","@HaskellHaveRTSLinker@") in the installed settings file.
-
Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3776
-
`FFILibDir` and `FFIIncludeDir` both show up in the `rts` library's package registration file. We therefore must define them or else we'll end up with spurious `@FFILibDir@` strings in the package registration. In principle I think we could also take these as arguments to the bindist configure but this seems simpler and I don't want to verify this at the moment. Test Plan: Build bindist while passing `--with-ffi-libraries=...` to source distribution configure then try to install and use bindist. Reviewers: austin, hvr Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3774
-
Ben Gamari authored
Scripts taken from autoconf 81497f5aaf50a12a9fe0cba30ef18bda46b62959
-
- Jul 22, 2017
-
-
niteria authored
I've encountered an issue with following reproduction steps: * `:load` a large number of modules (~2000) * compile a BCO that depends on many other BCOs from many other modules * `:reload` * try to compile anything, even `1` works Before this patch the last step takes ~5s. It takes 80ms after. Test Plan: harbormaster Reviewers: simonmar, austin, hvr, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3770
-
Tamar Christina authored
Summary: Always set dllwrap and windres values. Reviewers: austin, hvr, bgamari, trofi Reviewed By: trofi Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #13792 Differential Revision: https://phabricator.haskell.org/D3775
-
Ryan Scott authored
Test Plan: If it builds, ship it Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3772
-
- Jul 21, 2017
-
-
Several executables inexplicably appear twice in bindist.list, which ends up producing multiple tar file entries, consequently breaking BSD tar during extraction. I spent a fair amount of time trying to work out where these duplicates were coming from to no avail. Since Hadrian is right around the corner I'm satisfied with a terrible hack: just uniq bindist.list before producing the bindist tarball. Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13979, #13974 Differential Revision: https://phabricator.haskell.org/D3767
-
- Jul 20, 2017
-
-
This is a conservative assumption which will limit some uses of spliced patterns, but it fixes #13984. Test Plan: Validate Reviewers: RyanGlScott, AaronFriel, austin Reviewed By: RyanGlScott Subscribers: rwbarton, thomie GHC Trac Issues: #13984 Differential Revision: https://phabricator.haskell.org/D3766
-
Ben Gamari authored
This reverts commit b2d3ec37. Didn't mean to push this one.
-
Ben Gamari authored
-
Previously we failed to do this, which meant that the bindist's configure would fail when passed --target (as you may need to do when installing an armv7 bindist on an aarch64 machine, for instance). Reviewers: hvr, erikd, austin Reviewed By: hvr Subscribers: rwbarton, thomie GHC Trac Issues: #13934 Differential Revision: https://phabricator.haskell.org/D3761
-
In the fix to #13615 we introduced some logic to atomically blackhole AP_STACKs closures upon entry. However, this logic was placed *after* a stack pointer adjustment. This meant that if someone else beat us to blackholing the AP_STACK we would suspend the thread with uninitialized content on the stack. This would then later blow up when threadPaused attempted to walk the stack, hence #13970. Silly bug but still cost lots of head-scratching to find. Thanks to albertov for the great repro. Fixes #13970. Bug originally introduced by the fix to #13615. Reviewers: austin, erikd, simonmar Reviewed By: erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13970, #13615 Differential Revision: https://phabricator.haskell.org/D3760
-
This is another step in fixing #13825 (based on D38 by Simon Marlow). This commit adds a few macros for accessing and modifying `Sp` (interpreter stack) and will be useful to allow sub-word indexing/pushing. (but that will be a separate change, this commit should introduce no changes in behavior) Signed-off-by:
Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar, austin, erikd Reviewed By: bgamari, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #13825 Differential Revision: https://phabricator.haskell.org/D3744
-
Edward Z. Yang authored
Fixes #13803, but adds a note about a yet to be fixed #13981. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13803 Differential Revision: https://phabricator.haskell.org/D3742
-
Test T13701 was failing sporadically. The problem manifested while the test was run on a system under load. Profiling showed the increased allocations were in SysTools.builderMainLoop.loop, during calls to the assembler. This was due to loop effectively busy-waiting from when both stdin and stderr handles were closed, until getProcessExitCode succeeded. This is fixed by removing exit code handling from loop. We now wait for loop to finish, then read the exit code with waitForProcess. Some exception safety is added: the readerProc threads will now be killed and the handles will be closed if an exception is thrown. A TODO saying that threads dying is not accounted for is removed. I believe that this case is handled by readerProc sending EOF in a finally clause. Test Plan: Replicate test failures using procedure on the ticket, verify that they do not occur with this patch. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13987 Differential Revision: https://phabricator.haskell.org/D3748
-
Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3728
-
Previously the driver would read the stdin content from the source file and then write it to the subprocess' stdin. We now simply open the stdin file and provide that handle to the subprocess as its stdin Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D3735
-
This flag instructs the simplifier to emit ``error`` expressions in the continutation of empty case analyses (which should bottom and consequently not return). This is helpful when debugging demand analysis bugs which can sometimes manifest as segmentation faults. Test Plan: Validate Reviewers: simonpj, austin Subscribers: niteria, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3736
-
[skip-ci] Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3737
-
Gabor Greif authored
-
This fixes #13915, where the promoted tycons belonging to data family instances wouldn't get Typeable bindings, resulting in missing declarations. Test Plan: Validate with included testcases Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, RyanGlScott, rwbarton, thomie GHC Trac Issues: #13915 Differential Revision: https://phabricator.haskell.org/D3759
-
- Jul 19, 2017
-
-
-
-
Ryan Scott authored
An error message was referring to a type synonym as a datatype. Annoyingly, learning that the TyCon over which the error message is operating is actually a type synonym was previously impossible, since that code only had access to a TcTyCon, which doesn't retain any information about what sort of TyCon it is. To rectify this, I created a new TyConFlavour datatype, intended to capture roughly what sort of TyCon we're dealing with. I then performing the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and propagated this information through to the relevant error message. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13983 Differential Revision: https://phabricator.haskell.org/D3747
-
This fixes #13977 and consequently #13615. Here an optimization in the demand analyser was too liberal, causing us to drop the ExnStr flag and consequently resulting in incorrect demand signatures. This manifested as a segmentation fault in #13615 as we incorrectly concluded that an application of catchRetry# would bottom. Specifically, we had orElse' :: STM a -> STM a -> STM a orElse' x = catchRetry# x y where y = {- some action -} Where the catchRetry# primop places a demand of <xC(S),1*C1(U)> on its first argument. However, due to #13977 the demand analyser would assign a demand of <C(S),1*C1(U)> on the first argument of orElse'. Note the missing `x`. case orElse' bottomingAction anotherAction of { x -> Just x } being transformed to, case orElse' bottomingAction anotherAction of {} by the simplifier. This would naturally blow up when orElse' returned at runtime, causing the segmentation fault described in #13615. Test Plan: Validate, perhaps add a testcase Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13977, #13615 Differential Revision: https://phabricator.haskell.org/D3756
-