- 16 Oct, 2015 2 commits
-
-
Erik de Castro Lopo authored
Test Plan: Validate on x86_64, PowerPC and Arm Reviewers: simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1330 GHC Trac Issues: #10977
-
Add a missing #ifdef Reviewed By: simonmar Differential Revision: https://phabricator.haskell.org/D1328
-
- 15 Oct, 2015 6 commits
-
-
Simon Marlow authored
On 64-bit ELF we need to link object files into the low 2GB due to the small memory model. Previously we would map the entire object file using MAP_32BIT, but the object file can consist of 75% or more symbols, which only need to be present during linking, so this is wasteful. In our particular application, we're already running out of space here. This patch changes the way we load object files on ELF platforms so that the object is first mapped above the 2GB boundary, parsed, and then the important sections are re-mapped into the low 2GB area. Test Plan: validate (also needs testing on OS X & Windows, preferably 32 & 64 bit) Reviewers: Phyx, trommler, bgamari, austin Subscribers: hsyl20, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D975
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Comes with Haddock submodule update. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
This commit contains a Cabal submodule update which unifies installed package IDs and package keys under a single notion, a Component ID. We update GHC to keep follow this unification. However, this commit does NOT rename installed package ID to component ID and package key to unit ID; the plan is to do that in a companion commit. - Compiler info now has "Requires unified installed package IDs" - 'exposed' is now expected to contain unit keys, not IPIDs. - Shadowing is no more. We now just have a very simple strategy to deal with duplicate unit keys in combined package databases: if their ABIs are the same, use the latest one; otherwise error. Package databases maintain the invariant that there can only be one entry of a unit ID. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1184 GHC Trac Issues: #10714
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 14 Oct, 2015 2 commits
-
-
Erik de Castro Lopo authored
Arm has two instruction sets, Arm and Thumb, and an execution mode for each. Executing Arm code in Thumb mode or vice-versa will likely result in an Illegal instruction exception. Furthermore, Haskell code compiled via LLVM was generating Arm instructions while C code compiled via GCC was generating Thumb code by default. When these two object code types were being linked by the system linker, all was fine, because the system linker knows how to jump and call from one instruction set to the other. The first problem was with GHCi's object code loader which did not know about Thumb vs Arm. When loading an object file `StgCRun` would jump into the loaded object which could change the mode causing a crash after it returned. This was fixed by forcing all C code to generate Arm instructions by passing `-marm` to GCC. The second problem was the `mkJumpToAddr` function which was generating Thumb instructions. Changing that to generate Arm instructions instead results in a working GHCi on Arm. Test Plan: validate on x86_64 and arm Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1323 GHC Trac Issues: #10375
-
Austin Seipp authored
Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
- 13 Oct, 2015 9 commits
-
-
Erik de Castro Lopo authored
Before this commit, GHC only supported LLVM 3.6. Now it only supports LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier do not work on AArch64/Arm64, but 3.7 does. Also: * Add CC_Ghc constructor to LlvmCallConvention. * Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with a single `supportedLlvmVersion` variable. * Get `supportedLlvmVersion` from version specified in configure.ac. * Drop llvmVersion field from DynFlags (no longer needed because only one version is supported). Test Plan: Validate on x86_64 and arm Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1320 GHC Trac Issues: #10953
-
strake authored
See #10216 . Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
joeyadams authored
Fixes #8010, according to the specified libraries proposal. [1] Also, some minor wordsmithing. [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/22709 Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
Ryan Scott authored
The previous users' guide documentation was too implementation-oriented. This attempts to make it more accessible to those who aren't familiar with how `-XDeriveFunctor` and friends work (and more importantly, what will not work when using them). Fixes #10831. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1293 GHC Trac Issues: #10831
-
Ömer Sinan Ağacan authored
Currently, GHC's warning generation code is assuming that a name (`RdrName`) can be imported at most once. This is a correct assumption, because 1) it's OK to import same names as long as we don't use any of them 2) when we use one of them, GHC generates an error because it doesn't disambiguate it automatically. But apparently the story is different with typeclass methods. If I import two methods with same names, it's OK to use them in typeclass instance declarations, because the context specifies which one to use. For example, this is OK (where modules A and B define typeclasses A and B, both with a function has), import A import B data Blah = Blah instance A Blah where has = Blah instance B Blah where has = Blah But GHC's warning generator is not taking this into account, and so if I change import list of this program to: import A (A (has)) import B (B (has)) GHC is printing these warnings: Main.hs:5:1: Warning: The import of ‘A.has’ from module ‘A’ is redundant Main.hs:6:1: Warning: The import of ‘B.has’ from module ‘B’ is redundant Why? Because warning generation code is _silently_ ignoring multiple symbols with same names. With this patch, GHC takes this into account. If there's only one name, then this patch reduces to the previous version, that is, it works exactly the same as current GHC (thanks goes to @quchen for realizing this). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1257 GHC Trac Issues: #10890
-
Ryan Scott authored
Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function freak out if using a `Data` instance that produces a `Constr` (by means of `toConstr`) using a function name instead of a data constructor name. While such `Data` instances are somewhat questionable, they are nevertheless present in popular libraries (e.g., `containers`), so we can at least make `dataToQa` aware of their existence. In order to properly distinguish strings which represent variables (as opposed to data constructors), it was necessary to move functionality from `Lexeme` (in `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named `bin-package-db`). Reviewed By: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1313 GHC Trac Issues: #10796
-
bernalex authored
Add some commas, fix some typos, etc. Signed-off-by:
Alexander Berntsen <alexander@plaimi.net> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1321
-
Austin Seipp authored
This fallout was caused by f8fbf385 (see #10935 ), and looks easy enough, but admittedly I just tried patching the output, so we're doing it live. Signed-off-by:
Austin Seipp <austin@well-typed.com>
-
afarmer authored
HERMIT users depend on RULES to specify equational properties. 7.10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. A separate commit already disabled this for the LHS of rules. This does so for the RHS. See Trac #10829 for nofib results. Reviewed By: austin, bgamari, simonpj Differential Revision: https://phabricator.haskell.org/D1246 GHC Trac Issues: #10829
-
- 12 Oct, 2015 5 commits
-
-
Simon Peyton Jones authored
This patch is driven by Trac #10935, and reinstates the -fwarn-monomorphism-restriction warning. It was first lost in 2010: d2ce0f52 "Super-monster patch implementing the new typechecker -- at last" I think the existing documentation is accurate; it is not even turned on by -Wall. I added one test.
-
Simon Peyton Jones authored
-
Herbert Valerio Riedel authored
This refactors `(>>)`/`(*>)`/`return`/`pure` methods into normal form. The redundant explicit `return` method definitions are dropped altogether. The explicit `(>>) = (*>)` definitions can't be removed yet, as the default implementation of `(>>)` is still in terms of `(*>)` (even though that should have been changed according to the AMP but wasn't -- see note in GHC.Base for details why this had to be postponed) A nofib comparision shows this refactoring to result in minor runtime improvements (unless those are within normal measurement fluctuations): Program Size Allocs Runtime Elapsed TotalMem ------------------------------------------------------------------------- Min -0.0% -0.0% -1.6% -3.9% -1.1% Max -0.0% +0.0% +0.5% +0.5% 0.0% Geometric Mean -0.0% -0.0% -0.4% -0.5% -0.0% Full `nofib` report at https://phabricator.haskell.org/P68 Reviewers: quchen, alanz, austin, #core_libraries_committee, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1316
-
Erik de Castro Lopo authored
Summary: Test included. Test Plan: Run test T10870.hs on X86/X86_64/Arm/Arm64 etc Reviewers: bgamari, nomeata, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1322 GHC Trac Issues: #10870
-
Erik de Castro Lopo authored
-
- 10 Oct, 2015 7 commits
-
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Thomas Miedema authored
-
Ben Gamari authored
Sphinx may trip over itself when multiple instances are run in parallel. Fixes #10950.
-
Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1319
-
This can happen because the underlying primitive operations in `integer-gmp` don't support negative shift-amounts, and since `integer-gmp` can't throw proper exceptions and just provides a low-level API, it simply segfaults instead... This patch simply removes the `shift{L,R}` method definitions (and defines `unsafeShift{L,R}` instead) whose default-impls fallback on using `shift` which properly handles negative shift arguments. This addresses #10571 Test Plan: harbormaster can do it Reviewers: hvr, austin, rwbarton Subscribers: rwbarton, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1018 GHC Trac Issues: #10571
-
Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289
-
Thomas Miedema authored
Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1314
-
- 09 Oct, 2015 6 commits
-
-
Erik de Castro Lopo authored
Pushed by mistacke before it was ready. This reverts commit 5dc3db74.
-
Erik de Castro Lopo authored
-
Edward Z. Yang authored
Summary: Previously, we stored an entire ImportDecl, which was pretty wasteful since all we really cared about was the package qualifier and the module name. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1317
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
- 08 Oct, 2015 3 commits
-
-
Edward Z. Yang authored
Summary: Instead of doing these warnings at MkIface time, we do them when we create the instances/rules in the typechecker/desugarer. Emitting warnings for auto-generated instances was a pain (since the specialization monad doesn't have the capacity to emit warnings) so instead I just deprecated -fwarn-auto-orphans. Auto rule orphans are pretty harmless anyway: they don't cause interface files to be eagerly loaded in. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1297
-
Jan Stolarek authored
-
Thomas Miedema authored
Among doing other things, Phab:D201 (bc2289e1) tried to improve the error messages thrown by the parser. For example a missing else clause now prints "parse error in if statement: else clause empty" instead of "parse error (possibly incorrect indentation or mismatched brackets)". Some error messages got much worse however (see tests), and the result seems to be a net negative. Although not entirely satisfactory, this commits therefore reverts those parser changes. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1309 GHC Trac Issues: #10498
-