]]>
Fix two more `#ifndef` for the linterJohn Ericson <John.Ericson@Obsidian.Systems>Fri, 21 Jun 2019 00:30:25 +0000https://git.haskell.org/ghc.git/commitdiff/fb43bddc771094632bd08a4eab28fd3e714affd0https://git.haskell.org/ghc.git/commitdiff/fb43bddc771094632bd08a4eab28fd3e714affd0
Fix two more `#ifndef` for the linter
Fix two more `#ifndef` for the linter

]]>
Remove all target-specific portions of Config.hsJohn Ericson <git@JohnEricson.me>Wed, 27 Mar 2019 04:27:01 +0000https://git.haskell.org/ghc.git/commitdiff/e529c65eacf595006dd5358491d28c202d673732https://git.haskell.org/ghc.git/commitdiff/e529c65eacf595006dd5358491d28c202d673732
Remove all target-specific portions of Config.hs
Remove all target-specific portions of Config.hs
1. If GHC is to be multi-target, these cannot be baked in at compile
time.
2. Compile-time flags have a higher maintenance than run-time flags.
3. The old way makes build system implementation (various bootstrapping
details) with the thing being built. E.g. GHC doesn't need to care
about which integer library *will* be used---this is purely a crutch
so the build system doesn't need to pass flags later when using that
library.
4. Experience with cross compilation in Nixpkgs has shown things work
nicer when compiler's can *optionally* delegate the bootstrapping the
package manager. The package manager knows the entire end-goal build
plan, and thus can make top-down decisions on bootstrapping. GHC can
just worry about GHC, not even core library like base and ghc-prim!

]]>
Move cGHC_UNLIT_PGM to be "unlit command" in settingsJohn Ericson <John.Ericson@Obsidian.Systems>Thu, 4 Apr 2019 17:38:53 +0000https://git.haskell.org/ghc.git/commitdiff/2988ef5e0334f9841bf23d905b0363a3b8a1a660https://git.haskell.org/ghc.git/commitdiff/2988ef5e0334f9841bf23d905b0363a3b8a1a660
Move cGHC_UNLIT_PGM to be "unlit command" in settings
Move cGHC_UNLIT_PGM to be "unlit command" in settings
The bulk of the work was done in #712, making settings be make/Hadrian
controlled. This commit then just moves the unlit command rules in
make/Hadrian from the `Config.hs` generator to the `settings` generator
in each build system.
I think this is a good change because the crucial benefit is *settings*
don't affect the build: ghc gets one baby step closer to being a regular
cabal executable, and make/Hadrian just maintains settings as part of
bootstrapping.

]]>
Make GHC (the library) flexible in the choice of integer libraryJoachim Breitner <mail@joachim-breitner.de>Wed, 3 Oct 2018 13:36:55 +0000https://git.haskell.org/ghc.git/commitdiff/fc2ff6dd7496a33bf68165b28f37f40b7d647418https://git.haskell.org/ghc.git/commitdiff/fc2ff6dd7496a33bf68165b28f37f40b7d647418
Make GHC (the library) flexible in the choice of integer library
Make GHC (the library) flexible in the choice of integer library
Summary:
We have more and more users of GHC as a library, for example the
Haskell-to-WebAssembly-compiler https://github.com/tweag/asterius.
These need to make different decisions about various aspects of
code generation than the host compiler, and ideally GHC-the-library
allows them to set the `DynFlags` as needed.
This patch adds a new `DynFlag` that configures which `integer`
library to use. This flag is initialized by `cIntegerLibraryType`
(as before), and is only used in `CorePrep` to decide whether to
use `S#` or not.
The other code paths that were varying based on `cIntegerLibraryType`
are no now longer varying: The trick is to use `integer-wired-in`
as the `-this-unit-id` when compiling either `integer-gmp` or
`integer-simple`.
Test Plan: Validate is happy.
Reviewers: hvr, bgamari
Reviewed By: bgamari
Subscribers: TerrorJack, adamse, simonpj, rwbarton, carter
GHC Trac Issues: #13477
Differential Revision: https://phabricator.haskell.org/D5079

]]>
Remove dll-split.Tamar Christina <tamar@zhox.com>Mon, 28 Aug 2017 16:29:48 +0000https://git.haskell.org/ghc.git/commitdiff/5266ab9059dffa741b172636f50f1fbfd491dbb4https://git.haskell.org/ghc.git/commitdiff/5266ab9059dffa741b172636f50f1fbfd491dbb4
Remove dll-split.
Remove dll-split.
This patch removes dll-split from the code base, the reason is dll-split
no longer makes any sense. It was designed to split a dll in two, but we
now already have many more symbols than would fit inside two dlls. So we
need a third one. This means there's no point in having to maintain this
list as it'll never work anyway and the solution isn't scalable.
Test Plan: ./validate
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3882

]]>
Refactor temp files cleanupDouglas Wilson <douglas.wilson@gmail.com>Thu, 8 Jun 2017 18:59:49 +0000https://git.haskell.org/ghc.git/commitdiff/3ee3822ce588565e912ab6211e9d2cd545fc6ba6https://git.haskell.org/ghc.git/commitdiff/3ee3822ce588565e912ab6211e9d2cd545fc6ba6
Refactor temp files cleanup
Refactor temp files cleanup
Remove filesToNotIntermediateClean from DynFlags, create a data type
FilesToClean, and change filesToClean in DynFlags to be a FilesToClean.
Modify SysTools.newTempName and the Temporary constructor of
PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies
whether a temp file should live until the end of GhcMonad.withSession,
or until the next time cleanIntermediateTempFiles is called.
These changes allow the cleaning of intermediate files in GhcMake to be
much more efficient.
HscTypes.hptObjs is removed as it is no longer used.
A new performance test T13701 is added, which passes both with and
without -keep-tmp-files. The test fails by 25% without the patch, and
passes when -keep-tmp-files is added.
Note that there are still at two hotspots caused by
algorithms quadratic in the number of modules, however neither of them
allocate. They are:
* DriverPipeline.compileOne'.needsLinker
* GhcMake.getModLoop
DriverPipeline.compileOne'.needsLinker is changed slightly to improve
the situation.
I don't like adding these Types to DynFlags, but they need to be seen by
Dynflags, SysTools and PipelineMonad. The alternative seems to be to
create a new module.
Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie
GHC Trac Issues: #13701
Differential Revision: https://phabricator.haskell.org/D3620

]]>
Udate hsSyn AST to use Trees that GrowAlan Zimmerman <alan.zimm@gmail.com>Fri, 19 May 2017 12:56:09 +0000https://git.haskell.org/ghc.git/commitdiff/8e6ec0fa7431b0454b09c0011a615f0845df1198https://git.haskell.org/ghc.git/commitdiff/8e6ec0fa7431b0454b09c0011a615f0845df1198
Udate hsSyn AST to use Trees that Grow
Udate hsSyn AST to use Trees that Grow
Summary:
See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
This commit prepares the ground for a full extensible AST, by replacing the type
parameter for the hsSyn data types with a set of indices into type families,
data GhcPs -- ^ Index for GHC parser output
data GhcRn -- ^ Index for GHC renamer output
data GhcTc -- ^ Index for GHC typechecker output
These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
Where the original name type is required in a polymorphic context, this is
accessible via the IdP type family, defined as
type family IdP p
type instance IdP GhcPs = RdrName
type instance IdP GhcRn = Name
type instance IdP GhcTc = Id
These types are declared in the new 'hsSyn/HsExtension.hs' module.
To gain a better understanding of the extension mechanism, it has been applied
to `HsLit` only, also replacing the `SourceText` fields in them with extension
types.
To preserve extension generality, a type class is introduced to capture the
`SourceText` interface, which must be honoured by all of the extension points
which originally had a `SourceText`. The class is defined as
class HasSourceText a where
-- Provide setters to mimic existing constructors
noSourceText :: a
sourceText :: String -> a
setSourceText :: SourceText -> a
getSourceText :: a -> SourceText
And the constraint is captured in `SourceTextX`, which is a constraint type
listing all the extension points that make use of the class.
Updating Haddock submodule to match.
Test Plan: ./validate
Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
Subscribers: rwbarton, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D3609