- 09 Oct, 2015 2 commits
-
-
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 5 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
-
Matthew Pickering authored
For example ``` pattern head `Cons` tail = head : tail ``` Reviewed By: goldfire, austin Differential Revision: https://phabricator.haskell.org/D1295 GHC Trac Issues: #10747
-
kanetw authored
Improved error messages are only printed when the old message would be "No instance for...", since they're not as helpful for "Could not deduce..." No special test case as error messages are tested by other tests already. Signed-off-by:
David Kraeutmann <kane@kane.cx> Reviewed By: austin, goldfire Differential Revision: https://phabricator.haskell.org/D1182 GHC Trac Issues: #10733
-
- 07 Oct, 2015 2 commits
-
-
Ben Gamari authored
Fixes #10571.
-
Ben Gamari authored
Apparently some Clang 3.6 expects these to be sorted. Patch due to Peter Wortmann. Fixes #10687.
-
- 06 Oct, 2015 7 commits
-
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Simon Peyton Jones authored
Triggered by investigations around Trac 10845
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
A missing 'closeOverKinds' triggered Trac #10934. Happily the fix is simple. Merge to 7.10.3
-
Simon Peyton Jones authored
-
Edward Z. Yang authored
Summary: We had a duplicate copy of the code for --make and for -c which was a pain. The call graph looked something like this: compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend hscCompileOneShot ---^ with genericHscCompileGetFrontendResult and hscCompileOneShot duplicating logic for deciding whether or not recompilation was needed. This patchset fixes it, so now everything goes through this call-chain: compileOne (--make entry point) Calls hscIncrementCompile, invokes the pipeline to do codegen and sets up linkables. hscIncrementalCompile (-c entry point) Calls hscIncrementalFrontend, and then simplifying, desugaring, and writing out the interface. hscIncrementalFrontend Performs recompilation avoidance, if recompilation needed, does parses typechecking. I also cleaned up some of the MergeBoot nonsense by introducing a FrontendResult type. NB: this BREAKS #8101 again, because I can't unconditionally desugar due to Haddock barfing on lint, see #10600 Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, bgamari, simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1302
-
- 05 Oct, 2015 2 commits
-
-
Thomas Miedema authored
Reviewed by: kgardas Differential Revision: https://phabricator.haskell.org/D1311
-
Gabor Greif authored
-
- 04 Oct, 2015 2 commits
-
-
Thomas Miedema authored
It should be possible to run the testsuite with older versions of GHC. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1308
-
Thomas Miedema authored
A `make` build after running `./validate` earlier should use the normal mk/build.mk settings, without having to manually delete the leftover file mk/are-validating or run `make clean` first. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1307
-
- 03 Oct, 2015 11 commits
-
-
The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563
-
Ben Gamari authored
This started intermittently failing as a result of D1239. I suspect this was just the straw that broke the camel's back however.
-
Summary: Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in associated type family defaults when deriving a class which contained them. In order to fix this properly, `tcATDefault` needed to be used from `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved from `TcInstDcls` to `TcClsDcl`. Fixes #10361. Test Plan: ./validate Reviewers: kosmikus, dreixel, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1283 GHC Trac Issues: #10361
-
This warning was implemented via abb3a9fa for addressing #7881. The bounded H2010 integral types were handled, but the `Integer` type was missed for the enumeration warning. Fixes #10929 Test Plan: reused T7881 testcase Reviewers: thomie, bgamari, austin Reviewed By: thomie, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1305 GHC Trac Issues: #10929
-
This adds a data family (`URec`) and six data family instances (`UAddr`, `UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`, `Float#`, `Int#`, or `Word#`, respectively. The programmer can then provide instances for these data family instances to provide custom implementations for unboxed types, similar to how derived `Eq`, `Ord`, and `Show` instances currently special-case unboxed types. Fixes #10868. Test Plan: ./validate Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus Reviewed By: dreixel, kosmikus Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1239 GHC Trac Issues: #10868
-
Thomas Miedema authored
-
Reviewers: austin, bgamari Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1303 modified: configure.ac
-
Test Plan: ./validate Reviewers: thomie, austin, bgamari Reviewed By: bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1304
-
The Windows preprocessor code calls `runInteractiveProcess` but does not check if an exception is thrown. `runInteractiveProcess` calls `CreateProcess` which when given a format the system loader does not know about will throw an exception. This is what makes #9399 fail. Ultimately we should not use any `CreateProcess` based calls but instead `ShellExecuteEx` as this would allow us to run applications that the shell knows about instead of just the loader. More details on #365. This patch removes `PhaseFailed` and throws `ProgramError` instead. `PhaseFailed` was largely unneeded since it never gave very useful information aside from the `errorcode` which was almost always `1`. `IOErrors` have also been eliminated and `GhcExceptions` thrown in their place wherever possible. Updates haddock submodule. Test Plan: `./validate` to make sure anything didn't break and `make TESTS="T365"` to test that an error is now properly thrown Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1256 GHC Trac Issues: #365
-
Ben Gamari authored
-
Ben Gamari authored
-
- 02 Oct, 2015 9 commits
-
-
We should only use the old linkable when the really is nothing to be done. In the case of hs-boot, there should just not be a linkable. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1301
-
This patch is due to Andreas Schwab. This fixes #10926, which reports (on AArch64) errors of the form, ``` /tmp/ghc1492_0/ghc_1.hc:2844:25: warning: passing argument 1 of 'hs_atomic_xor64' makes pointer from integer without a cast [-Wint-conversion] _c1Ho = hs_atomic_xor64((*Sp) + (((Sp[1]) << 0x3UL) + 0x10UL), Sp[2]); ^ In file included from /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/Stg.h:273:0: 0, from /tmp/ghc1492_0/ghc_1.hc:3: /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/stg/Prim.h:41:11: note: expected 'volatile StgWord64 * {aka volatile long unsigned int *}' but argument is of type 'long unsigned int' StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); ^ ``` Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1300 GHC Trac Issues: #10926
-
CallStack requires tuples, instances of which are defined in GHC.Tuple. Unfortunately the change made in D757 to the `Typeable` deriving mechanism means that `GHC.Tuple` must import `GHC.Types` for types necessary to generate type representations. This results in a cycle. Test Plan: Validate Reviewers: gridaphobe, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1298
-
The LLVM code generator currently has a rather large amount of boilerplate devoted to piping around and building up various AST elements. This is rather unfortunate for a language which prides itself on ease of abstraction and detracts from readability. Here I continue a refactoring that I originally suggested in D991, using `WriterT` to factor out this pattern. `WriterT` is in general a bit problematic from an evaluation perspective, but the expressions here are small enough that it should be a problem in practice. Test Plan: Validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1286
-
This fixes Trac #7883. This adds proper support for, * `MO_AtomicRMW` * `MO_AtomicWrite` * `MO_CmpXChg` Test Plan: Validate Reviewers: rrnewton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1282 GHC Trac Issues: #7883
-
Implement access to spill slots at offsets larger than 16 bits. Also allocation and deallocation of spill slots was restricted to 16 bit offsets. Now 32 bit offsets are supported on all PowerPC platforms. The implementation of 32 bit offsets requires more than one instruction but the native code generator wants one instruction. So we implement pseudo-instructions that are pretty printed into multiple assembly instructions. With pseudo-instructions for spill slot allocation and deallocation we can also implement handling of the back chain pointer according to the ELF ABIs. Test Plan: validate (especially on powerpc (32 bit)) Reviewers: bgamari, austin, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1296 GHC Trac Issues: #7830
-
Reviewers: bgamari, hvr, austin Reviewed By: bgamari, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1289
-
Here we fix a few mis-optimizations that could occur in code with floating point comparisons with -0.0. These issues arose from our insistence on rewriting equalities into case analyses and the simplifier's ignorance of floating-point semantics. For instance, in Trac #10215 (and the similar issue Trac #9238) we turned `ds == 0.0` into a case analysis, ``` case ds of __DEFAULT -> ... 0.0 -> ... ``` Where the second alternative matches where `ds` is +0.0 and *also* -0.0. However, the simplifier doesn't realize this and will introduce a local inlining of `ds = -- +0.0` as it believes this is the only value that matches this pattern. Instead of teaching the simplifier about floating-point semantics we simply prohibit case analysis on floating-point scrutinees and keep this logic in the comparison primops, where it belongs. We do several things here, - Add test cases from relevant tickets - Clean up a bit of documentation - Desugar literal matches against floats into applications of the appropriate equality primitive instead of case analysis - Add a CoreLint to ensure we don't pattern match on floats in Core Test Plan: validate with included testcases Reviewers: goldfire, simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1061 GHC Trac Issues: #10215, #9238
-
Joachim Breitner authored
reverting my bogus commit there.
-