- Jan 17, 2019
-
-
-
All operating systems except AIX and Darwin follow the ELF specification.
-
-
Ömer Sinan Ağacan authored
-
- Jan 16, 2019
-
-
Ömer Sinan Ağacan authored
-
...and does so in the lib folder of the right stage
-
Fixes #16105 * Require Haddock's resource as runtime dependencies of the Haddock builder. This means we no longer have to `need` particular resources in every other documentation rule. * Do a _tracked_ copy of both the 'html' and 'latex' folder resource folders. * Move resources into `stage1/lib` (NB: the `haddock` binary goes in `stage1/bin`). Besides now actually matching the Haddock script wrapper generated by BinaryDist, this also prepares for Haddock in relocatable build folder detecting its own resources. -
-
This reverts commit af210f40
-
-
The Stack build script `build.stack.bat` currently fails on Windows when invoked with the `--configure` flag, see: https://ghc.haskell.org/trac/ghc/ticket/15982 The Cabal build script `build.cabal.bat` works reliably on my Windows machine, so I am proposing to switch to it by default, that is, to run it from the default `build.bat` script. The Stack build script can still be run directly if need be.
-
-
See https://ghc.haskell.org/trac/ghc/ticket/15971. This is work in progress: this commit does the right thing, but does not yet fix the ticket.
-
Alp Mestanogullari authored -
Alp Mestanogullari authored
-
The rts option `-h` behaves as `-hT` when compiled without profiling, and `-hc` when compiled with profiling. Add a note to the user's guide highlighting this inconsistency.
-
-
Complete b7b6617a (see ticket #15086) to actually enable profiling by closure type in the profiling rts. I.e. +RTS -p -hT is now accepted.
-
-
A bunch of tests for `integer-simple` were now broken for a foolish reason: unlike the `integer-gmp` case, there is no CorePrep optimization for turning small integers directly into applications of `S#`. Rather than port this optimization to `integer-simple` (which would involve moving a bunch of `integer-simple` names into `PrelNames`), I switched as many tests as possible to use `Int`. The printing of `Integer` is already tested in `print037`.
-
* `GHC.Natural` now exports the same functions (regardless of integer backend) * remove unnecessary CPP around instances * remove the 'OPTIMISE_INTEGER_GCD_LCM' flag - almost all of those optimizations now work regardless of which integer backend is used Note that some CPP still remains for situations where there are backend-specific optimization hacks (like a more efficient GMP-only `gcd` for `Int#` and `Word#`). -
In `integer-simple`: * Added an efficient `popCountInteger` and `bitInteger` * Added an efficient `gcdInteger` and `lcmInteger` * Made `testBitInteger` more efficient
-
This means that `:p` no longer leaks the implementation details of `Integer` with `integer-simple`. The `print037` test case should exercise all possible code paths for GHCi's code around printing `Integer`s (both in `integer-simple` and `integer-gmp`). `ghc` the package now also has a Cabal `integer-simple` flag (like the `integer-gmp` one).
-
Summary: This matches the existing behaviour for .hi files: if the user requests the interface file be written in some location, we should create the parent folder if it doesn't already exist. Reviewers: bgamari, sjakobi Reviewed By: sjakobi Subscribers: sjakobi, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5463
-
Summary: This fixes some of the issues that surfaced when trying to build dynamic GHC on OSX. Unfortunately, due some other `libffi` issues, this doesn't completely fix dynamic builds on OSX. - Use 'extra-libraries' from .cabal files instead of hardcoding which packages need which extra libs. Also add support for 'extra-lib-dirs'. - Make sure Hadrian looks in the right places to support both plain '<pkg>.buildinfo' and '<pkg>.buildinfo.in' files. - Make the '-rpath' support more robust across OS's (it previously didn't work on OSX and possibly windows either). Reviewers: angerman, alpmestan, adamse, DavidEichmann, bgamari, Phyx Subscribers: rwbarton, carter GHC Trac Issues: #15990 Differential Revision: https://phabricator.haskell.org/D5409 -
Introduce ghci command wrapper, which can be used to cutomize ghci: * process additionals actions before/after the command * handle particular exceptions in given ways * logging stats We also split the timing and printing part of `timeIt` into different functions.
-
-
-
There is only one place where UPDATE_SP was used. Instead of the UPDATE_SP pseudo instruction build the list of instructions directly.
-
This means that we can query the package DB for haddock interfaces. Haddock uses this in its testsuite. 'cabal {v1-,v2,}-haddock' also uses this. Also thread through to Haddock package-specific overrides of GHC warnings. -
Roland Senn authored
-
Roland Senn authored
-
Mr Kerckhove authored
-
- Jan 15, 2019
-
-
Ryan Scott authored
-
Ryan Scott authored
-
Ryan Scott authored
Trac #16059 shows that when validity checking applications of type synonyms, GHC sometimes wasn't checking the expanded type enough. We must be careful, however, since checking both the expanded type as well as the arguments to the type synonym can lead to exponential blowup (see https://ghc.haskell.org/trac/ghc/ticket/16059#comment:4). Nor can we omit checking either the expanded type or the argument for correctness reasons. The solution here is to introduce a new `ExpandMode` data type that is plumbed through all of the type-validity-checking functions in `TcValidity`. `ExpandMode` dictates whether we only check the expanded type (`Expand`), only check the arguments (`NoExpand), or both (`Both`). Importantly, if we check `Both` in the function for validity checking type synonym applications, then we switch to `NoExpand` when checking the arguments so as to avoid exponential blowup. See `Note [Correctness and performance of type synonym validity checking]` for the full story.
-
Ryan Scott authored
-
Ryan Scott authored
-
- Jan 14, 2019
-
-
Ben Gamari authored
See Note [Cleanup on Windows].
-
-
